What to do with entities after uninstall

[FuryoftheStars]

Hmm, while it would be nice, I feel like there are so many edge cases with this that may be difficult to handle and it may come down to where to draw the line in support. And what about recipes? Or technologies?

Even if the devs did add a json or script method, it would still be on the mod author to implement and implement correctly.

In all the games that I have ever played, I've never seen one that handles or gives a method to the mod authors to handle themselves uninstall of the mods. They just do the same thing as this game: if it was a mod added entity, it will just vanish (or in the case of one other game I can think of, it just becomes a useless object).

I am of the opinion that if you want to try out a mod, try it out on a new game/sandbox first, make a backup save of any running game that you want to introduce it to, and if you go long enough with it that you don't want to revert, then you need to put in the time and effort yourself to cleanup your map so uninstalling it won't break anything.

If the mod author can and does include an uninstall option for you, that's great and you should use it. But this may not always be possible depending on the mod and what it does, so like it or not, there's always going to be some mods that you'll need to take care of yourself on uninstall.

[DarkShadow44]

If the mod author can and does include an uninstall option for you, that's great and you should use it. But this may not always be possible depending on the mod and what it does, so like it or not, there's always going to be some mods that you'll need to take care of yourself on uninstall.

Very true. Thinking about it, mods can already add an uninstall command you could run before you remove the mod. Never seen that happen though, guess it's not too important after all.
The modding community could easily add a library to provide "/uninstall modname" where each mod can register it's own uninstall handlers. Probably would make the most sense, but I doubt too many modders would support that.

[jodokus31]

The modding community could easily add a library to provide "/uninstall modname" where each mod can register it's own uninstall handlers. Probably would make the most sense, but I doubt too many modders would support that.

The only advantage of a central mod could be, that it is executable after the actual mod was removed, but then the uninstall code must be part of that central mod and who wants to maintain that?

In this case, it would be easier, if a mod provides a "/modname_uninstall" command and the user must remember to call it, before removing it. No need for central mod to register to.

[Pi-C]

Thinking about it, mods can already add an uninstall command you could run before you remove the mod. Never seen that happen though, guess it's not too important after all.

I actually have included commands in GCKI to reset vehicles. That's important because players can "lock" (i.e., make inactive, unminable and inoperable) vehicles, and they would be left in this state if the mod was removed. However, the command isn't called something like "/uninstall" because it's also meant to be used if something has gone wrong. But I could add an alias (something like "/uninstall_GCKI") to make it more obvious that the command should be used before the mod is removed.

Additionally, I run some clean-up code for GCKI in on_configuration_changed of Autodrive when GCKI has been removed, and robot256 mentioned he'd add it to Vehicle Wagon as well.

The modding community could easily add a library to provide "/uninstall modname" where each mod can register it's own uninstall handlers. Probably would make the most sense, but I doubt too many modders would support that.

If it was possible to store functions in the global table, other mods could add a dependency on the library mod and register their uninstall routines. The library could call the functions in on_configuration_changed for all mods that have event.mod_changes[mod_name].old_version, but not event.mod_changes[mod_name].new_version, and then remove the mod's function from global. Unfortunately, we are not allowed to store functions in the global table (unless I'm very much mistaken).

[Tooster]

If the uninstall scripts/migrations were to be too much of a pain to add, then at least some API to add an opt-in notification on mod uninstall could be added. Any mod author could provide an appropriate message, and when the mod is uninstalled/disabled (in a mod manager or during save load?) a confirmation popup with a message would be presented to the player. For example:
Shortcuts for 1.1 mod author could add a "uninstall notice", and when the player tries to load a save without that mod, he is prompted with the dialog:
"Shortcuts 1.1 deinstallation notice:
To safely remove Shortcuts for 1.1 go to Settings>Map and set Mode to "uninstall" first.

[Enable mod and Restart (safe)] [Proceed anyway (unsafe)]
"

Then a player is given a chance to do as the mod says. The problem right now is that there is no way to inform player removing the mod that some things may not work as expected. This approach with notification could be also expanded. The mod could opt-in into an "uninstall-stage". With it, when the save tries to load with mod disabled, the game would be restarted with the mod enabled and the save loaded BUT the game would say to a mod that it's in its "unsinstall" mode now - this way the mod could perform all required operations like it normally would. The game would then restart, the mod would get disabled "for real" now and the game would be restared. Now the save game would get loaded like it is now (removing uncleaned resources).

If it was possible to store functions in the global table, other mods could add a dependency on the library mod and register their uninstall routines. The library could call the functions in on_configuration_changed for all mods that have event.mod_changes[mod_name].old_version, but not event.mod_changes[mod_name].new_version, and then remove the mod's function from global. Unfortunately, we are not allowed to store functions in the global table (unless I'm very much mistaken).

There is a concept of "friends" in c++, where a mod can specify which other mods can access it's internal data/functions. Maybe something like that could be useful in this case — Mod A says that mod B can access functions and internal data of A. This would enable mod authors to explicitly permit other mods to use internals of their mods and would restrict unathorized access.

[Pi-C]

If the uninstall scripts/migrations were to be too much of a pain to add, then at least some API to add an opt-in notification on mod uninstall could be added. […]

Then a player is given a chance to do as the mod says. The problem right now is that there is no way to inform player removing the mod that some things may not work as expected. This approach with notification could be also expanded. The mod could opt-in into an "uninstall-stage". With it, when the save tries to load with mod disabled, the game would be restarted with the mod enabled and the save loaded BUT the game would say to a mod that it's in its "unsinstall" mode now - this way the mod could perform all required operations like it normally would. The game would then restart, the mod would get disabled "for real" now and the game would be restared. Now the save game would get loaded like it is now (removing uncleaned resources).

While your approach makes sense at the first glance, I don't think that mods can (or should be able to --> just think of malicious or buggy mods) restart the game. This would only work if it's implemented in vanilla

There is a concept of "friends" in c++, where a mod can specify which other mods can access it's internal data/functions. Maybe something like that could be useful in this case — Mod A says that mod B can access functions and internal data of A. This would enable mod authors to explicitly permit other mods to use internals of their mods and would restrict unathorized access.

This would work if mod A had been disabled. However, there's a chance that the files of mod A doesn't even exist:

• A player in single player mode has uninstalled (i.e. removed all files of) mod A.
• Mod A has just been turned off in a multiplayer game when a new player who hasn't installed the mod joins.

In both cases, on_configuration_changed would still contain the info that there is an old, but no new version of mod A. However, on trying to access the internal data of mod A, the game would fail to find the necessary files.

[Silari]

• A player in single player mode has uninstalled (i.e. removed all files of) mod A.
• Mod A has just been turned off in a multiplayer game when a new player who hasn't installed the mod joins.

In both cases, on_configuration_changed would still contain the info that there is an old, but no new version of mod A. However, on trying to access the internal data of mod A, the game would fail to find the necessary files.

Pretty sure in the second case the mod would already have been removed by the time the new player joins. Remember that joining a multiplayer server saves the game first, then sends that new save to the new player who then loads it. Mod would already be gone in the save that gets sent.

The data lifecycles page in the API says that outright:

Note that when loading a save to connect to a running multiplayer session, the answer to the diamond-shaped nodes will always be "No", and all migrations will have been applied previously. Because of this, effectively only steps 1 (control.lua) and 4 (on_load()) (marked yellow in the diagram) will run.

There's an explicit error the game gives if migrations fire loading a server, because it shouldn't ever happen. Not sure if that also happens if on_configuration_changed runs, but same idea.

[Pi-C]

Pretty sure in the second case the mod would already have been removed by the time the new player joins. Remember that joining a multiplayer server saves the game first, then sends that new save to the new player who then loads it. Mod would already be gone in the save that gets sent.

Sorry if my example wasn't correct -- I must admit I don't have a lot experience with multiplayer games, so it seemed to be reasonable.

[curiosity]

While your approach makes sense at the first glance, I don't think that mods can (or should be able to --> just think of malicious or buggy mods) restart the game. This would only work if it's implemented in vanilla

Just what do you think this API request thread is about?

And with the suggestion you quoted mods won't be able to restart the game anyway. Player will be offered a restart.