What feature of the API do you think doesn’t get enough attention from plugin devs / users?
The extensibility of the command API. When I’m making a plugin with commands that GenericArguments doesn’t solve, I generally make new CommandElements to suit my purposes (and made a library for, and did a couple PRs for which unfortunately got swallowed by the brand new API). But nearly every plugin I’ve looked at, if they do something that the base can’t handle, they’ll just stick with GenericArguments.string() and parse it in the command executor, going right back to Bukkit-style tactics.
7 Likes
Creating own custom data. I think it could be used more. DataManipulatorGenerator by @pie_flavor does a great job to simplify creating custom data, but it is still a lot of code that may seem too complicated to use it in a productive way.
1 Like
The generator is a horrible kludge of string concatenation. Somehow I doubt the efficiency of a system which requires three classes with solely boilerplate implementations to store a single string. I can’t wait for that class-generation thing @gabizou was talking about.
5 Likes
I would say it could be Custom data but since theres no byte code generation layer we are forced to write lots of boilerplate and its documentation is lacking.
1 Like
I very much enjoy the ability to add custom data to entities, tile entities, etc., but what I have always missed was a consistent way of assigning custom data to blocks. I’ve used workarounds such as placing an invisible armor stand at the location of the block and assigning custom data to that armor stand, but this solution brings obvious downsides.
It would be more than convenient if there was a standard way to assign custom data to any blocks (not just tile entities) via the Sponge API. I propose the following: Since there is a way to store data about the history of blocks (who placed / destroyed it), why not use this way of storage for custom data? Note that this way of storage would leave the data of tile entities unchanged. Also note that I know close to nothing how the “block history” is currently managed in the internals, so this might not be possible without major refactorings.
Edit: Also, I don’t think this is the “most overlooked aspect”, but I thought I needed to get this idea out there, sorry for kind of hijacking the thread.
That’s fine. The problem with custom block data storage is the efficiency. It’s almost always better for people to come up with their own solutions for stuff that can be as dense as blocks. Fyi the way the block history works is that uuid are mapped to (ints? Shorts?) per (chunk or region file can’t remember which) which allows us to get tight packing and perf. Otherwise for sparse data some sort of custom tile entity would work, but have problems with compatibility. We could keep sparse data in an external file or data section per chunk mimicking tile entities, but if people used them for dense data there would be huge issues.