Mod "garbage collection" via some means (not sure what would make sense, though)

[aaron311]

Hey,

This is only a half-formed request, but interested in what people might think -

I don't do much modding, but I did publish a mod back in the 1.0/1.1 days, and thinking about resurrecting it for 2.0, now. It was a semi-evil mod that made force changes in order to accomplish prioritization of local player construction robots, etc. In order to make this happen, the mod of course had a bunch of force creation/merging logic in its code. The code had various paths to support "resetting" or "uninstalling" which would undo any duplicated forces and merge them back to how things originally were, but of course, this code had to actually be loaded to run. In such a case, if you simply went to the mod manager and unchecked the mod, your saved game files (that were previously using the mod) would be left in a somewhat bad state. You'd have to "know" to re-enable the mod, load the game, run the special 'uninstall' command, and then re-save. Then re-disable the mod.

This mod of mine also isn't the only circumstance where I've had some semi-permanent 'global modification' that I wanted to apply to the game state, yet would ideally somehow revert if my mod was being uninstalled. At the same time, I'm not sure what APIs would be practical in such situations...

---

Some ideas/concepts:

1. On a surface level, an onModUninstall() type hook *maybe* sounds like what I'd want, but this comes with the obvious problems of 'if the code isn't loaded in the first place, how the heck do you run this hook' so it feels like that approach would be insane / a non-starter. Granted, the game files could maybe permanently cache any uninstallation hook Lua code but that feels like a huge violation of the modding model of Factorio right now. Or, maybe when loading a game that had such a hook registered, Factorio could prompt the user to re-enable the mod, load the game, run the uninstall, prompt to re-save, and then auto-disable the mod again. Ugly as hell, though.

2. Possibly a more viable approach would be a sort of 'mod ownership' API for "known common" global state changes made by mods. For instance, in my specific circumstance of force changes, maybe luaForce (and other things that have lifetimes separately from mod lifetimes) could be given an optional "owning mod" attribute. If set, then if the 'owning mod' goes away, Factorio knows to 'garbage collect' the luaForce via some pre-defined rules (also possibly set by the mod as properties on the luaForce).

Are there other possible approaches?

---

Anyway, sorry I know this is entirely whimsical and half-baked thoughts, but curious if other modders have had similar garbage collection desires, and if there's any common appetite for some way to 'clean up' during mod uninstall for a file?

[aaron311]

Something I realized after posting this is that while I like the general concept of being able to attach a 'mod owner' to global state objects like luaForce, cleanup does get a bit complicated if you have a structure where one force is defined as collapsing into another when the mod goes away, but the target also has a 'mod owner' which also could be removed simultaneously.

i.e.

(force 3 owned by mod A) ----(on owner removal, merges to)---> (force 2 owned by mod B) ---(on owner removal, merges to)--> Force 1 (no owner)

This still could be solved. Upon a mod being removed, the algorithm would be to build the tree and collapse the 'leaf' forces first, moving up toward the root. If there's an owner cycle the logic would just give up, leave the forces intact, and remove the owner attribute for the removed mods.