You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I am sure that there is a reason why commands are registered and automatically managed under the loader's hxp command, but I think it would still be a lot better if developers could register their own commands at the root level.
Describe the solution you'd like
I don't know if it's possible, but if it is, it would be great if developers could provide plugin.yml and register commands at root with that. just like it is done in ScalaLoader for minecraft plugins written in Scala.
The text was updated successfully, but these errors were encountered:
When creating this API I spent a lot of time into finding a possible way to achieve this. But there are a few problems that lead to the decision of making it managed under the main hxp command.
The first problem is that the Haxe Minecraft API does not know about any of the Java classes/interfaces. So Haxe based plugins do not extend the JavaPlugin class and are not loaded the same way Java or Scala plugins are loaded. Instead, they are loaded via their own interface by the HaxePluginLoader. I've never used the ScalaLoader, but looking into the source code it seems that these plugins are loaded (essentially) by making them implement Spigot's Plugin interface and overriding the PluginLoader. The ScalaLoader however, also uses a weird hack to override the default JavaPluginLoader.
The second problem is that plugin commands need a PluginDescriptionFile instance to define the commands. The PluginDescriptionFile is set from the values of the plugin.yml when the plugin is loaded and can normally not be modified afterwards at runtime. If this object could be modified it would be possible. Overriding the PluginLoader like the ScalaLoader does solves this issue as it can return its own implementation of the PluginDescriptionFile at runtime.
The third problem is that Haxe based plugins are created via the --java flag, which generates a jar file and does not allow you to include a plugin.yml, or any other file for that matter, into it. This could maybe be resolved by some post-compilation script though.
If the hack that the ScalaLoader uses is not necessary (which might be the case) I will look into making an adapter for the Plugin and PluginLoader interfaces and see if I can load Haxe plugins with commands being added at root level. This also resolves the third problem as the plugin.yml is not necessary then. I can't make promises as there is a lot that could go wrong but in the best case outcome commands could be used both at root level and from the hxp command.
Is your feature request related to a problem? Please describe.
I am sure that there is a reason why commands are registered and automatically managed under the loader's
hxp
command, but I think it would still be a lot better if developers could register their own commands at the root level.Describe the solution you'd like
I don't know if it's possible, but if it is, it would be great if developers could provide plugin.yml and register commands at root with that. just like it is done in ScalaLoader for minecraft plugins written in Scala.
The text was updated successfully, but these errors were encountered: