Mod-associated permanent-state "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 (optionally by the creating mod), 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.

[aaron311]

Another example situation I just hit right now when writing a mod. In my mod, I did this:

player.mute_alert(defines.alert_type.entity_destroyed)

I load a save with my mod. Save game. Then I disable mod. File no longer plays alerts anymore even with mod removed.

It would be great if Factorio would track "Mod X set custom config A, thus roll back custom config A when mod X is disabled." Or else give me some way to set an 'uninstall hook'.

[Gweneph]

I second this request. I think it would be most easily achompplished with a single lua file removal_migration.lua or something. The code in there would be like a migration script except it couldn't have any imports which would allow the file to run without the mod as long as it was saved into the game.

Any errors should not prevent the script from being removed. So it only gets one chance and is considered successful regarless of errors. This prevents a mod from locking out a save.

My use case is Facotrio Access where someone might share a save file with someone sighted to have them check it out.

[curiosity]

I second this request. I think it would be most easily achompplished with a single lua file removal_migration.lua or something. The code in there would be like a migration script except it couldn't have any imports which would allow the file to run without the mod as long as it was saved into the game.

Any errors should not prevent the script from being removed. So it only gets one chance and is considered successful regarless of errors. This prevents a mod from locking out a save.

My use case is Facotrio Access where someone might share a save file with someone sighted to have them check it out.

I like this idea. But I think there must be a channel for getting those errors to the mod author. Maybe the usual error message, but with an option to "continue anyway".

[aaron311]

Hi folks,

Thank you for the interest, discussion, and suggestions!

The more I think I’m about an uninstall script the more I am convinced that - while it would represent a lot of flexibility - it does not make sense architecturally. I also think that it sets up uninstalls to nearly “always fail” due to the difficulties associated with the logic. Lastly, it doesn’t really solve the problem of how mods would know for sure that reverting something was “right” — mod A and B that both change a default flag from true to false, if A is removed, ideally A would not change flag back to true since B is there. Etc.

I am starting to really believe that the proper approach is to optionally attach mod “ownership” to variable changes. Maybe some utility class with a “set_owned_value(target, value, revert_behavior)” that could save into the file that the value gets reverted upon mod uninstall.

Would that meet most of the use cases so far? Not my force use case. But my alert sound one, yes. Maybe forces could be handled differently.

Can you two elaborate on your use cases further? It might help add some clarity on a design.

[curiosity]

I don't have a use case, it's just something (or lack thereof) I see every so often in mods. Recently I've been reminded of Discovery Tree.

With what you have outlined, the only resort aside from your idea seems to be involving the player. Like Discovery Tree does, include a way to prepare for mod uninstall.

[aaron311]

Ah, makes sense. Still, if you could comment with example types of things that needed to be "rolled back" via a custom mechanism for a mod, we could try to start making a list of things that would need to have a solution. IDK. Just a thought.

[eugenekay]

Still, if you could comment with example types of things that needed to be "rolled back" via a custom mechanism for a mod

Changes to Force Modifier values, such as the Long Reach family of mods are a semi-common issue.