Savagame

Because in function WriteGame () in game/g_save.c, the date of the
binary is written to the savegame. Later, in function ReadGame ()
(same file), the DLL's date is compared to what's read from the file,
and the save isn't loaded unless the dates match.

For a simple hack, you could always hardcode a certain date string
instead of using the date when the game module was built (just replace
the strcpy (str, __DATE__); in WriteGame (), and strcmp (str,
__DATE__) in ReadGame ()).

And now I just spotted the oldsave cvar. By setting "oldsave" to 1,
you can bypass the check and load older/newer saves (assuming they are
still compatible, of course). That's even simpler. :)

On Wed, 30 Mar 2005 12:25:17 +0200, Andreas 'GlaDiaC' Schneider

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
why isn't it possible to use an older savegame with a new version. I
played with 0.16 and now I'm not able to load the savegame with 0.16.1
==== InitGame ====
********************
ERROR: Game Error: Savegame from an older version.
This should not happen.
-- andreas
- --
http://www.cynapses.org/ -- the geek source
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCSn6NwDudlFFJUr4RApmTAJ9Ac2QMnnP9eKrAG7kjjivVwuehHgCgvLqh
PXcWqaMvTGYwZXXQyQ0b+SE=
=Iqfg
-----END PGP SIGNATURE-----

--
Regards,
Sigurdur Axel

Brendan Burns

2005-03-30 12:58:38 UTC

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...")

--brendan

Post by Sigurdur Hannesson
Because in function WriteGame () in game/g_save.c, the date of the
binary is written to the savegame. Later, in function ReadGame ()
(same file), the DLL's date is compared to what's read from the file,
and the save isn't loaded unless the dates match.
For a simple hack, you could always hardcode a certain date string
instead of using the date when the game module was built (just replace
the strcpy (str, __DATE__); in WriteGame (), and strcmp (str,
__DATE__) in ReadGame ()).
And now I just spotted the oldsave cvar. By setting "oldsave" to 1,
you can bypass the check and load older/newer saves (assuming they are
still compatible, of course). That's even simpler. :)
On Wed, 30 Mar 2005 12:25:17 +0200, Andreas 'GlaDiaC' Schneider

--
Regards,
Sigurdur Axel

Laurent Desnogues

2005-03-30 14:06:54 UTC

IIRC, there used to be many pointers in saved games,
including pointers to functions that resulted in
crashes if you tried to load a save game with a
different game.so.

A hack I implemented at that time was to patch saved
games with the new addresses extracted from the .so.

All this may obsolete or partially wrong (it was so
long ago ;)

Laurent

Post by Brendan Burns
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...")
--brendan

--
Regards,
Sigurdur Axel

Sigurdur Hannesson

2005-03-30 14:40:26 UTC

Can you name any Quake II engine without this issue? 'Cause I thought
I'd seen the majority, but nowhere have there been any improvements to
the savegame system. Either way, I reckon I may just take a closer
look and try it out with different savegames. You know, for
curiosity's sakes. ;)

On Wed, 30 Mar 2005 07:58:38 -0500, Brendan Burns

Post by Brendan Burns
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...")
--brendan

--
Regards,
Sigurdur Axel

coyote

2005-04-05 15:07:21 UTC

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?

Vincent

Jamie Wilkinson

2005-04-06 02:04:24 UTC

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.
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
probably some way of compromising so at least the engine doesn't segfault
:-)

Post by coyote
Vincent

tei

2005-04-06 06:11:26 UTC

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?

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

Post by Jamie Wilkinson
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)

Post by Jamie Wilkinson
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

Post by coyote
Vincent

Brendan Burns

2005-04-06 14:31:58 UTC

A platform neutral saved game format would be cool... As tei points
out, it needs to serialize *everything* in the game state. Id is
already doing this, but they're doing it via memory dump rather than
true serialization. Not hard to change, but a fair amount of work.
Again, I'm not going to do this in the near future, but I'd be happy to
help guide someone through the process...

--brendan

Post by tei

Post by Brendan Burns
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?

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

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

Post by Jamie Wilkinson
probably some way of compromising so at least the engine doesn't segfault
:-)

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

Post by coyote
Vincent

brendanburns

2005-04-05 15:20:54 UTC

I think basically its figuring out what function/data pointers q2 stores in the savegame file and then doing a better job (e.g. not assuming that the pointers are correct) of linking up the saved game to the current version of quake2. basically a lot of calls to dlsym. I myself have not really looked at the file format that much, so a lot of the work would probably be exploration... (and documenting that exploration...)

--brendan

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?
Vincent

coyote

2005-04-06 09:26:43 UTC