Factorio Forums

I have been experimenting with the new zoom_limits API and feel like it is hard for a mod to clean up after itself after having made changes. The issue especially noticeable when uninstalling a mod.

The mod I'm maintaining "unlimits" the zoom function and this works really well with the new API, the settings are flexible and the experience is seamless as there is no need to hack about manually with the zoom value.

The only thing that detracts from the UX is that the settings persist even after the mod is uninstalled.
As it is only possible to adjust the zoom_limits of the active controller for a player the results can become unpredictable, especially in multiplayer games where some players may be limited depending on whether they played when the mod was active or not (the difference may even be on a per controller basis).

The only reliable way I've been able to figure out so far to handle removal is either:
-Having a "disable" mode in the mod that resets zoom_limits instead of the regular processing. With some additional bookkeeping of which player/controller combinations have been changed it could likely emit a message once the mod is safe to remove without leaving altered zoom_limits.
-Creating a dedicated "reset" mod to be installed instead that would actively reset zoom_limits, there is no way for this mod to know when it is done though.

It might be possible to iterate through all controllers for all players using LuaPlayer::set_controller{} and reset the zoom_limits but some of the controllers have side effects on permissions etc. that would need to be compensated for.

I'm not really sure how to solve this in a good way.
-Being able to access the zoom_limits for other controllers than the active one could help with the cleanup and would also make subscribing to defines.events.on_player_controller_changed less mandatory. Even if it wouldn't solve the entire issue it would reliably be able to reset even offline players in a save.
-zoom_limits not being persistent to save/load would be clunky as they cannot be modified during on_load().

Thoughts and suggestions for how to tackle this are very welcome!

I am not seeing anything here that is specific to zoom_limits. The same would happen if you have a mod that makes all placed entities not rotatable and you remove that mod - settings that are persisted on game objects remain on the game objects, and we will not do any attempts at tracking which variables were set by which mods to revert them when that mod is uninstalled - that would be way too much to track, both in the amount of entities/objects to track and in the granularity of the data to track (what if one mod would made entity not rotatable but other made it indestructible and first of those is removed).

That is fair. The persistence behavior would be the same for other settings as you say. What about expanding the API to make the cleanup easier?

I have not dug deep enough into that many objects/settings but, for the ones I have looked at the settings are "always" available. For the rotation/invincible example a mod/script could reasonably try to clean up after itself, it would need to deal with the conflict, but it can at least access the entity properties to make the changes.

For the zoom_limits a mod/script can only readily clean up the limits for the active controller. To make a script clean up the zoom_limits for all players on a save you'd need to iterate all controllers for a player using LuaPlayer::set_controller{} while also keeping track of a lot of state that would need to be restored, thing like player permissions, current controller etc. This can probably be done, but the ergonomics of it do not really feel great. Or am I overthinking this?

If it was possible to set the zoom limits for a controller without having to actually wait for the player to switch to that controller (or force them to), it would be so much easier to clean up these kinds of changes.
Being able to change the zoom_limits for all controllers would also, as mentioned, mostly remove the need to subscribe to defines.events.on_player_controller_changed

One way to do it might be to allow for an optional controller field in the ZoomLimits table and if it is empty, use the current controller. I think that should be backwards compatible with the current API.