What I learned

    Finally got it to compile! So one thing missing from the examples that Red posted include was how to set up the import statements for Listener. Here's a more complete example of a simple listener event. I also learned that in Netbeans that its better to select "Java Class" as your project type, not "Java Application". The difference is an application has to have a class identified as the main class and must have a main method. However the "Java Class" is great if your writing a small plugin which is exactly what we are doing here! However, for testing purposes you can still include a main method (like below) but it doesn't have to do anything. This is still good if you want to test the application on its own. Not sure how we do that unless someone knows how to trigger events.



    To test the class on its own you can modify the main method like this to create an instance of itself. Of course this wont do much because this is event driven so the message will never display:



    Java
    public static void main(String[] args) {

        mod newMod = new mod();

    }

    Finally you just build the jar. Make sure your package matches the package line in the source code. Simply right-click on the package and compile it. Then browse to where your project is saved on your drive and find the jar file under dist


    http://imgur.com/a/1aKBW



    To install the package, I'm still a bit confused about. Red51 said your probably just drop a jar into scripts or plugins. The process seems not entirely finalized so I'll just play with it more for now. My work computer can barely handle running Rising World even at absolute minimal draw distances.

    Quote from zfoxfire

    Finally got it to compile!

    Great, congratulations! :thumbup:


    Quote from zfoxfire

    one thing missing from the examples that Red posted include was how to set up the import statements for Listener

    Yeah the examples don't include the imports. The easiest way to import the necessary classes is to let the IDE handle it (e.g. in NetBeans, when it complains about missing imports, you can click the small light bulb on the left and hit "Add import for net.risingworld.api...." (sometimes other default java packages have classes with the same name, make sure to always choose from the "net.risingworld.api..." packages).
    Maybe it makes sense to add the imports to the examples, however, I hope it does not give the impression that exactly these imports are always required ^^


    Quote from zfoxfire

    its better to select "Java Class" as your project type, not "Java Application"

    Bascially that's true, but what do you refer to exactly, the "Java Class Library"? When it gets created it does not contain a class at all, so I thought it's more convenient if there is already a class (optionally you can just remove the main method).


    Quote from zfoxfire

    Red51 said your probably just drop a jar into scripts or plugins

    Yes, probably every plugin will have a separate subfolder, can't say for sure. Of course we're always open for suggestions^^

    Thanks for reporting your findings, @zfoxfire. I personally use Eclipse under Linux, so most of it is not directly applicable for me, but it is always interesting to hear about other people experiences.


    I am a bit surprised about the need to fix the imports with NetBeans, Eclipse manages them automatically, or suggests the proper import, as soon as you use the implements keyword.


    About testing the plug-in, of course this is not possible now, until a plugin-enabled version of the server will not be available (soon... :evil: ).

    Quote from red51

    Yes, probably every plugin will have a separate subfolder, can't say for sure. Of course we're always open for suggestions^^


    For what is worth, I would greatly prefer a separate sub-directory for each plug-in to be a requirement (with only second-level directories scanned for plug-ins). It avoids any file name clash between the contents of different packages, simplifies the distribution (the distribution ZIP can already include the sub-directory to be directly expanded in the plug-in directory), without any noticeable inconvenient.


    You probably already thought of this: I would suggest using a directory other than scripts for Java plug-ins, to keep the two worlds separate and simplify the transition (and the final clean-up, once the LUA framework will be phased out).

    Quote from Miwarre

    I am a bit surprised about the need to fix the imports with NetBeans, Eclipse manages them automatically, or suggests the proper import, as soon as you use the implements keyword.

    NetBeans also suggests proper imports, if you select a class from the code completion selection, it also adds the proper imports. Alternatively one can use a keyboard shortcut (Ctrl + Space), click on the small lightbulb on the left side (as mentioned above), or use another method. Here is an useful overview of imports in NetBeans: https://netbeans.org/kb/73/jav…odereference.html#imports


    Quote from Miwarre

    For what is worth, I would greatly prefer a separate sub-directory for each plug-in to be a requirement (with only second-level directories scanned for plug-ins). It avoids any file name clash between the contents of different packages, simplifies the distribution (the distribution ZIP can already include the sub-directory to be directly expanded in the plug-in directory), without any noticeable inconvenient.

    Thanks for your feedback! It's true, even to avoid a file name clash it's necessary to have sub directories. Guess it will be similar to the Lua plugins, so there will also be a configuration file. In addition, we could add support for zip files (so people don't have to extract them [of course they can do this optionally], but simply put the zip file into the plugin folder.


    Quote from Miwarre

    You probably already thought of this: I would suggest using a directory other than scripts for Java plug-ins, to keep the two worlds separate and simplify the transition (and the final clean-up, once the LUA framework will be phased out).

    Yeah, there will be definitely a different directory for Java plugins, most likely a folder called "plugins" ^^ Especially since the Java plugins can't be considered as "scripts" anymore, so having to put them into a "scripts" folder is a little bit awkward^^

    Quote from Miwarre

    Thanks for reporting your findings, @zfoxfire. I personally use Eclipse under Linux, so most of it is not directly applicable for me, but it is always interesting to hear about other people experiences.


    I am a bit surprised about the need to fix the imports with NetBeans, Eclipse manages them automatically, or suggests the proper import, as soon as you use the implements keyword.


    About testing the plug-in, of course this is not possible now, until a plugin-enabled version of the server will not be available (soon... :evil: ).

    I am also surprised that I had to specify individual classes of the jar in my import statement. In the past, I've just included the top-level jar and that was it. Maybe there is a NetBeans setting i am overlooking. Maybe I am in some kind of strict mode. But that's fine by me. I did discover the light bulb icon with suggestions and I guess the IDE managed to scan the rest of the jar and suggest what other classes to import. No biggie!


    Testing should be possible in game right now. Atleast that is what I interpreted from Red51. Unless I am still confused on the language used.


    Regarding the proper way to implement a plugin, I'd suggest drop-in zip file approach. On game-launch, the zip files in plugins are expanded to a corresponding folder if the matching folder name does not exist yet. Regardless, the game reads the actual plugin from a folder, not the zip. The Jar file will contain Manifest info containing authors info so I really see no reason to require a config file as LUA did. The Jar file just needs a class matching the Jar/folder name for the plugin to be recognized. Any additional files such as config files or databases which will be modified can be included in the zip or we can just assume the mod writer will create those files if they don't yet exist.

    Quote from Miwarre

    About testing the plug-in, of course this is not possible now, until a plugin-enabled version of the server will not be available (soon... :evil: ).


    I just confirmed this.. I must have misinterpreted what Red51 meant when he was talking about dropping jars in the scripts or plugins folder. I read that I can when it meant that it might be. Oh well... I already tried my jar file in both folders and it should have printed the text to stdout which I assume is the console in Rising World. It would be nice to have a feature in-game (maybe by console command) to list all recognized and active plugins loaded.


    Anyways looks like I have the basics down so I can atleast start writing a mod. Whenever the API is supported by the game then I "can" actually test in-game :) The way I read the comment about no server-side support was that I can still run a plugin that did not communicate with a server but would still work in the client.

    Quote from zfoxfire

    It just seems that for mods that do not require the user modifying settings that simply dropping in a jar would be convenient. Whatever configs info can just be read in from inside the jar. The zips can still work as discussed earlier.


    I know this is still being finalized but I was just thinking that for certain mods that dont require external configuration files, it might be convenient to drop a jar directly into the plugins folder without any unpacking.


    @zfoxfire posted this here, but I am replying here as an attempt to keep all contributions about this topic together.


    Placement: I agree that it, in the specific case of single-file plug-ins, placing the file in the main "plugins" directory would be easier. I am not sure it would be globally easier, though. Having a rule with sub-cases or exceptions is more complex and error-prone that a single-sentence rule:


    "Each plug-in shall placed into its own sub-directory under the "plugins" directory, unless it is a single file, in which case it can be directly placed in the "plugins" itself".


    is not easier to read, to remember and to put into practice than:


    "Each plug-in shall placed into its own sub-directory under the "plugins" directory".


    Unless, the rule will be to have only single-file plug-ins, in the form of a ZIP-ped file, which will be placed in the main "plugins" directory.


    File type: whether to natively support ZIP files or not -- in addition to OR instead of .jar files -- is a decision which the dev team can make, having in the mind the general structure and economy of the app.


    Personally, I would NOT push this option, though. The ZIP file has to be expanded, sooner or later. This can happen in memory each time the application starts up, resulting in greater memory occupation and slower start-up time.


    Or it can be done once, the first time the application finds a "new" plug-in ZIP in the standard "plugins" directory, extracting into a specialized destination directory. This raises some issues as well, though.


    *) It might be hard to decide when a plug-in is "new": how to detect a new version of a plug-in with exactly the same the ZIP file name, in order to update the destination directory containing the expansion? Has to application to keep track of file time stamps too?


    *) What if "myPlugin_1_1.zip" is added to the "plug-ins" directory? How the application can decide that this a new version of "myPlugig.zip" and delete the expansion of the previous version?


    *) Having both the ZIP file and its expansion may lead to confusion and/or to sync problems due to manual updating the latter without updating the former too (we ALL did this this kinds of things, didn't we?)


    So, unless there are other compelling reasons, I would not suggest supporting ZIP at all.


    Of course, this does not affect distribution: plug-ins could still be distributed as ZIP files; it would be the care of the user to expand them into the appropriate (sub-)directory.


    Under this respect it would be useful to encourage authors to distribute plug-ins in ZIP files already providing their own sub-directory directly in the ZIP file (so that these ZIP files could be expanded directly in the main "plugins" directory, without directly dealing with sub-directories).

    Quote from Miwarre

    I agree that it, in the specific case of single-file plug-ins, placing the file in the main "plugins" directory would be easier

    That's true. Originally I wasn't sure if this may cause some problems, especially if the plugin ships with some assets or third party libraries. However, I guess it doesn't matter. For assets, it might be a requirement to put them into the jar file. For third party libs, I guess it's no problem if they're in the "plugins" folder, or maybe we add a specal "libs" folder or something like that.


    Quote from Miwarre

    whether to natively support ZIP files or not [...] The ZIP file has to be expanded, sooner or later

    Well, basically ZIP support isn't necessary. And yeah, the server has to unzip it anyway. Plus there won't be any advantages in terms of disk space usage. Originally it was intended to just have an easier way to "install" a plugin in singleplayer. Some people struggle to unzip a ZIP file (this happened several times in the past), so it would be easier for them if they move the ZIP file (it's still better to upload plugins in a ZIP file) into the plugins folder. But I guess it would be more preferable to have an installer for that...


    Quote from Miwarre

    the first time the application finds a "new" plug-in ZIP in the standard "plugins" directory, extracting into a specialized destination directory. This raises some issues as well, though.

    Yeah that's true. I guess having an "auto-unzip" feature may cause more problems than benefits.


    ------------------------------


    So to recapitulate this, I *guess* the best approach is having all plugin jars just into one single folder (the "plugins" folder), third party libs (I think most plugins don't use any third party libs at all) may go to a "libs" folder, and ZIP file support will be discarded (maybe we could put an installer on our todo-list).

    Miwarre,


    I made a new thread here: Zip vs Jars, Plugin nameing conventions, upgrades, and Maven repositories
    We can use that to hammer this out there. This one also talks about repositories so goes a bit beyond the scope of package names but still very relevant. If you want to consolidate some of your thoughts from the following thread then please do so: Package name requirements?

Participate now!

Don’t have an account yet? Create a new account now and be part of our community!

Create Account Login