DevSrSouza/KotlinBukkitAPI

Outdated Bukkit API

Opened this issue ยท 16 comments

CDFN commented

Any reason why Bukkit API is very outdated in this project? I think it should be latest version, but I guess there's valid reason for it being outdated. If it isn't intentional, I could PR version bump for it.

KotlinBukkitAPI is focus on long version support, the reason behind this is that currently on minecraft community we have a bunch of servers running at 1.8 because of the pvp and performance stuff. 1.13 e specially 1.14+ make the server so lag with low player count.

The player community is still focused on 1.8 and I don't want to stop supporting this type of server.
I really like to work with newer version, this is why KotlinBukkitAPI Tooling has all Server Versions supported, but the focus is to support 1.8 and higher.

I want to KotlinBukkitAPI & Bukkript to be used to speedup development in any version, for any server, hobby or professional, this is why KBAPI is in 1.8+.

I'm planning to add new versions APIs extensions in the future, but, currently, I do not have time to work on it.

And this why I support down from 1.8.

Others 2 reasons:

  1. If I recall Hypixel still run at 1.8 and a bunch of others big servers.

  2. I don't want developers not choosing KBAPI because it does not support 1.8, 1.9, 1.12, etc.

CDFN commented

So, another branch for latest would be fine? If so, I could try to update it

Any version above 1.12 is too slow to be reliable in big projects. However I think it'd be cool to have a KBAPI that's built on top of newer versions of the game because the API is far better than the 1.8 one.

CDFN commented

Completely agree :)

It should have (I think it has) a layer of abstraction for implementing another server platforms. So in the future Sponge, for example, and other minecraft versions/platforms could be easily implemented.

So, another branch for latest would be fine? If so, I could try to update it

KotlinBukkitAPI is an API and a Plugin, is not a new implementation on top of spigot or something like this, is just a API that your plugin will implement, with this in mind, KBAPI works fine in newer versions, the only thing is that, the new APIs like: sendTitle built in the Spigot in the newer versions do not have Extensions for example, this is the only downside, that currently I do not work on extensions from new APIs, just that, but KotlinBukkitAPI will work just fine in the new versions, and if some extension does not, open an issue to me fix it or create a PR.

It should have (I think it has) a layer of abstraction for implementing another server platforms. So in the future Sponge, for example, and other minecraft versions/platforms could be easily implemented.

This is something that was already asked for, but is so hard to maintain, and I do not have resources to work more time on KBAPI, if one day, I could live of Open Source project will be awesome, until then, I this ideas are good but is so much thing to do and is hard to maintain. This is why KBAPI does not ship any NMS stuff, because maintain it from the 1.8 to the 1.16 is really hard and it will consume my time when I could be doing other projects like Bukkript and KotlinBukkitAPI Tooling.

Other plugins do this approach, like WorldEdit and WorldGuard, but the API get more complex to use and it's not what I want now with KBAPI.


Lastly, the KotlinBukkitAPI is suppose to be an API for your plugin from 1.8 to 1.16, you should be able to choose what range you want to support down from 1.8 using it.

Right now Kotlin Bukkit API works fine from 1.8-1.16, glad that bukkit didn't change most thing

CDFN commented

Accidently closed this, sorry. Yeah, I'm currently using it with 1.16.3. Works absolutely fine (except it complains about not specified api-version)

Accidently closed this, sorry. Yeah, I'm currently using it with 1.16.3. Works absolutely fine (except it complains about not specified api-version)

I will specify the supported version in the README.
About specific APIs for the new versions, it is something that I was thinking about days ago and I have some idea how I will do this, this will not have much maintenance cost because what was added to the APIs I don't need to recreate, this is not the case for NMS APIs.

Supporting other servers like Sponge, would be a lot of work, because currently it doesn't have an abstraction that will support other servers easily. And the name is KotlinBukkitAPI.

CDFN commented

Supporting other servers like Sponge, would be a lot of work, because currently it doesn't have an abstraction that will support other servers easily. And the name is KotlinBukkitAPI.

Name is only the name, always can be changed :) But abstracting away this project would be hard imho.

About a PR @CDFN adding the extensions, I will create the new api module strucutre in the next days and would be awesome if you could make PR with Extensions for the new APIs

CDFN commented

Sure, is there any list of these? To be honest, I just started using KBA, I don't really know how it works internally yet.

I don't have any list in mind of what is needed, but, I usually do stuffs for KBAPI this way:

Developing a plugin using KBAPI and I find a some Spigot or Paper API call that could have an extension to make it easier, and I add to KBAPI, just that.

After I create the new module structure for new versions, you can make a PR adding an extension or request in a new issue.

KBAPI have more complex stuffs, but related to newer versions, I guess it all extensions that is needed, I don't have in mind any complex API that was added to the new versions, is not like Menus or Commands that have DSLs.

I'd recommend just creating another branch calling it whatever Minecraft version they are specified for...

Instead of just waiting it out, I can understand the complexity of a API that can manage to get mixed up or something was to happen due to versioning, but this is why GitHub is where you post versions of your API to contribute toward.

I have also noticed Spigot & Bukkit don't support coroutines for some odd reason!
I suppose, It's because its such a old java language or something...