Essentially, because it's easier to access from outside the script: since the functions have to be static to be accessed easily (calling NicToyCustomTrailPlugin.function instead of calling Global.getCombatEngine.getPlugins and going from there) the variables those functions access must be static, as well. The non-static plugin itself doesn't store information, it only uses it: the static maps keeps the information with the help of an ID as key, which is just a Float (one map, however, stores with CombatEntityAPI as key).
...
EDIT: I somehow managed to miss your comment on storing it in engine.getCustomData()… that solution is significantly safer, so I'll try to move everything over to that before people start using this plugin to too big a degree. It would as far as I see not cause any issues, and would be just as easy for the end-user.
Right, yeah. Accessing customData every time is kind of a pain, so what I generally do is have a static method, sort of like so:
class NicToyTrailProjectileTrackerPlugin {
...
public static final String KEY = "NicToyTrailProjectileTrackerPlugin_key";
public static NicToyTrailProjectileTrackerPlugin get() {
return Global.getCombatEngine().getCustomData().get(KEY);
}
...
}
And then have the init() method put the plugin into the customData. Then when you're using it, it's just
NicToyTrailProjectileTrackerPlugin.get().SPRITE_CATEGORIES
Which isn't really that much more awkward to write.
Your point on game engine, however... I'm sort of wondering here: if I leave a Map with a CombatEntityAPI as a key, would that thus by extension save the entire combat data, even when the engine that had the entity in question stops being instantiated? If this is the case, I've made an oversight I did not expect: I thought once the combat engine was killed off, any entities inside it would cease to exist and my references to those entities would now return Null, since I've only referenced their data as keys.
I must honestly say I don't know if this causes issues with memory: I have not done detailed memory mapping, especially not in the campaign. I simply know a bit too little about how the game handles long-term memory storage and how it "cleans up" after killing off the combat engine.
All objects in java are handled through references. If you have a reference to something, it will not be garbage collected (unless it's from somewhere that could itself be garbage collected due to not having any outside references pointing to it). So for example if you have a reference to a CombatEntityAPI (as a key or value in a map, or whatever), that will prevent that entity from being freed up, because you could access it through that reference. It would never automatically become null, that can't happen.
Anything that entity references, in turn, would not be garbage collected either. If somewhere along the line the entity or something the entity references points to the combat engine itself, then the engine wouldn't be collected either.
Or if it was pointing to the campaign engine (say, a ShipAPI has a FleetMemberAPI data member, which has a FleetDataAPI data member, which has a CampaignFleetAPI data member, which has a containingLocation data member, which is a StarSystemAPI, which in turn has its hyperspace anchor, which in turn points to hyperspace, which in turn has every single star system, then none of that stuff can get garbage collected all because of the static map holding on to a ShipAPI or a DamagingProjectileAPI or whatever.
So, what gets pointed to depends on the implementation of the combat entity (or whatever you're holding on to), and could change without warning. It's best to just assume that holding on to any combat entity or anything similar will result in the entire combat and campaign engine not being collected, because it would be the case for some of these objects, and because it could become the case due to otherwise invisible implementation changes I might make. But if you have these references in a non-static data member in the plugin, you're safe, since that reference is from inside the combat engine, and will not prevent it from getting garbage-collected once it no longer has outside references pointing to it.
I hope that makes sense! Let me know if I can clarify anything here.