Open Moderocky opened 4 years ago
I think there are multiple possible solutions:
Java support in skript (like skript-mirror). This is good for two reasons. First, it is very nice for quick prototyping. Second, it gets rid of all the very basic addons that just convert java apis to skript expressions.
Writing basic java files that are then loaded/compiled by skript and do not require to be standalone plugins. This would be better than java support directly in skript because it the skript code is not disturbed by weird java syntax in it. It would also allow to get rid of a lot of boilerplate. The issue with this approach is that you do not get any support from your java ide, which will become an issue once you have some functions you want to share between different files and so on...
Better addon api. Did not really think about that yet, but there is certainly potential.
-1 to having a separate addons folder. Many APIs require a plugin instance in order to use and would need to be loaded using the server's standard plugin-loading mechanism anyway. If we allow both, that just adds confusion about whether or not a jar should be placed in the plugins folder or the addons folder.
Yes, a good API should do the job. And a template that you can git clone + a good tutorial would make creating your first addon much easier.
Then there remains the question of java interop in the language itself.
IMO, Skript API would should not be tied to Minecraft in any way. It would be ideal if you could use Skript for adding scripting to any application. For Spigot plugins, I agree with @btk5h; let's not reinvent the wheel with our own plugin loading system.
Supporting Java calls from Skript would allow parts of Skript plugin to be written in Skript instead of Java, which might allow more people to work on it effectively. It could be gated behind a flag in script (or as parameter to Java API used for loading it) so that people who have zero knowledge in Java do not use it.
Making an addon is currently not a small task, particularly the first time. This is mostly due to how complex all of the boilerplate tasks are, such as all the bits of registration.
On top of this, some addons have very standard (see sk-nbeet, skript-npc, etc.) and others have some more complex parts (see skellett, Tuske to some extent and Skript-mirror, etc.)
I suggest that addons should not be standalone plugins, but instead put in a /Skript/addons/ folder. The boilerplate processes should be simplified a lot, to make registration of events, effects, types (especially) etc. simpler and to better handle priorities and configs. This would also mean that addons would work through the Skript plugin and should be generally more standardised.
Any more ideas in this vein would be welcome.