#—Discontinued—
Apparently sponge already has a nice NBTTranslator built in which you can’t access (yet) unless you depend on SpongeCommon for now. In the comments there was already a project made a year ago with the exact same name. (I didn’t know)
Feel free to do anything with the library you want…
#NBeeT
Hey!
Let’s get straight to it. NBeeT is a Java library that allows users to read and write* to NBT files, even if they’re compressed or not NBeeT handles that for you!
NBeeT is designed for easy use, to show you: You can load a compressed NBT file and get values within three lines of code!
###Reading:
For example if you’d like to load the compressed level_sponge.dat file from a world and retrieve it’s dimension ID you can:
(Code tags were not working for some reason )
###Writing:
* I’m working on the writing part, should be finished in a day or two/three
For a Sponge plugin, there is no reason why they need to handle NBT directly. Plugins pass DataViews around. You should look into DataTranslator, an interface for reading and writing DataViews to some format. That is much better than interfacing with NBT directly.
Ah well, I didn’t make this specificaly for sponge
And I made a world backup manager, which can load worlds from a backup dynamically but it has to change the dimension ID for it to work correctly. I’ve asked in the IRC and there is nothing yet to change the DimensionId without loading the wirld first. (which can’t happen if there is a conflict).
So I think it still has quite alot of use for certain projects.
Or you could’ve exposed an NbtTranslator that was totally already written to handle going to and from DataContainers. The reason I say this is that relying on an implementation detail such as the entire tag system for NBT is silly. The ONLY reason why you have the various tags (such as BeeBooleanTag etc.) is because they exist in NBT. So, I have to ask: Why go through such lengths of having this verbose system when you could use something as simple as the already provided DataView system that already has proven to be cross “serialization” compatible with configurate and NBT?
Well it’s for plugins, but how should one get the NbtTranslator if it’s in SpongeCommon and plugins only depend on the SpongeApi?
And there is no documentation on this topic, and just the comments doesn’t make me understand how it all works. I do my best to find things in the sourcode, but DataView doesn’t make me think, Oh that’s probably NBT
And ofcourse I’m not an advanced Java programmer so I did it too learn more too.
I hope you get my points
If it’s already implemented as to the point where I need it then I’ll just discontinue this.
The thing about DataView is that you should’ve noticed that it has a ton of getters of specific types, right? And better yet, these types can become pretty advanced as well, such as List<T extends DataSerializable>. The reason why it’s not advertised or documented as an NBT replacement is because it’s not. It’s an in-memory data structure that can hold anything and everything you wish it to hold. There is no reason why it can’t be used to represent data found in NBT, let alone be translated back and forth to NBT.
Which brings me back to my original point: Why not just expose a Translator that uses NBT as a backend storage, but returns types of DataContainers/DataViews?
It’s far easier to read this:
final DataContainer container = NBeeTTranslator.loadFile("level_sponge.dat", true);
final int dimId = container.getInt(of("dimensionId")).get();
But to expose it don’t I need to make changes in the SpongeApi? I don’t mind doing that, but it doesn’t feel right, since I’m not confident enough that I’ll do it the right way
No, what you would need to do is add SpongeCommon as a dependency when you compile the library. The plugins using your library will not need to do this because SpongeCommon is only used indirectly, and will be provided by the server implementation running the plugins. Your plugin just internally uses NbtTranslator instead of a standalone NBT parser.
HOWEVER I don’t recommend exposing NBT regardless. Especially not opening sponge_level.dat, which is an implementation detail to the way sponge handles worlds, and if accidentally modified could easily cause worlds to stop loading until deleting sponge_level.dat which may contain important data.
Oh okey!
I thought adding SpongeCommon as a dependency wasn’t a good thing to do, that’s why I didn’t came up with it.
All I need to do to the sponge_level.dat is change the dimension id of worlds I’m going to load. But I’ll remove this thread as it seems unuseful for anyone.
The world ID changing to load copies is being added via the API. As for using SpongeCommon as a dependency yes that’s almost always a bad idea. But the only way to do what gabizou suggested is by adding a SpongeCommon dependency.
FYI, if you depend on SpongeCommon, you have to use ForgeGradle to compile your plugin/library since you’d still be relying on NBT from internal implementation of Minecraft.
Right: Let’s just convert the entire Gson library over to data API, because a Json[XXX] is just an arbitrary type and exposes just a bunch of random stuff.
Sorry, I just found your tone just a tad bit harsh on tim.
Lol, that’s why I should lookup names before I make something xD
I didn’t know that existed but I could’ve guessed it.
I just leave my NBeeT as it is, I won’t develop if further since (apparently) sponge already has a good NBT translator built in.
And because there is already a NBeeT library, that basically does the same thing as I do but probably better.
)
