What to do with entities after uninstall

[saors]

I was looking at
https://mods.factorio.com/mod/BetterBots
and in the description, the author states that if you use this mod and place down the entities (which are upgraded roboports) and then uninstall the mod, the roboports will be deleted. I've experienced this personally with a different mod (that wasn't as kind as this one to provide a way to fix it).

So I wanted to start a discussion and throw around ideas on ways to address this without having to do tricks like this author did. Here's one solution I've thought of:

A "replaceWith" attribute on entities. When mods define an entity, they could give a replaceWith value (ideally vanilla entity) that the game would know to use in the case of not being able to load the mod (because it was removed).

The only con I see here is that the value has to be stored outside of the mod itself. I see it being hooked on the onEntityPlaced event and adding to some sort of global map table or something...
but I'm not experienced enough with the framework to know for sure...

Thoughts?

[saors]

I also want to add that this is important because unless the mod creator includes something like the previously linked mod does, it could potentially ruin your game.
Imagine if you had something that upgraded all of your logistics and then you uninstall it because it's out of date or because of a bug. Now your entire save no longer has trains, belts, inserters, bots, etc.
Manually replacing all of these before uninstalling (if you're even able to downgrade first AND the vanilla items are still available to the player) isn't feasible and players shouldn't have to rely on mod creators to patch the game to avoid ruining their map/save.

[steinio]

Maybe some general uninstall event in which you can define migrations, remote interface calls or variable clean up.
This must also be cached in the save to stay in it after the mod is gone.

Or you just move the players 1000 chunks north :p

[eradicator]

Thoughts?

First thought would be: Don't built half your base with a mod that you're going to uninstall later :P
Second thought: Sure, would be nice to have. Proper implementation is again up to the mod author thought who has define a table of new -> old mappings. So... the only thing that could be changed would be to add a reusable uninstall script. Maybe adding uninstall.json which on being required returns a simple mapping of
'modded-entity-name' : 'vanilla-entity-name'.
That way you don't need to store anything in the savegame, you just need to still have the mod on the drive.

I know of no other game that provides that kind of functionality though. You'd also need a pretty complicated new interface to enable selective uninstalling on a per-savegame basis.

[saors]

Re the first though, yeah, of course but if support for the mod stops and starts negatively affecting gameplay...

as per second thought: I had thought about doing it during uninstall, but the drawbacks you listed are exactly why I didn't think it was a good idea.

It really wouldn't be too complicated to save it in the save file, it'd be a simple record of what entity the mod adds and what the vanilla counter-part is. You don't need to save information about the specific entities on the map.
So if your mod adds 30 entities, that's only 30 records on the save saying {'super-duper-inserter':'fast-inserter'}.
If the mod is removed, those entries are kept until the save is loaded and the entities replaced.

[bobingabout]

honestly, it would be useful to be able to set an entities "uninstalled migration" state, because people have already complained that when they remove bobclasses, their player entity disappeared. being able to tell the game that if "bob-player-miner" no longer exists, migrate it to "player" would be awesome.

[Anson]

i also encountered this problem on some mods and had to manually rebuild hundreds of missing items after some mod was no longer usable. this includes cases where i want to get rid of a mod for some reason (eg to make some vanilla-compatible blueprints; here it would maybe possible to use some upgrade planner to downgrade before or instead of removing the mod), but most of all it includes those cases where a mod is no longer working, be it some new incompatibility with other mods, a mod not being updated yet for a new version of factorio (this includes several nice mods from Klonan), some new bug, or any of a few other reasons.

for many mods it might be impossible to have any replacement method that makes sense, eg for big packages like Bobs, or when there are new multipart entities or similar (for these, vanilla might get some new placeholder items like simple 1x1, 3x3, grey squares to mark those positions). but there are also a lot of mods that add higher tiers of vanilla items and it would be better to have any belt/solar/whatever after removing the new MK4+ versions. and there are lots of simple mods that only add variants of vanilla items with slight variations like different looks (but that are not modifying the vanilla items and instead create their own versions to be able to use them all, eg alternate lamps, alternate power poles, alternate rails, alternate concrete or alternate other floor tiles, etc). Even if the properties (besides the pure looks) are modified, it would be better to have a similar item instead of losing the item completely.

btw: i encountered this problem eg with lamps MK2, colored lamps and colored concrete, power poles that include lamps, and the last time was with Connection Boxes which more or less is only a variant of power poles, but with a different graphic and a slight difference in functionality (no high power poles, but small pins on the ground that don't connect copper wires by default, to make logic wire connections easier to build). In all these cases, simple replacements with other vanilla items would easily have been possible, provided that some general such method for "uninstall-migration" existed (even if it was only a simple "back replacement table" that is included in the savefile).

and as a last method (if any replacement fails), it would be nice to at least give back most of the resources that were used to craft some expensive no longer existing items (spontaneous idea to do that: fill inventory until full, or replace items with dummy chests that contain those resources, similar to player corpses).

[Rseding91]

My immediate reaction: it's working how we want it to: remove the mod and everything it added is removed.

If that's not what you want to happen then don't remove the mod.

That being said, if someone has better arguments I'll listen.

[bobingabout]

My immediate reaction: it's working how we want it to: remove the mod and everything it added is removed.

If that's not what you want to happen then don't remove the mod.

That being said, if someone has better arguments I'll listen.

Well, I personally would only use it in a few very select situations, as mentioned in my post above.
I've had people install the bobclasses mod just to try it out, play for a bit, uninstall the mod then... oh wait, their savegame is now broken because the player entity it was using doesn't exist anymore, and the character disappeared.


So, on a personal note, I'd like to see a file named uninstall.json that runs just the same way as any other .json migration file, except it would need to be saved into the savegame (since it can't be run from the mod if the mod is uninstalled), and run in the event that the mod isn't there anymore.
I would keep it purposely just that simple so that things can't mess up if people write a bad script, and if a bad script does exist, it should be ignored rather than crash out the savegame. (which is easier to do with an object replacement migration file like this than a full on lua script)

An example of the content of what I'd use for bobclasses would be as follows:

Code: Select all

{
  "entity":
  [
    ["bob-player-miner", "player"],
    ["bob-player-fighter", "player"],
    ["bob-player-builder", "player"]
  ]
}

And that's it, it would fix the major issues with that mod.

[Aeternus]

Sounds like you may need to do what some other mod developers (I know Bobingabout had to) have done to migrate certain stuff - create a "migration" mod that'll upon loading your game replace all the deprecated items for that mod you want to remove, with the vanilla versions where able. This cannot be handled from the basemod since the base mod does not know the new entities introduced in the mods, so it can't guess what to replace those with and instead just deletes those outright (which is sensible).

This is something the mod designers would need to provide. Since most mods introduce structures that have no vanilla counterpart, few if any do.

[Edit] Aw shucks, ninjad by Bob

[mrvn]

What to replace something with would also depend on what other mods remain.

For example when I add new roboports on top of Bobs and my mod gets removed then I want my roboports to fall back on bobs., But if bobs mod isn't used then the fallback would be on vanilla roboports.

So I don't think a simple entitiy->fallback mapping will do. Should be a lua script that migrates a savegame on load.

[Aeternus]

Problem with that, mrvn is that that fallback mapping script needs to know -every- entity prototype published in -every- mod and the fallback order for those. Given that new mods are still being added, that's just not feasable.

[eradicator]

What to replace something with would also depend on what other mods remain.

For example when I add new roboports on top of Bobs and my mod gets removed then I want my roboports to fall back on bobs., But if bobs mod isn't used then the fallback would be on vanilla roboports.

So I don't think a simple entitiy->fallback mapping will do. Should be a lua script that migrates a savegame on load.

Sounds trivial. You just give [source entity] = [target1, target2, target3,...], then when "uninstalling" you loop through the list and use the first name that actually exists. Ofc that's not how the system currently works so it's still more work than a 1:1 mapping, but i don't see the need to allow full scripting of that stage.

[sparr]

I would want this functionality to be optional. When you load a game with some saved "mod uninstall" events, give the user a dialog similar to the "sync mods to save" dialog, with checkboxes for various mods to choose whether to run the uninstall event or just delete the entities how it works now.

[Tooster]

I know that the topic was moved to "won't implement" and it staled for 4 years, but I would like to maybe hear some new thoughts about it.

My experiences so far that led me to looking for this topic:

• Recently I've tried installing BigBrother mod that upgrades radars. After a bit of playing with them, I decided to try something else and removed the mod. To my big surprise, upon loading, the save file has been cleared from all radars.
• While browsing settings, the Shortcuts mod includes "uninstall option" in the menu — it toggles night vision, flashlight and resets artillery state.
• Some mods introduce lots of changes, which get removed when the mod is removed. This makes mistakes more punishing when a save is loaded/saved and there are things like all train networks missing suddenly. If I don't create a backup for world on mods sync or autosave happens at a wrong time, there is a high probability I will irreversibly corrupt my world, or break a lot of stuff that will require manual recreation later.

Removing those mods without knowledge leaves the game in a "semi broken" state, which can go undetected for a while. When the improper behavior is finally found, finding the source of a problem can be hard. I often find myself in a loop where I add some mod, test it, and when it doesn't work out for me I remove it.

In my humble opinion, some standardized way to avoid doing such hacks would be nice to have. Something like an "uninstall stage" where a mod can run it's cleanup scripts.

I also had an idea of keeping a "removal" log/data store for mods. This is from a player's perspective, because I don't know it the game doesn't already keep some track of removed entities (without rolling them back up). If a mod were to be removed, then things that were added by it could be moved to some file. If the mod gets re-added again, some "sync" prompt could be shown to interactively select which old data can be restored. This would also probably require some rollback stage and would probably be complicated.

Do you think that a "disabled" and "enabled" migration script could help here? One would be run when the game loads a save and the mod is now disabled. The other one when it is enabled/added again.

I understand that it is not a trivial task to designing a robust uninstall workflow, but I would like to hear if you maybe have some new opinions and ideas on that.

[curiosity]

Definitely needs an uninstalling migration to solve this. The migration is a JSON migration (the only way to change one prototype into another) that gets stored in the save (updated every time fresh from the mod) and run when the mod is removed (after which the migration itself is removed). This migration could be validated so it doesn't cause errors on mod removal, the syntax is pretty strict that I think it should be possible.

Not sure about any of that other stuff you mentioned. If some setting becomes inaccessible due to mod removal, you can manually set it right and only then remove mod. Any script can be run while the mod is still present, too, letting the modder provide an uninstall command or setting if needed. Not so much with prototype migrations, which would otherwise need a separate "uninstaller" mod to run.

[jodokus31]

The current solution is, that it leaves the player to fix all the issues, when modded entities are simply removed.
f.e. In case of a railsystem, it can be pretty painfull.

The problem is probably, when you remove a mod, there's no way to execute any code from that mod again. You would need some kind of a rollback system, where you are able to restore the original state. but I can't imagine, that it's going to happen.

Another possibility could be, that mods can implement an uninstall step, which you can trigger manually before unstalling. But that quite wonky, because nobody would ever remember to trigger that.

Another idea, when you load up a save where a mod was installed and then removed, you get a summary, what entities were removed. Here you could do something, with that information, maybe implement a UI-selector, which entity should be used instead. But it's also quite problematic, because you have to validate, if the new entity fits. In case of the railsystem you probably have different entities for curved rails. etc.
Maybe simply make the summary a bit more informative and add the locations, where entities got removed.

[DarkShadow44]

I do like the uninstall JSON idea, just a simple migration entity -> array[entity], where the first one that exists is used.
What's the reason this got moved to Won't Implement?

[robot256]

Anything that can be done by a JSON script can also be done by a Lua script and "uninstall" setting, if the mod author is careful. I can see a lot of problems running uninstall JSON files if you multiple mods still installed--what if it tries to set them back to a vanilla entity that doesn't exist? A Lua script can account for that. Most mods either alter vanilla entities or add many entities without direct replacements, so player rebuilding is needed anyways.

As for the cases of "I only use autosaves/didn't make a backup before testing mods/clicked the wrong button". Debate is welcome, but there's only so much handholding the devs can do before they cripple someone else's workflow. Maybe callous of me, but IMHO it's better to learn in Factorio than at your first job: always know where your data is being saved and make a backup before you change something major.

[curiosity]

What's the reason this got moved to Won't Implement?

Probably because this:

My immediate reaction: it's working how we want it to: remove the mod and everything it added is removed.

If that's not what you want to happen then don't remove the mod.

That being said, if someone has better arguments I'll listen.

But it's also possible that some moderator came by and moved it for whatever arbitrary reason.

Anything that can be done by a JSON script can also be done by a Lua script and "uninstall" setting, if the mod author is careful. I can see a lot of problems running uninstall JSON files if you multiple mods still installed--what if it tries to set them back to a vanilla entity that doesn't exist? A Lua script can account for that. Most mods either alter vanilla entities or add many entities without direct replacements, so player rebuilding is needed anyways.

Sure, technically you can replace entities with other entities in Lua. But aside from the narrow case of fast replace, this means manually transferring every property of the old entity to the new one. You are very likely to miss some properties, especially in complicated entities like characters. And you may not even have access to some of them. Meanwhile, the game already does all this in JSON migrations, which have been used for a long time by now and thus unlikely to miss anything.

As for the cases of "I only use autosaves/didn't make a backup before testing mods/clicked the wrong button". Debate is welcome, but there's only so much handholding the devs can do before they cripple someone else's workflow. Maybe callous of me, but IMHO it's better to learn in Factorio than at your first job: always know where your data is being saved and make a backup before you change something major.

I don't think this is that case. You can play for quite a while before making your mind up about the mod, especially the more situational mod content is (e.g. the aforementioned radars). There is no reason to punish players for trying out mods, nor is there any reason to punish mod authors for making content mods.