So now we have Folia, which is a fork of Paper, which is a fork of Spigot, which I believe was originally a fork of Bukkit. Nice. I guess people don't want to upstream patches for some reason.
So now we have Folia, which is a fork of Paper, which is a fork of Spigot, which I believe was originally a fork of Bukkit. Nice. I guess people don't want to upstream patches for some reason.
I have a feeling such plans were killed off during the acquisition, as it has never been mentioned since then. Even now it would be simple for the devs to allow players to add new blocks and items via server sent resource packs without needed a modded client, and yet for some reason they do not.
I still have to thanks Bukkit/Spigot for getting me in to Java in the first place tough, and thus my current position as a Java dev. I don't follow it as often but I still maintain a small server my friends play on.
The biggest problem with the "mod API" is that, effectively, you'll need to open source Minecraft entirely to satisfy the kinds of changes mods make to the vanilla experience, or else everyone will keep using the patch systems we are building on now. It is discouraged unless absolutely needed, but mods can even apply bytecode level runtime patches on the vanilla classpath to enable functionality that the mod framework hasn't yet exposed.
Basically, there was Bukkit. In 2011, Mojang hired a bunch of Bukkit's developers, but didn't tell anyone that they also legally took control of the Bukkit project. This was because Mojang didn't really want Bukkit to be their official API as much as being a temporary API for the time being (and also didn't want to have anyone assume they would be responsible for it), but from that point, Bukkit was legally their project and the community didn't know.
Then, Mojang changed their EULA to ban Pay-to-win servers. This caused a lot of controversy, and one of the Bukkit developers left. Mojang then revealed that, yeah, they owned Bukkit for years, so they didn't need him. Another developer, feeling betrayed, who had contributed to Bukkit, submitted a DMCA takedown against his own code bringing Bukkit down with it, angry at having done "free labor." (You might say, "but the GPL!," but being tricked into a contract under false pretenses can legally invalidate contracts, making the GPL-license for his contributions potentially invalid.) Mojang panicked at the takedown and a ton of developers abandoned ship, working on Bukkit's community fork Spigot. Mojang then 2.5 months later brought Bukkit back and that time really just threw it into the community's hands.
The result of the aftermath was everyone had restructured around Spigot, based on Bukkit; and Mojang wasn't going to deal with APIs and open-source stuff for a long while afterwards. (They did later try purchasing parts of OptiFine, but the developer wanted compatibility to be all-or-nothing which Mojang wouldn't accept.)
https://www.reddit.com/r/Minecraft/comments/6g1tqn/psa_no_bu...
https://blog.jwf.io/2020/04/open-source-minecraft-bukkit-gpl...
https://www.reddit.com/r/Minecraft/comments/2fk5nn/my_respon...
Data packs and resource packs certainly seem very promising as a modding API, but it still seems the devs are artificially restricting their usage.
My insanely biased impression based on my experience is that this is just the norm for Windows-centric development. Generally you have no expectation of being given access to source code at all; if software is free then it's "freeware", but for whatever reason the developers don't generally want you modifying it. So many power user tools just died out when their developers quit working on them because the source code was not available, at least not under a free license.
I remember back in the early days of Minecraft (beta+ era) I'd just go on the forum and download random jar files uploaded by whomever, and mod Minecraft with them. Nobody asked for source code. Or thinking about doom9, for years and years the norm for tool development was that you'd download a random exe from someone on a forum, with a single thread for "support". If they disappeared one day, that was it. That's also the way a bunch of Android stuff is/was developed on xda-dev.
The more Linux-centric set of norms has expanded outward into a pretty robust open source ecosystem, but it's by no means the universal norm for free (as in beer) software development. Even in cases like Paper / Bukkit where the source is free, building the software yourself is very much not the norm, often is not even supported.
I remember hearing an explanation from one such solo developer with a relatively recognizable brand that he doesn't want people to be able to easily replicate his tools with added malware / adware. But I feel like download sites have been doing that for years anyway.
He has released at least one tiny but useful piece of code as public domain.
Also he does have one product that charges for. I suppose one potential reason to keep code private is to maintain more control of the free tools for purposes of branding and bringing attention to the pay tool? That's just a thought.
I think this has to do with the way that ultimate, true upstream involves the closed source Microsoft components. None of these servers seem to be built from the ground up, each extending an existing package (closed or open source) in one way or another.
After all these years though it is extremely exciting to see this advancement, I'd expect this to allow extremely large servers. Makes me want to start playing again ^_^
We're not old, the forks just fly by so very fast
Spigot, meanwhile, is run by one developer who only posts his code within a few weeks of a Minecraft launch after working on it completely privately. Paper has examined taking over that role, but has decided against it for the time being until they are ready to fully take on that job because... it's not an easy job and he's basically mastered it (Paper would be much slower if they were doing it themselves for the first few releases). Also he runs the plugin repository and Paper isn't ready to launch their own yet. Also, Spigot and Bukkit have this ancient API that not many plugins use, but a few do... and it'd be nice to not break them.
So Paper is the first remotely reasonable downstream with a big open-source community for it, which then makes it more like... one fork. And even though Paper is technically reliant on Spigot (and Spigot on Bukkit), Paper can really cut them off whenever convenient. And there's a good reason to make Folia a fork - the way it works under the hood is very different than a traditional Minecraft server, and it basically breaks all the Spigot and Paper and Bukkit plugin compatibility.
If you ignore server plugins, the only effort in actually trying to build a modding API is Quilt and it's Quilt Standard Libraries, which you probably guesses further splits the modding community into Forge, Fabric and now Quilt but that is on the Forge and Fabric guys for not even trying.
Java MC's development had always been extremely conservative, and it always will be under Mojang. Its both saved it from going downhill and weighed it down.
And now it has IAPs too?
Both clients/servers have their ups and downs. I do wish they'd release the Bedrock client for Mac/Linux though. Then all platforms would have an official way to interop.
Land claim / griefing protection? Multiplayer sleep? Custom recipes? Dynmap? Multiverse? WorldGuard rules? :)
Edit because I can't reply any more:
> to use a 3rd party bridging solution with it instead like GeyserMC+Floodgate
All that for the privilege of running the Bedrock client on a Mac with Crossover, I guess. Nah, they can keep it. I didn't even claim the free Bedrock when they were giving it free to java owners.
On the server I play we're looking forward to testing Folia so redstone addicts will only lag themselves and not everyone btw.
That said multiplayer sleep, custom recipes, bedrock-viz, and others exist. Customized protection I've found to be lacking though.
But honestly if you're looking at that many 3rd party things you might find it easier to use a 3rd party bridging solution with it instead like GeyserMC+Floodgate. It still has limitations compared to a native java (client, server, mod) tuple but it's probably easier to adapt to if you're used to java server.
https://www.youtube.com/watch?v=rR8W-f9YhYA
... and that is just one mod. There are mods for interplanetary space travel, mods for modular portals and matter-energy conversion, mods for full z height terrain gen and massive premade structures, mods for virtual NPCs and towns, "backend" mods that overhaul the render, light engine, chunk loading and such. You cant get that with simple block APIs (which Java and Bedrock have to a limited extent).
And we do have modding APIs, like Fabric and Forge. They are just unofficial.
That being said, there is a better middle ground between the current extremely limited official APIs and the very permissive unofficial modding APIs, but it will never happen because it would interfere with Bedrock's MTX, and Java's development is too conservative.
Also, Fabric and Forge are not modding APIs. They sometimes provide extra APIs on top of the base game to make mod compatibility easier, but you are very much supposed to just mess around with the Minecraft codebase directly and directly reference Mojang classes in your code. If all you want to do is add a new block in Fabric you don't touch any Fabric API.
That being said, the low hanging mod fruit they could incorporate is often poisoned by GPL or some other weird license.
They have tried to pull in mods before, but unfortunate drama that ensued probably soured them on that idea.
https://github.com/TheUsefulLists/UsefulMods#performance-and...
> So now we have Folia, which is a fork of Paper, which is a fork of Spigot, which I believe was originally a fork of Bukkit. Nice. I guess people don't want to upstream patches for some reason.
Time and effort you put into upstreaming patches is almost always wasted, either you get it included and then have to maintain it forever or it will get removed due to bitrot or developers will just say no and all your effort was wasted. Don't forget that developers might also want to share their opinions about you based on your commit. There is no better way to build community than saying that no one cares about you inside of it.