- Why We Think the Server Should Use Fabric Instead of Paper
- 21 Dec 2020 09:07:17 pm
- Last edited by commandblockguy on 16 Jul 2021 10:14:27 pm; edited 2 times in total
Fabric is a modloader for Minecraft, similar to CraftBukkit or Forge. Although it can’t load Bukkit plugins, it has its own collection of equivalent server-side mods. In our (commandblockguy and _iPhoenix_, who helped write this post) opinion, Fabric is a better option for Cemetech’s Minecraft server than PaperMC, the modloader we’re currently using. Here’s why:
Advantages of Fabric:
Consistency with Vanilla Mechanics:
Paper applies a large number of "fixes" by default. Many of these are useful, like dupe prevention, but others affect the behavior of vanilla mechanics for seemingly no reason. For example, until commandblockguy submitted a PR fixing it, in Paper, blocks moved by a piston were completely indestructible by TNT unless you turned off the option which prevented bedrock breaking exploits. This made it basically impossible to make a TNT blast chamber, a necessary component of many advanced farms.
There are many other mechanical differences between vanilla and Paper, ranging from minor changes requiring redstone builds to be slightly tweaked to massive differences that make some builds like ender stasis chambers impossible. The main issue with these mechanical differences is that the only way for you to know how a particular device will behave is to either build it on the actual server, or to run your own Paper server, with the same configuration as the real deal, to test things on. This can be extremely frustrating when you discover that something you designed and tested in creative mode doesn't work after you've spent hours building it in survival.
Fabric, on the other hand, is a "pure" modloader - with no mods installed, there's no way to tell whether a server uses Fabric or vanilla using in-game mechanics. The Fabric API, a library most Fabric mods depend on, doesn't change vanilla mechanics, either. Even if it did, unlike in Paper, that would most likely be considered a bug and fixed quickly. Many of the Fabric contributors, and most developers of server-side Fabric mods, are expert redstoners for whom consistency with vanilla is a priority.
Performance:
Although Fabric itself does not apply any optimizations to the game, there are several Fabric mods that apply optimizations to the game, including Lithium, Phosphor, and Carpetmod. Lithium can reduce tick times by 45% (about on par with Paper), but without making any changes to gameplay. The two devs behind it, JellySquid and 2No2Name, are literally geniuses. Phosphor, also by JellySquid, optimizes the lighting engine, which greatly speeds up chunk loading.
EDIT: Starlight is a light engine replacement which is even faster than Phosphor and about 35 times faster than vanilla's. It was still experimental at the time I originally wrote this, but is now stable enough to use.
Bukkit Plugins are Kinda Terrible:
The main draw of Bukkit plugins (for devs, at least) is that the API almost never changes. This is extremely convenient for plugin devs, as they don't have to actively update their plugins, but in my opinion ultimately bad for server owners. Much of the game has been rewritten since the Bukkit API was developed. Even just since 1.12, world generation, world storage, chunk loading, commands, block updates, and lighting have all been fully rewritten. Paper must either add wrappers around the new systems for existing plugins to keep working (resulting in worse performance), or make major changes to how the game is implemented (resulting in the aforementioned mechanical differences).
The minimum-effort update cycle of Bukkit plugins also means that they don't really work that well with new features. Just take a look at the command system - none of the plugins that we use work with 1.13's Brigadier autocompletion and error-detection, despite it being over two years old. You also can't run Bukkit plugin commands from inside command blocks, or use target selectors with them, or basically any other feature of the command system that was added after Bukkit introduced commands.
This isn't the only issue resulting from plugins’s development process, of course - WorldGuard lacks options for most modern game events, and respawn anchors just straight-up don't work with our current combination of Multiverse + EssentialsSpawn.
Most of these plugins aren't even that necessary - multiworld support was added to vanilla in 1.16, spawn protection has been in vanilla for forever, and most common Essentials commands can be done with vanilla commands or simple datapacks/command blocks.
Most remaining plugins we use either have Fabric versions (e.g. WorldEdit, Dynmap) or Fabric equivalents (e.g. CoreProtect, WorldGuard, chat linking, Essentials). The Fabric versions of these mods are, in general, better integrated with the base game, and are usually open-source, so if there are any issues commandblockguy or another member can always just fix them.
Fabric Plugins are Kinda Neat:
Fabric mods can use mixins, which allow for a deeper level control of the game than with Bukkit plugins. This is part of why Paper includes so many gameplay changes - it's not actually possible to make most of those with a plugin, so the functionality had to be included in Paper itself. To allow pistons to move chests with Bukkit, you would have to listen for piston powering events, check if any of the blocks being moved is a chest, and then reimplement the piston movement behavior yourself. With Fabric, a mod can do basically anything you could by editing the source code, and just replace the few lines that prevent tile entities from being moved with a few lines that properly handle tile entity movement. In addition to a wider range of possible features of mods, this flexibility also means faster mods, and allows mods like Lithium that optimize the server to exist.
There's a ton of neat fabric server mods, just as there are a ton of neat Bukkit plugins. One of the most interesting is Carpetmod, which has many (entirely configurable) features like movable tile entities, a fully fledged scripting language, the ability to rotate blocks, renewable coral, tools to help debug lag, and a ton of optional bugfixes. All of these features can be toggled at any time by the admins.
Potential Disadvantages of Fabric:
Requires Some Effort to Switch to:
Fabric cannot run Bukkit plugins, so it won't be a drop-in replacement like Paper was for CraftBukkit. Each plugin's functionality will need to be replaced with an equivalent Fabric mod, which needs to be found and configured. Because Fabric is much newer than Bukkit, much fewer fully developed server mods exist, so Fabric mods might lack the advanced functionality of the Bukkit plugins they replace.
Lack of Permission Nodes:
Fabric doesn't yet have a permission node / groups system like Bukkit does. This makes it impossible to granularly control which players can use a command outside of operator/non-operator.
EDIT: this is no longer the case.
Although it would take a bit of effort to switch to, we feel that Fabric would be a better option for the next iteration of Cemetech’s Minecraft server. Both iPhoenix and commandblockguy will be willing to help make the switch, and as Fabric mod developers will be able to create mods to replace missing functionality.
Advantages of Fabric:
Consistency with Vanilla Mechanics:
Paper applies a large number of "fixes" by default. Many of these are useful, like dupe prevention, but others affect the behavior of vanilla mechanics for seemingly no reason. For example, until commandblockguy submitted a PR fixing it, in Paper, blocks moved by a piston were completely indestructible by TNT unless you turned off the option which prevented bedrock breaking exploits. This made it basically impossible to make a TNT blast chamber, a necessary component of many advanced farms.
There are many other mechanical differences between vanilla and Paper, ranging from minor changes requiring redstone builds to be slightly tweaked to massive differences that make some builds like ender stasis chambers impossible. The main issue with these mechanical differences is that the only way for you to know how a particular device will behave is to either build it on the actual server, or to run your own Paper server, with the same configuration as the real deal, to test things on. This can be extremely frustrating when you discover that something you designed and tested in creative mode doesn't work after you've spent hours building it in survival.
Fabric, on the other hand, is a "pure" modloader - with no mods installed, there's no way to tell whether a server uses Fabric or vanilla using in-game mechanics. The Fabric API, a library most Fabric mods depend on, doesn't change vanilla mechanics, either. Even if it did, unlike in Paper, that would most likely be considered a bug and fixed quickly. Many of the Fabric contributors, and most developers of server-side Fabric mods, are expert redstoners for whom consistency with vanilla is a priority.
Performance:
Although Fabric itself does not apply any optimizations to the game, there are several Fabric mods that apply optimizations to the game, including Lithium, Phosphor, and Carpetmod. Lithium can reduce tick times by 45% (about on par with Paper), but without making any changes to gameplay. The two devs behind it, JellySquid and 2No2Name, are literally geniuses. Phosphor, also by JellySquid, optimizes the lighting engine, which greatly speeds up chunk loading.
EDIT: Starlight is a light engine replacement which is even faster than Phosphor and about 35 times faster than vanilla's. It was still experimental at the time I originally wrote this, but is now stable enough to use.
Bukkit Plugins are Kinda Terrible:
The main draw of Bukkit plugins (for devs, at least) is that the API almost never changes. This is extremely convenient for plugin devs, as they don't have to actively update their plugins, but in my opinion ultimately bad for server owners. Much of the game has been rewritten since the Bukkit API was developed. Even just since 1.12, world generation, world storage, chunk loading, commands, block updates, and lighting have all been fully rewritten. Paper must either add wrappers around the new systems for existing plugins to keep working (resulting in worse performance), or make major changes to how the game is implemented (resulting in the aforementioned mechanical differences).
The minimum-effort update cycle of Bukkit plugins also means that they don't really work that well with new features. Just take a look at the command system - none of the plugins that we use work with 1.13's Brigadier autocompletion and error-detection, despite it being over two years old. You also can't run Bukkit plugin commands from inside command blocks, or use target selectors with them, or basically any other feature of the command system that was added after Bukkit introduced commands.
This isn't the only issue resulting from plugins’s development process, of course - WorldGuard lacks options for most modern game events, and respawn anchors just straight-up don't work with our current combination of Multiverse + EssentialsSpawn.
Most of these plugins aren't even that necessary - multiworld support was added to vanilla in 1.16, spawn protection has been in vanilla for forever, and most common Essentials commands can be done with vanilla commands or simple datapacks/command blocks.
Most remaining plugins we use either have Fabric versions (e.g. WorldEdit, Dynmap) or Fabric equivalents (e.g. CoreProtect, WorldGuard, chat linking, Essentials). The Fabric versions of these mods are, in general, better integrated with the base game, and are usually open-source, so if there are any issues commandblockguy or another member can always just fix them.
Fabric Plugins are Kinda Neat:
Fabric mods can use mixins, which allow for a deeper level control of the game than with Bukkit plugins. This is part of why Paper includes so many gameplay changes - it's not actually possible to make most of those with a plugin, so the functionality had to be included in Paper itself. To allow pistons to move chests with Bukkit, you would have to listen for piston powering events, check if any of the blocks being moved is a chest, and then reimplement the piston movement behavior yourself. With Fabric, a mod can do basically anything you could by editing the source code, and just replace the few lines that prevent tile entities from being moved with a few lines that properly handle tile entity movement. In addition to a wider range of possible features of mods, this flexibility also means faster mods, and allows mods like Lithium that optimize the server to exist.
There's a ton of neat fabric server mods, just as there are a ton of neat Bukkit plugins. One of the most interesting is Carpetmod, which has many (entirely configurable) features like movable tile entities, a fully fledged scripting language, the ability to rotate blocks, renewable coral, tools to help debug lag, and a ton of optional bugfixes. All of these features can be toggled at any time by the admins.
Potential Disadvantages of Fabric:
Requires Some Effort to Switch to:
Fabric cannot run Bukkit plugins, so it won't be a drop-in replacement like Paper was for CraftBukkit. Each plugin's functionality will need to be replaced with an equivalent Fabric mod, which needs to be found and configured. Because Fabric is much newer than Bukkit, much fewer fully developed server mods exist, so Fabric mods might lack the advanced functionality of the Bukkit plugins they replace.
Fabric doesn't yet have a permission node / groups system like Bukkit does. This makes it impossible to granularly control which players can use a command outside of operator/non-operator.
EDIT: this is no longer the case.
Although it would take a bit of effort to switch to, we feel that Fabric would be a better option for the next iteration of Cemetech’s Minecraft server. Both iPhoenix and commandblockguy will be willing to help make the switch, and as Fabric mod developers will be able to create mods to replace missing functionality.