Currently, this plug-in is rather complicated to install (requires the right java installation and a lot of different files and plug-ins). I think all of this could be solved by changing 2 things:
Let Editor.jar generate CustomItems.jar upon exporting
I would only publish Editor.jar and notCustomItems.jar. Since KnokkoCore is only used for CustomItems and the Editor knows for which version it is exporting, it can include the right version of KnokkoCore in CustomItems.jar, which solves one of the most common problems. It also spares me some file uploading work since I would only need to publish the Editor rather than the plug-in + Editor + all versions of KnokkoCore.
Also, the Editor can include the .cis file in the generated CustomItems.jar, which is 1 less file for the user to worry about. Furthermore, the Editor can include the resourcepack as well and I could add some code to let CustomItems automatically send this resourcepack to my resource pack host. This also avoids the need to update the resource pack manually and find a resource pack host.
Note: the drawback of including the files in CustomItems.jar is that they can't be updated without restarting the server. I should still allow the user to 'override' the files via the plugins/CustomItems folder when doing /kci reload (this could spare experienced users a lot of time).
Publish native executables
I could use some CI/CD setup to automatically generate native executables for Windows and MacOS upon creating a release. (Maybe even Linux, but that's less valuable since Linux users tend to be the most experienced, while Linux is also the easiest operating system to install Java.) I can use something like Launch4J or jpackage to create these executables (requires further research). I would probably publish these releases on Github releases and post a link to them on my plug-in pages (in case BukkitDev and Spigot would appreciate native executables).
Aternos considerations
Since quite some of my users use Aternos, which doesn't allow them to upload arbitrary files to their server, I should check with them whether this system could work. If not, I should create some kind of fallback.
Currently, this plug-in is rather complicated to install (requires the right java installation and a lot of different files and plug-ins). I think all of this could be solved by changing 2 things:
Let
Editor.jar
generateCustomItems.jar
upon exportingI would only publish
Editor.jar
and notCustomItems.jar
. Since KnokkoCore is only used for CustomItems and the Editor knows for which version it is exporting, it can include the right version of KnokkoCore inCustomItems.jar
, which solves one of the most common problems. It also spares me some file uploading work since I would only need to publish the Editor rather than the plug-in + Editor + all versions of KnokkoCore.Also, the Editor can include the .cis file in the generated
CustomItems.jar
, which is 1 less file for the user to worry about. Furthermore, the Editor can include the resourcepack as well and I could add some code to let CustomItems automatically send this resourcepack to my resource pack host. This also avoids the need to update the resource pack manually and find a resource pack host.Note: the drawback of including the files in
CustomItems.jar
is that they can't be updated without restarting the server. I should still allow the user to 'override' the files via the plugins/CustomItems folder when doing/kci reload
(this could spare experienced users a lot of time).Publish native executables
I could use some CI/CD setup to automatically generate native executables for Windows and MacOS upon creating a release. (Maybe even Linux, but that's less valuable since Linux users tend to be the most experienced, while Linux is also the easiest operating system to install Java.) I can use something like
Launch4J
orjpackage
to create these executables (requires further research). I would probably publish these releases on Github releases and post a link to them on my plug-in pages (in case BukkitDev and Spigot would appreciate native executables).Aternos considerations
Since quite some of my users use Aternos, which doesn't allow them to upload arbitrary files to their server, I should check with them whether this system could work. If not, I should create some kind of fallback.