TeamSpen210
commented
1 year ago This seems tricky to automatically handle, since map changes could be arbitrary, the old entity state could either be perfectly fine to transfer or be totally broken. But BSPs do store some data we can use in the entity lump. First there's the mapversion field in worldspawn, matching the same in the VMF - if stored in the save file that would tell us whether the map was changed.
For brush models, what we could do is store the hammerid keyvalue in the save file for each entity, then if the map changes use that to lookup the changed brush ID. That wouldn't be reliable though for instances, and might not work regardless (what to do with removed or added brush ents?).
I think the safest approach would be to ensure the save format stores off the transitioning entities and data when you first load each map, then you could allow the player to restart this level, loading in that transitioned stuff so it was like you entered from the previous map. That should be very safe since you probably wouldn't have brush models coming through, and the map would be in a known state. Possibly add a logic_auto output with the old map version as a parameter, so it could potentially do fixups?
Is your feature request related to a problem? Please describe.
Saves are vulnerable to breaking after the map they're saved in is updated. This is particularly a problem for Steam mods, which usually have lots of people playing at the same time and any updates to game content via Steam cannot be avoided by players.
Describe the solution you'd like
A way for the game to detect saves broken by map updates and try to salvage them, or protect them from being broken in the first place. Perhaps there could be some way for the game to know what to do with changed entities or brushes depending on the player's current game state. That solution may require the mapper to explicitly define separate instructions for handling saves from older versions of a map.
Describe alternatives you've considered
Saves normally always break after a map update, but if I recall correctly, the issues presented by it are pretty specific (i.e. AI is disabled due to the node graph manager being out of sync and trigger brushes become visible due to differing brush models), and if those specific issues can be resolved or worked around in some way, it's possible that an elaborate save/restore instruction system wouldn't be entirely necessary.
Additional context
Whether or not Steam mod teams have accounted for map changes breaking saves tends to vary. Some mod teams ignore the issue and update maps anyway, which breaks saves for anyone who happens to be on updated maps. For mod teams which avoid changing the maps, their ability to update the game is very limited. Making the game even slightly resilient to this problem would be a massive deal.