Hiya Spongineers! (Can I say that? Is that trademarked? Please don’t kill me. I have a family.)
I’ve been working on putting together a simple plugin to hold some of the different things I find myself doing in many of my plugins, if not all. I originally planned to just copy-paste things over and call it a day, but I realized that this is something that many others could make use of as well. As such, I’ve gone ahead and begun working on implementing some of these different parts.
Currently, here are the ideas I’ve been working on implementing. The check doesn’t mean they’re complete, but the foundation is present.
-
Wrap a Configuration loader with the respective node, for saving
-
Message system for changeable messages through a config file
-
Translation system based of the users set language
-
Process cooldowns and save data to a config file
-
Wrap the slf4j logger to add a debug mode and save logs to a file
-
Basic gui system to easily create static inventory views
-
Animation system for guis, particles, and block selections
-
Common Configuration serializers and deserializers
-
Slightly-less GenericArgs for common argument patterns
And of course, any other ideas people can come up with!
The repository for this projects can be found on GitHub: LibraryAPI. If you’re interested in supporting the project, feel free to review what’s there, create/respond to issues, or add something to the discussion below!
This might be useful for some people but I’ve seen enough developers creating a lib themselves(myself too). I don’t think there would be too many devs using one lib.
My contribution: kosp/PlayerExecutedCommand.kt at master · randombyte-developer/kosp · GitHub
Most of ‘kosp’ is just nice Kotlin stuff for Sponge(like ‘kludge’ by @pie_flavor). The Configurate serializers and the object mapper might be interesting: date, duration, text, TextTemplate… Serialization and automatic hyphen separated config keys.
1 Like
I have plans to design a professional particle lib as part of my software engineering class project.
I’d suggest that incubating pre-existing community projects that already do these things (like HuskyUI) would be a better move, but that’s really up to you.
1 Like
I agree here with you regarding inventory(husky ui), text ui(@simon816) and some future particle lib. But like additonal Configurate serializers are nice.
1 Like
I think it would be useful to integrate with PlaceholderAPI from the get-go to support placeholders for messages and other plugins using this. Things like translations and message systems would probably be able to use the api quite effectively, and I’ve gotten it to the point where it would only be a few lines of code on your part. (I could contribute the code myself if you would prefer).
Another thing I think might help would be a GitHub repo for this project, especially during the starting phase; that way people can contribute faster and provide feedback more directly to the code you write.
1 Like
Working to implement existing community projects is definitely something to discuss, but I think we should also consider any improvements that could be made as well - no sense in repeating something that already exists!
My focus for the meantime is on the things I know I’ll need for my plugins (which I why I started this in the first place!), so I’ll start getting some things together and look into create a GitHub repository for it in the next few days. It’s good to know that others are interested in this as well, so I guess we’ll see where it takes us!
… You know that this goes against what people have said, and really what you said moments earlier in your own post?
No it doesn’t. I’m simply stating that I’m willing to consider implementing features from other plugins (with the owners approval of course!) and look into any improvements while doing so.
I then said I’d be starting with the features I know I’ll need for my personal plugins, such as the aforementioned ConfigHolder and the LoggerService. I must say I can’t see a confliction in that at all.
I personally don’t agree with what you want to do in the first bit, but thanks for clearing that up.
I think it would be better to leave the other libraries to their devices and instead maybe shade them into yours, as a way of providing them standard to devs looking to use them. Might not be that good though because it might increase jar size and inflate the project.
Shading other people’s libraries into your public jars isn’t really a good idea.
Indeed. I’d be willing to consider speaking with a developer to integrate their features into the plugin on a case-by-case, but in general it’s simply not worth it for either party involved to do that. I wouldn’t try to replace any existing projects unless there was an extremely good reason, and I wouldn’t think to blend their work in mine like that - especially without permission.
As for the purpose of this, I’m basically writing a library for a system of a plugins I have planned for over the next few months. The purpose of this thread was to get a bit of insight as to whether other developers might be interested in making use of it and ask for some suggestions as well.
I’d like to point out that if there is a simple helper library that MANY plugin developers seek to use, it is time to consider adding the heavily desirable features in question to sponge itself. Husky UI is already starting to fall slowly into this territory, for example.
I’m not saying it should, because the features you listed appear to be limited to use by only a few plugins, rather than all. However, it is something to that I’d like everyone to consider.
2 Likes
I’ve spent the last couple hours Javadoc’ing (can I use that as a verb?) what I’ve come up with so far and tying up any loose ends. I’ve created a GitHub repository named LibraryAPI to house the current progress of the project and allow others to view the existing code. If you’re interested in the project, It’d be a huge help to read over the sections you’re familiar with and offer some advice - I could definitely use it!
As for adding the features into Sponge, I think it’s best to look at things on a case-by-case basis. Once we have the opportunity to get things functional and better understand their usage, we can make an informed decision on whether it’s something that Sponge should implement by default. Everything has to start somewhere!