Well, the problem is that we have to sync every "mouse enter" and "mouse exit" event with the server. This could result in a lot of packets, at least if you have a complex UI
But apart from that, we're still unsure about the future of the API regarding the new engine... we really want to keep old plugins compatible, but that would mean that the new version must cover almost every event and function of the old API... especially the UI will give us a headache (or more precisely, converting Plugin GuiElements to the new engine), so we really prefer to not touch the Plugin GUI part for the time being
Ah yes I see that would mean a lot of packets
I also see what you mean about the API; writing and keeping up a translation bridge between Java and the native API would be a big job.
Are there plans for a new "native API" and if so what language? C#?
(If I need to learn a new language then so be it).
Well, actually we're still racking our brains about the new API For the time being, we will probably implement an "abstract" API, so we don't have to specify a language now (and this approach also allows us to add support for more than one language in the future).
Unfortunately we cannot use C# as API language since we're using the IL2CPP backend (which means there is no Mono runtime to load C# assemblies).
We've been thinking about keeping Java as plugin language, but this would require the user to install a JVM...
It would be easier if we use a script language for the API. Common languages would be Lua or Python. Going back to Lua would be awkward, and it has no support for multi-threading, so Python seems to be a better candidate here.
I hope we can find a proper solution in the next months Nevertheless, it's still our intention to find a way to keep existing Java plugins compatible (although it's possible that they require a few tweaks)
Thanks for the info - I plan to keep developing my plugin but I'll hold fire a little.
As soon as more concrete decisions are made on the API s future I assume well get an official update?