Paper

[fantahund]

Can you implement the paper API?

[IzzelAliz]

I don't know exactly how much plugin requires a paper api.
This is actually planned with very low priority.

If someone see this please add an emoji here.

[fantahund]

We have a lot of plugins on our vanilla server that need the Paper API. :>

[IzzelAliz]

This is now considered in roadmap.

I'm busy schooling now, and if I have enough time I will work on it.

[Mike5357]

Paper support is definitely something I'd love to see supported by Arclight

[IzzelAliz]

I wonder if users prefer Paper API support or just performance and optimize.

Please react with ❤️ if API support and 🚀 if performance.

[Hi-Im-Ina]

Hello,
At the moment the Pixelmon mod community is preparing itself for a version bump to 1.16.5 and as such we've all been looking for ways to host our servers.
The consensus seems to be SpongeForge is less preferred due to the mostly dry ecosystem of plugins, Mohist is unstable but does come with Paper benefits unlike Arclight which despite being generally considered the best solution for those looking to jump to a Spigot hybrid has always been held back compared to the alternative due to the lack of Paper API and optimizations.
Arclight has a lot to gain in terms of community support by properly implementing Paper even if just bit by bit into itself.
Hopefully this incentivizes you to consider tackling both sides of the coin.

Thank you for all the work you do in the project!

[Rasgnarok]

PixelmonMod Community Manager here. A full, clean implementation of Paper is needed for Arclight to be production-ready. Servers with a large amount of players will require the support Paper provides in API and performance. We expect that with our move to 1.16.5, you'll be seeing a lot more pressure from the server community towards Arclight's performance in comparison to projects such as Mohist or even Sponge. Should you need to discuss this further, I'm on your discord, Rasgnarok#6969.

[Sm0keySa1m0n]

I think both are a good idea, performance is definitely a huge issue for large scale servers at the moment especially with chunk loading.

[IzzelAliz]

Per discussion in Discord.

I have the interest to have Paper in Arclight. However, Paper is rapidly changing and its API set is way larger than Spigot, and they make much more changes to this game.
Maintaining from both Spigot and Paper is too difficult for me, but if there is help from community it would be good.
Here are some stats: Spigot has roughly 40k line patches and Paper has 118k line patches. I can made an update between major versions in about 7 days for a 40k line project. The lines in Paper should be lesser as they sometimes include api codes in server patches.
Paper is a simple human resource problem to me, and if someone want to become a maintainer that is responsible for version upgrade, bugfix, optionally optimisations, doing paper stuff, etc please DM me.

[Maxsh001]

At least add the adventure API plz

[qyl27]

After Paper changes more of Spigot's behaviors, we might need to re-evaluate the priority of this issue and make a decision.
cc @IzzelAliz

[PukPukov]

Reducing paper api support is actually good thing because idiotic paper devs gives no shit to backwards compatibility. Less paper api support = less paper plugins = less pain.

[virtualspan]

This is the time to make implementing the Paper API as a priority, this is because as of 1.21.4, Paper is becoming a hard fork and distancing itself from Spigot, and it will slowly drop Spigot plugin support over time. This all basically means that plugins will be forced, to increase their workload supporting both, or more likely, remove spigot support and migrate to Paper. And obviously Paper is not going anywhere, it is the most widely used minecraft server jar, with Spigot being a much lesser and lesser priority for plugin Devs as it loses popularity. Ultimately, Arclight is going to have to support the Paper API at some point soon, unless it wants to significantly reduce plugin support.

[PukPukov]

Ah yes, the good old "big brother watching you"-style reasoning. You should give paper all rights to do everything with API without being limited by spigot not because paper good or something, no, you should do that because everyone do that and you can only cry about it.

[PukPukov]

I wonder if users prefer Paper API support or just performance and optimize.

Paper actually does not improve performance, from my benchmarks that i've done last year Spigot and Paper had the exact same performance (Paper was even slower, but this was most likely measurement error). Only way to improve performance over Spigot was to use performance-targeted forks of Paper that could improve it twice.

[PukPukov]

Paper have not so big support — they actively using bots and their own staff members to create illusion of support (does it reminds me of something?).

And if you will try to argue with them, you will get more insults than actual arguments. Check this thread: https://www.spigotmc.org/threads/wiki-vg-is-down-—-any-alternative.242197

[PukPukov]

And the irony is that paper hardfork directly hits all forks of paper that doing better, eliminating all competitors. All of them will have to perform a huge job on transferring their own patches to new paper patch system. While paper with dozens of developers can do that, forks that have just one or two maintainers most likely will just be discontinued.

[PukPukov]

Paper again forcing developers to spend their time on adapting with a sole alternative of discontinuing their project which they could have been working on for years. Whats paper's argument on that? "ur lazy son of a bitch". As if developers owe something to paper.

[qyl27]

Yes, I stand with Paper, Spigot API is too old to face the new versions of Minecraft, and developers have suffered from Spigot for a long time.
We will begin our Paper implementation soon, and keep Spigot API support.

[PukPukov]

and developers have suffered from Spigot for a long time.

That does not sound very convincing without any arguments, especially when there are some quite well-reasoned posts above that says exactly opposite things.

[PukPukov]

I have to add that I am not agitating for spigot, paper also have some good things over spigot, like adventure lib with itemstacks integration and anti xray, and no need to lose it just because paper team became mad. Spigot could just pull that changes from paper, but they refused (for some reason; there could be a good reason, but I dont see any).

What we have to do is to agree that paper have huge ideologic problems and stop being fans of somebody who completely disrespects you and your work. One of alternatives will be fork of paper that will think about backward compatibility.

It could start even from old repo, if fork authors that now forced by paper to adapt will refuse and make 1.21.4 update themselves, together.

[qyl27]

and developers have suffered from Spigot for a long time.

That does not sound very convincing without any arguments, especially when there are some quite well-reasoned posts above that says exactly opposite things.

Yes, something you might not know, that is for plugin developers. It doesn't matter.
Personally, I totally disagree with your ideological accusations about the hard fork. I am focused on the technical things and second it.
Btw, you can criticize PaperMC, but in this issue, we are talking about the implementation, and we will do it soon.

[PukPukov]

Implementation is "how", ideology is "why"... It is more important. Being fair, for Arclight hard fork matters less because it is mixin based, but paper's carte blanche on api breakages still will affect arclight later.

[qyl27]

Again, the hard fork will be positive for the server-side software, we are happy to see that and will deliver ourselves on it.

[PukPukov]

Again, "nuh uh" is not a best argument.

[IzzelAliz]

Stop making drama here.We're nothing against paper or their team. If majority of users want paper support, we'll consider it, and we are considering it.2024年12月15日 08:36，PukPukov ***@***.***>写道： Again, "nuh uh" is not a best argument. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>