-
-
Notifications
You must be signed in to change notification settings - Fork 2
Description
It's been a while since Rtag appeared as a "new and revolutionary API" with zero popularity (and still near zero right now), the main reasons to create an API to edit NBT objects was the absence of competition between libraries, the most popular one being too heavy for servers with more than 80 online players, every single "i'm gonna make my own core" developer making an insane amount of version modules and early-dropping version compatibility in general.
I wake up some day and say "man, every single NBT object is just a Java object", and that is, Mojang only uses NBT as an abstraction of Java objects to provide more methods to save/load that data directly to/from bytes.
So my question was "Why should I use a lot of methods that change in almost every version?" When I only need to put or get a Java object in a Map or List.
The development started as a library focused on ItemStack data with some kind of cool methods to handle deep paths and gson-like serialization, something new 3 years ago.
The Problem
Minecraft has changed a lot in the past 3 years, and Rtag is being moved from "a decent API" to "okay, that is another option".
There are some important stuff that is not completely covered by Rtag like Codecs and data components, PaperMC being a more accessible way to make simple edits and the usage of better hardware on Minecraft servers making people don't care about heavy reflection usage.
Actually, Rtag is only attractive by:
- Providing easy-to-use methods for complex data structures.
- Direct call-like performance for reflected methods.
- Data component serialization.
SkullTextureutility class (that isn't even related with NBT).
So what?
In the past 3 years I developed some libraries that are "born" from Rtag, that expands the usage of some specific concepts.
At this point, Rtag is pretty much like a data-related API and a bridge between Bukkit and Paper.
So my idea is to make Rtag a bigger library, not only to edit some objects in a Minecraft server, a library that covers Minecraft data in general.
Adding the two mentioned libraries as required dependencies, creating a more consistent data transformation and making Rtag compatible with every single platform and every single Minecraft version that use NBT data format.
Disadvantages
- The Rtag dependency will be heavier (Since it will require 2 other libraries to work).
Advantages
- Multiplatform support.
- Extensive bidimensional data transformation (upgrade and downgrade versions of every single data object from Minecraft and also some well-known formats like schematics).
- Extensive java types usage.
- Compatibility with more server objects like chunks.
- Better cross-version reference.
In general
I will NOT change the current usage of the API, so you can still use Rtag without thinking about breaking changes.
The development of these changes will start on 1.6.0.
Any suggestion and recommendation is appreciated.