Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Debido]

If you've come to this post, the quick answer is:
1. Create a settings.json in your mod\data\config folder if you don't have one already
2. Add the following

   "plugins":{
      "Plugin1":"data.scripts.plugins.Plugin1",
      "Plugin2":"data.scripts.plugins.Plugin2",
   },

For as many plugins as you have

here is an example file:

{
   "plugins":{
      "AdrenalineToggleTracker":"data.scripts.plugins.AdrenalineToggleTracker",
      "ProtectionTracker":"data.scripts.plugins.ProtectionTracker",
   },
}

Now the long answer:
IF you have a loose EveryFrameCombatPlugin class file in data\scripts\plugins *FOLDER* - it will be compiled and instantiated for you automatically by the game engine, but this is not the case for compiled JARs.

As soon as your EveryFrameCombatPlugin class file goes into the JAR file in a compiled format you must add it to the settings.json file, otherwise the best you can do is call upon other methods inside your file, but the game engine will not call upon the Advance or Init interfaces.


EDIT: LazyWizard has spoken:

data/scripts/plugins is a special folder. The game will automatically add any plugins in this folder to the game, including instantiating them for you at the start of the battle. The "plugins" section of settings.json seems to be similar, but it doesn't force you to put your scripts in a specific folder.

So, the ways to get your plugin loaded (that I know of):

• Put it as a loose script in data/scripts/plugins
• Put it anywhere, then use CombatEngineAPI's addPlugin() to instantiate it in battle
• Include it in a jar AND in data/scripts/plugins, only the jarred version will be loaded
• Include it in a jar, then put an empty stub that extends the plugin in data/scripts/plugins
• Include it in a jar, then add it to "plugins" in data/config/settings.json

The last one is the best option as it's the only one that doesn't rely on the 'magic' data/scripts/plugins directory or another script doing extra work.

Addendum from DR to do with adding scripts in the settings.json file:
"..if it has an advance() that isn't explicitly defined elsewhere i.e. a beam effect or something is defined elsewhere but an EveryFrameCombatPlugin isn't then it must be in that settings file"

[xenoargh]

That's weird.  I never put anything outside the "magic" plugin folder, though, go figure

[xenoargh]

Huh.  I just tested this, and I'm not sure that you're right. 

All that stuff is compiled in my JAR, but I haven't had any errors in terms of instantiation. 

Perhaps the real issue is that you need the engine to read the JAR'd version, because you're using a method Janino doesn't like in a Plugin.  If so, I could save a little loading time by putting those entries in, but meh, more maintenance hassle.

[Alex]

All that stuff is compiled in my JAR, but I haven't had any errors in terms of instantiation. 

That's pretty weird, since the game looks for .java files in the data/scripts/plugins folder, and only automatically loads those up as EveryFrameCombatPlugins. There could be something else going on here, as this is code I haven't really looked at in a long time, but on the surface, that's what it looks like.

Any chance you're adding them using a custom BattleCreationPlugin, with MissionDefinitionAPI.addPlugin()?

[Debido]

Actually I should elaborate further on prioritisation of JAR classes vs loose classes.

In the above example I had plugins that were located at data.scripts.plugins inside the JAR folder. If you were compiling it, the folder structure would also have it located in data\scripts\plugins.

So even if location is data.scripts.plugins inside the JAR it still will not be automatically added by the game engine.

I would suggest that if you are making your mod and you do decide to go down the path of compiling your mod
a) It isn't at all scary, it's really easy to do with any IDE/compiler.
b) It speeds up the start time of the game as Janino is not compiling them on the fly
c) The code can run faster/is more efficient/optimised
d) You can use generics (makes programming easier, avoids bugs/problems)
e) It is the ONLY method to have custom AI for your ships utilised with the BaseModPlugin pickShipAI interface. Why? It's a generic return type. (You can assign AI in other ways...but don't*)

Further I would recommend if you are going down the path of compiling to a JAR, name the top level group to that of your mod. Such as
bge.data.scripts.plugins

This can help avoid conflicts and make your code easier to read. Don't take my word for it, LazyWizard uses this format inside his JAR file. You've probably noticed his util looks like this:
org.lazywizard.lazylib.<package>/<class>

[LazyWizard]

All that stuff is compiled in my JAR, but I haven't had any errors in terms of instantiation. 

That's pretty weird, since the game looks for .java files in the data/scripts/plugins folder, and only automatically loads those up as EveryFrameCombatPlugins. There could be something else going on here, as this is code I haven't really looked at in a long time, but on the surface, that's what it looks like.

Any chance you're adding them using a custom BattleCreationPlugin, with MissionDefinitionAPI.addPlugin()?

Xeno includes all his jar's source in the data/scripts folder, so I assume the game notices it outside the jar then immediately discards it for the jarred version. This pretty much has to be the case since the source in data/scripts/plugins includes generics.

[Alex]

Ahh, that's it then. So it works by a fortuitous accident, more or less

(As you surmised, it'll notice it outside the jar, add it to the plugin list, and queue it up to be compiled. Which it then won't bother to, upon finding that the class is already loaded, from the jar.)

[Debido]

Wow, ok, not sure I know what the consistent rule is with the loading of EveryFrameCombatPlugin anymore.

I thought I had the definitive state of how it worked, I can report what I've found, but it would be good to get this clarified.

[LazyWizard]

data/scripts/plugins is a special folder. The game will automatically add any plugins in this folder to the game, including instantiating them for you at the start of the battle. The "plugins" section of settings.json seems to be similar, but it doesn't force you to put your scripts in a specific package and works for jarred classes as well.

So, the ways to get your plugin loaded (that I know of):

• Put it as a loose script in data/scripts/plugins
• Put it anywhere, then use MissionDefinitionAPI/CombatEngineAPI's addPlugin() to instantiate it in battle
• Include it in a jar AND in data/scripts/plugins, only the jarred version will be loaded
• Include it in a jar, then put an empty stub that extends the plugin in data/scripts/plugins
• Include it in a jar, then add it to "plugins" in data/config/settings.json

The last one is the best option as it's the only one that doesn't rely on the 'magic' data/scripts/plugins directory or another script doing extra work. The addPlugin() method is also useful, if a bit more work, as it lets you have plugins that only load in certain situations. For example: fighting next to a sun? The mod might include a special EveryFrameCombatPlugin for such an occasion. Enjoy the constant damage!

[xenoargh]

Xeno includes all his jar's source in the data/scripts folder, so I assume the game notices it outside the jar then immediately discards it for the jarred version. This pretty much has to be the case since the source in data/scripts/plugins includes generics.

Exactly; that was the behavior I was expecting, honestly; it's good to know it's a happy accident.  

I just tested that, and it's what's going on for sure.  

So basically, I don't have to care about this at all unless Alex make the "magical" /plugins folder hack quit working for some reason.

[Alex]

@LazyWizard: Correct on all counts, and covers everything.

@xenoargh: Yep; I would imagine it'll keep working for the foreseeable future, no reason for me to remove that functionality.