TeslaLibs - Developed by Simon_Flash ([email protected])
Current Version: 1.0.0
GitHub | Download | Wiki | Support Discord
Features
- Lightweight, customizable GUI library
- Easily handle messages and translations
- Basic configuration utilities
- Gui animation handlers
Users
If you’re running any Tesla plugins, you should already have a version of TeslaLibs contained within TeslaPowered. If you’re only here for TeslaLibs, you can find the available versions here.
Developers
TeslaLibs offers a library for many features used throughout plugins that are difficult or costly to implement independently. By using TeslaLibs, you can save yourself a lot of agony and boilerplate code to implement things such as guis, translations, and more. When you’re ready to get started, you can find an introduction to the available modules on the wiki!
Contributing
If you’re interested in contributing to TeslaLibs, you’re more than welcome to set up your own fork and begin working on a pull request! However, if you’d like a bit of feedback before you get started you can create an issue or talk with me in the #teslalibs channel on Discord - I’m always happy to help!
If you have any questions or would like to provide some feedback or suggestions feel free to leave a message below! I’m really excited to get this project out to the public and I hope that some of the community will be able to make use of it!
6 Likes
I still will never understand why you take a version-only commit pattern over a commit frequently approach to git. Keeping people in the dark for upcoming changes, especially for a public library you intend for others to use, is rather challenging for other developers to keep up with.
My preference for commits for each version is one I’ve decided upon and am comfortable with for my private projects. Projects that are public and intended for others to review and contribute to have commits based on specific features or updates being worked on, as shown by my work on Magnetar.
While you have a good point, it is wrapped and shrouded in the hostility of your comment. I would also appreciate it if you don’t jump to conclusions simply so you may have an opportunity to criticise me.
It really isn’t me being hostile. I have no issues with you and I think I’ve made that pretty clear by now.
Not exactly sure what I said that “shrouded” my comment in “hostility”, but believe what you wish.
Most prototyping stage git history before an initial version is near useless anyway.
It’s the commits going forward that matter.
1 Like
That was my point, really.
I’ve created a new PR for the CommandService and command library, which is one of the remaining major features I have planned for TeslaLibs. I’d like to ask for anyone interested in it to take a look and leave some feedback. If you’re interested in helping out, the PR can be found here. Thanks!
Hello hello! It is still a wonderful Tuesday for me (I’ll hope it lasts!) and I’ve got a couple new additions here to point out.
First, TeslaLibs is now available on API 5, 6, and 7 - so if you’re doing your best Marty McFly and are stuck in the dark ages, at least now you’ll be able to have a little bit of light.
This is also the first release to include the CommandService, which manages all of your command instances and provides a builder-like settings usage or an annotation based approach depending on what you prefer. I had a lot of fun playing around with the system to construct some pretty crazy command hierarchies, so I hope that some other developers will have the opportunity to make use of it.
Now, let’s talk about where TeslaLibs is going from here. One of the largest things I’d like to do is get a series of utility classes set up for common actions with items, texts, and so on (you can see the NodeUtils class for an example). I’m going to adhere to the Guava principle utility times ubiquity on this one to make sure I’m not going overboard with things. If you have any suggestions for what you’d like to see in the mix, feel free to let me know or even start up your own PR if you feel like it!
Next, I know I want to look into providing a series of serializers and other tools for working with Configurate better. I’ll be migrating the custom ItemStack serializer I built for TeslaCrate (shown here) in the process, and I know that’s something that’s been wanted by anyone who’s ever tried to have an item in a config.
Finally, I have also been considering a system that stores things like items and commands for offline players until they’re online and provides some other securities so plugins may give these to the player with 100% certainty that they won’t be wastefully consumed in that process. I’ve got a system for this in mind that I haven’t taken much further than an alpha test, so let me your thoughts if this would be something you’re interested in.
That’s all for now, so keep an eye out for these projects coming to TeslaLibs in the next few weeks!
Hiya all! I’ve opened up a new PR on the GitHub for an argument parsing system I’ve been working on. After having started the code for this back in September, I’m happy to have finally gotten things stable where it won’t be rewritten a bunch of times (sigh). If you’re interested in it, I’d encourage you to take a look!
Of course, it wouldn’t be much fun without showing off some examples of how things work, so here are two of my favorites:
// a quantity (integer within 1 - 64)
Arguments.integer().inRange(Range.closed(1, 64)).toElement("quantity");
// the UUID of a provided Player or the CommandSource
Arguments.player().orSource().toUuid().toElement("uuid");
There’s still a lot of work to be done with this before it’s merged into TeslaLibs, but if you’d like to speed things up feel free to provide some feedback on the PR or any suggestions you have for how this can be improved. Here’s to a great 2018! 
Honestly I’d like to see a system like this implemented into Sponge itself. There isn’t a real reason why it couldn’t, or shouldn’t be. Really easy, specific argument creation should be possible.
There’s always the Command Refactor (ofc, API 8 instead of 7), but the largest piece I wanted was the generics so I could chain things like Arguments.integer().inRange(...), which I brought up at this past State of Sponge. Once builds for API 8 start coming out and I can play around with the system more I’ll be looking into PR’s for some of this.
1 Like
Right, now I see what you were getting at. You want contextual modifiers for ValueParameters, which would require the Parameter.Builder to be generic. In the refactor, ValueParameters et. al. are already generic, so that confused me during SoS - you want a generic ValueParameter to affect what additional generic ValueParameterModifiers are available. That wasn’t clear before, so right, that makes sense now.
I see the value in such a proposal and may play about with what I’ve got. There are some things I’m not happy about with my current branch so I’ll look at rolling changes like this into it. The largest challenge is due to the separation of API and impl and so writing it in such a manner that doesn’t leak impl details.
2 Likes