Full game save / persistence / snapshot mega-issue

[ElectroJr]

This is a collection of issues/tasks that need to be addressed for full game saves to work properly. Some of these are engine issues, but a decent number of the problems are in content, so I've opened it here.

See also:

• Full server snapshot/reload RobustToolbox#2406
• system saving idea RobustToolbox#4856

Issues:

• Nullspace entity and multi-map support Refactor map loading & saving RobustToolbox#5572
• NodeNets like power and atmos need to be turned into entities.
• Several prototypes are marked as non-saveable via MetaDataComponent.MapSavable, which includes most mobs. I don't know specifically why they are marked as such, but that needs to be fixed.
• Some system data is not serialized / not stored on entities
  • Device Nets DeviceNetwork doesn't handle save/load #26424
  • Wire layouts?
  • Game Ticker / Round flow
    • Might've already been fixed? but it and various rule systems used to have fields referencing specific entities/rules or maps.
• Some components likely store data in non-serialized fields
  • Hands? hands persistence #20776
  • Need to check that mind/actors work well when loading entities.
    • Might largely be fixed by null-space entity auto inclusion Refactor map loading & saving #34020
    • See also Mind persistence #20773
    • What happens if an entity with a player attached is saved, deleted, and then loaded again?
    • What happens if it gets loaded multiple times?
    • What if the player disconnects and reconnects during the deletion & loading?
• Saving an initialized map and reloading it causes containers to drop their contents. RobustToolbox#3119
• How do we handle BUIs?
  • If we save them we need to ensure all the BUI state is yaml-serialisable.
  • If we don't save them, for consistency we should probably first close all buis before saving.
• Prototype uploads
  • The full-save system should add an extra entry for listing all uploaded prototypes
• Resource uploads
  • The save file should also reference any uploaded resources, and the saving system should write them to files alongside the save file.
• CTRL+F & fix:
  • Timer.Spawn()
    • Maybe fine for some "out-of-game" stuff like votes or ghost-role raffles?
  • // TODO full game save

And then we need to thoroughly test this somehow. Catching all the odd bits and bobs that aren't saved properly will be difficult. If admins are feeling sadistic they could just save & reload an ongoing round and collect the hate mail. Though we should probably start by saving a real round and trying to load it locally.

[deltanedas]

mobs

i think mostly its so you dont map mobs and instead use the spawner, having a tested do not map category would help with this
but when i tested it out, saving a urist wrote all its bodyparts etc in the yml even if they arent damaged or anything, could just be a mapinit thing

[deltanedas]

all the BUI state is serialisable.

game will throw if its not at least NetSerializable, i dont think any states arent Serializable too

[ElectroJr]

game will throw if its not at least NetSerializable, i dont think any states arent Serializable too

I've edited the point to clarify: I meant yaml-serializable, not net-serializable. We could try use net-serialization, but that would generally prevent loading an older save with a newer version, for the same reason the replay client version should to be the same as the actual game client version for loading a replay (or at least, needs the same registered net serializable C# types).

If everything is yaml serializable, there'd be better backwards compatibility. though any PR that requires manual changes to map files would still break saves.