-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Wellspring is designed to give content creators direct access to edit and add to the Minecraft registry - the 'wellspring' of the game's content.
This includes using internal features that are not accessible in upstream server platforms (such as Spigot and Paper) as well as allowing plugins to modify normally-constant values at runtime to better control their environment.
- To provide new accessibility and options for plugins
-
- Example: Automatic package re-mapping for the current NMS version
- To remove the need for reflection and version-dependent code
-
- Example: Packets/NBT library for accessing those features
- To allow access to Minecraft features that Bukkit overlooks
-
- Example: NBT, packets, attribute/potion type creation
- To provide new features and potential for plugins
-
- Example: attachments, enchantment attributes, etc.
- This is not for altering or changing the vanilla game
-
- Example: we will not "improve" the default pathfinders
- This is not for patching vanilla bugs - that is Mojang's job
-
- Example: we would not create a temporary patch for a vanilla bug
- This is not for 'speeding up' the server or improving performance
-
- Example: we would not alter entity ticking to be more efficient
Where possible, Wellspring aims to remain consistent with Bukkit/Spigot/Paper ("Upstream") so that, for example, a Spigot plugin would work on a Wellspring server. However this will not always be possible. In order to make some features functional and easy-to-use, this requires changes to Upstream classes that could potentially break plugins in edge cases.
Example:
The plugin 'Skript' relies on the
org.bukkit.attribute.Attribute
class extendingEnum
. Wellspring changes this to allow for custom attributes to be registered. The alternative was to abstract the class, which would require changes to 31 other classes and would be a lot more breaking. As such, Skript would encounter an error when trying to load on a Wellspring server.
Where possible, these cases are minimised, either by creating workarounds or trying to preserve the original erasure of the class so that plugins relying on it (possibly by reflection) would still be able to work.
We are looking into better ways to preserve this compatibility, such as re-mapping Spigot plugins at runtime, or fiddling with class-loaders. This will be a long-term project.