Dump global variables to hard disk for persistant data?

[Nash]

I didn't post this in feature suggestions yet because I'd like to hear what others think of this idea. Because there is a fixed amount of global variable slots... would it be feasible to introduce an ACS command that dumps the state of the global variables on to the hard disk so that they can be retrieved at a later time? Some uses:

- High scores
- Character data import/export (since you cannot modify maps after a saved game (ZDoom will crash) this is useful for RPG mods where the user can install modified maps but still continue playing with his previous character)
- New game+

To prevent conflict, the name of the dumped file will be the same name as the WAD that contained the library/script.

Possible? Rubbish? Thoughts please...

[GooberMan]

So if I read you right, you want stuff that isn't persistent across one instance of a mod but across every instance of the mod ever.

cvar's already accomplish that. And it has precedent - id themselves used a cvar to lock off nightmare difficulty in Doom 3.

[Nash]

But cvars are easily editable with a text editor by any average Joe. Memory dumps will be a little harder to edit.

Also ZDoom's GetCVar is prone to multiplayer desync anyway...

[GooberMan]

And dumping to disk makes multiplayer easier?

[Nash]

Again, see what I said about ease of editing: the game will be harder to desync because player 1 and player 2 both have identical dumps because either of them can't (accidently?) mess it up in a text editor.

[GooberMan]

Sorry, not seeing your point here. First, they'd need to sync the dumps, which is another thing that would need to be put in the synchronisation code. I'm not entirely sure what advantage that would have over fixing whatever's wrong with cvar synchronisation.

Second, you're suggesting adding code to an open-sourced engine to dump values to a binary format. Reverse engineering is effortless, and some enterprising soul could write even some simple javascript to parse that and modify it to their own ends. It's not a very effective form of obfuscation.

[Blzut3]

I wouldn't necessarily cite commercial games as precedent. You should know as well as I do that they hack stuff together because they don't have to worry about mod compatibiltiy and what not.

I do think a persistent store like Nash suggests would be possible, provided the persistent store is only active if a file is provided by command line (-session <file> or something). However, I'm not sure if we could all agree on a set behavior on how it should be handled. It's safe to say that we would have no interest in supporting anything where save games don't hold the entire game state, so the only time the session file would come into play is when new game is selected. But when exactly is the session saved?

It would be short sighted to outright say that persistent data won't happen, but I think it's quite unlikely. Keeping in mind that Doom assumes a deterministic game state (the game state includes the ACS VM), it is difficult to have persistent data with the current state of things. Perhaps when ZScript is a reality we might have a general purpose scripting language that can act outside of the game state, but the scope of ZScript is yet to be completely defined.

Edit: While not exactly the cleanest way of doing things, as far as ZDoom is concerned you could simulate persistent data by having a Quake like start map and just using the existing save system. When the game is over just send the player back to the start level.

[GooberMan]

What's the world coming to when I can't cite a commercial game tailored with modding in mind?