More streamlined API
Opened this issue ยท 1 comments
I while ago I worked on a rewrite of the trinkets API from the ground up to streamline the whole thing and implement layers of inheritance to make it more customizable depending upon the use cases. I never finished the rewrite, but a solid 75% of it was done so there might be some ideas for a v3 of trinkets.
This issue can be closed immediately, I just didn't know where else to put this message other than a PR, and as the code was not completely ready a PR seemed improper.
Here's a link to the forked repo with the changes in it... link
There's also a README file that explains how developers would use the api to get a better idea of how exactly the rewrite was supposed to function... link
Again, this issue can be immediately resolved, and obviously there's no obligation to use any of this I just wanted to make sure it was on your radar in case you were interested.
There's definitely a lot of cool stuff here I'm gonna take inspiration from and read into more deeply in the future but there is also a huge problem, at least for me, in the way you designed some things. Slots being a class definitely expands on their functionality, which is neat. However, one of the main reasons I created trinkets is because in forge modding environments, there are like 20 different forms of accessories and it seems like every mod had its own duplicate slots (multiple belt slots, many ring slots, etc.) and because of this I wanted multiple mods that implemented trinkets being able to share the same slots for a more cohesive modding experience, like things were actually made to work together instead of a bunch of things cobbled together stepping on each other's toes. For this reason, I'd much rather go with a group:slot identifier system. Thanks a lot for letting me know about this!