Saved Games

[Zini]

We would have to reload the respective reference record from the content stack again. I suspect this would be substantially slower. As for problems with content file updates, that only affects changes to existing references. Everything else (new references and non-reference records) should be handled properly.

Do we know what MW is doing here? If MW is doing the same as the current implementation, than it is definitely good enough for 1.0.

A clear no to saving only changed subrecords. We wouldn't gain much from that, since the content stack loading isn't doing that either and the code is already minimising the record size by not writing subrecords that have their respective default value.

[Zini]

I just added NpcStats and a small part of CreatureStats (attributes and dynamics only). A bit of a rush job, but that should cover the most important state.

[Tolchock]

Spells learnt by the player are not saved yet, either.

[Zini]

That is a part of the CreatureStats (see above).

[Jyby]

Saving the state of loot containers that have been viewed/opened but not the containers that have not.

In vanilla Morrowind if you reload your game containers that you have not looked in will generate new loot, but containers you have will remain the same.


Then, I can argue that we save the game objects by serialization using boost... I suspect that is what we're doing right? I read on previous pages that we're using the exm save format; can you link me or briefly explain how that works?

[Zini]

We do not do serialsation via boost. The saved game files have the same basic structure as the ESM/P files, just with records taken out that make no sense for saved games and new records added for state, that can't be represented in the original ESM/P records. Most of the code can be found in components/esm.

[scrawl]

- Movement of references from one cell to another. It works for the player, because that is a special case. Everything else will not work properly. This is tricky unfortunately. It seems we need to keep track of references changing cells and then store that in the saved game file.
We already have an implementation for reference moves that are done within content files. Unfortunately these are stored in the cell record, which is the wrong place IMO. Ideally that whole thing should be replaced by a unified implementation. I haven't thought through all implications sufficiently yet.

What exactly is not working properly here? I just did some tests (both moving an NPC across exterior cell border, and teleport to an interior with positioncell) and the produced savegame works fine as far as I can tell. When a non-player reference moves to a new cell, it is deleted from the old cell and then added to the target cell. It then shows up in the list of saved references of this target cell in the savegame. I don't see any issues with that.

[Zini]

By moving the reference from one cell to another the connection between the original reference in the content files and the moved reference in the saved game file are broken. For example, if we remove the content file that adds this reference, the reference should also be purged upon loading the saved game file. This we currently can't do.

[scrawl]

That's simple enough to fix. Just copy the content file id to the new reference.

[Zini]

That would result in an invalid RefNum value.