[quake2] Savagame

[tei]

Jamie Wilkinson wrote:
> This one time, at band camp, coyote at cojot.name wrote:
> 
>>On Wed, 30 Mar 2005, Brendan Burns wrote:
>>
>>
>>>Yeah, although its worth pointing out that I think if it doesn't work, q2 
>>>crashes...  I've heard that other versions of q2 have improved the saved 
>>>file format and don't have this issue...  Adding that to this version 
>>>would be a great project for someone interested in getting their feet wet 
>>>in q2 development (hint, hint)  Otherwise I'll put it on my (really, 
>>>really long) list of things to do (write after "Graduate with PhD...")
>>
>>Mind sharing with us the list of changes you'd like to do?
> 
> 
> Dunno what Brendan's thinking of, but back in the day I was contemplating
> encapsulating the save game info in a parseable format (rather than the
> memory dump thing it currently is) that isn't tied to the particular build.

savegames sould be serializations of entity state + status globals, like 
on Quake1

actually everything about serialization its very well know, not that 
obscure as the old good days

> I'd expect there to be some problems, such as the state of monsters or items
> in levels during development changing (at least, that's what I understand to
> be the reason that the tie-to-build exists in the first place) but there is

the order of precache or something similar? (sorry, I am q1 ish)

> probably some way of compromising so at least the engine doesn't segfault
> :-)

for every fatal action, the engine sould work on two modes:

If developer its set to 1, messagebox with error message (stop game)

If developer its set to 0, avoid crash then a warning in console 
(continue game), if the error can't be repaired, messagebox with error 
message (stop game)

developers sould debug his mods on developer mode

> 
>>Vincent
> 
>