urm wrote: ↑10 Nov 2020, 13:18
AFAIK we only load the actual list of cell objects and actors when the cell is first visited. Correct me if I'm wrong there.
OpenMW uses at least these data when cell becomes active:
1. Base ESM records, which are common for all objects with the same ID
2. CellRef data, which represents an
initial state of object in cell (transformations, owner, charges count, etc).
3. LiveCellRef data, which represents
current object state (CreatureStats, ContainerStore with resolved items, etc) in visited cell. If you drop such data, it is a respawn.
Most of cell data in saves is actors skills, attributes and inventories.
4. Additional state, which is used only for active cells (e.g. OSG scene nodes, character controllers, Bullet shapes) - occupy most of resources, so we do not create them for every visited cell.
As I understood, you want to store first two types of data in the one database (on disk) and the third type in the another database (in RAM). Backups of second database are treated as savegame files.
In this case you do not really need to store first database on disk - this data generally does not occupy too many space - a significant part of ESM/ESP files are landscape heights/colors, dialogues, etc. I doubt that you really need to copy all this stuff to the SQL database and then validate this database on every startup.
Also there are cases when user changed his mods setup, so his save files become obsoleted, and there is an additional logic to make them usable again (clean up removed cells, delete instances of non-exisent now objects, assign default values instead of missing classes, etc). With such cases a simple "drop existing database and take an another one from backup" approach more likely will not work properly, and with complex validation it will be simpler just to use existing save format with existing and working validation, and then copy loaded data to the in-memory database, if it present.
And most of singleplayer and coop setups will not need data from unloaded cells anyway, even with Lua mods:
1. Base ESM records can be handled en masse once during startup and when the game creates a new dynamic ESM record on the fly.
In theory, client needs to get a large amount of changes once when he is logged in.
2. Modmaker can handle objects in cell once it becomes active instead of altering objects in whole game world. For example, if you want to add torches to all actors, you can add torches for all actors in given cell once it become active. For non-active cells players will not see the difference anyway, so modmaker does not need to query all actor instances in game world.
Data from non-active loaded cells can be useful in singleplayer to create some kind of "offline" life simulation (when different events happen even in unloaded cells), but it is not a performance-critical feature.
IMO, it would be better to use SQL storage as an optional indexing mechanism (mostly on servers with a lot of players), but on such servers an amount of active cells actually may be larger issue than data format (after all, OpenMW is not an MMO engine). In singleplayer it is just a redundant entity and additinal source of bugs and slowdowns (you will need spend additional resources to keep databases and sync them with the game itself). Probably it is worth even to add a compile flag to do not build SQL-related code at all.