2.3.2 not compatible with older versions' saves?

Advanced OpenGL source port fork from ZDoom, picking up where ZDoomGL left off.
[Home] [Download] [Git builds (Win)] [Git builds (Mac)] [Wiki] [Repo] [Bugs&Suggestions]

Moderator: Graf Zahl

Locked
User avatar
MagicWazard
Posts: 7
Joined: Sat Jul 16, 2016 6:37

2.3.2 not compatible with older versions' saves?

Post by MagicWazard »

Before I wrote up a formal bug on Mantis, I just wanted to ask if it was intentional behavior that GZDoom 2.3.2 wasn't compatible with saves from older versions (such as 2.1.0).
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: 2.3.2 not compatible with older versions' saves?

Post by Rachael »

Correct. The savegame code was rewritten recently, so old saves will not work.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: 2.3.2 not compatible with older versions' saves?

Post by Graf Zahl »

For the record, 2.4 will also break savegame compatibility, because there have been many changes already which move some saved values to different places. I won't bump savegame versions for the devbuilds, though, only for the final release. Although most savegames MIGHT still work I'm not going to risk it for an official version that all these changes may result in bugs.
User avatar
Enjay
Developer
Developer
Posts: 4720
Joined: Tue Aug 30, 2005 23:19
Location: Scotland
Contact:

Re: 2.3.2 not compatible with older versions' saves?

Post by Enjay »

Given that there have been a lot of quite important changes*, does this have an impact on the release schedule? i.e. do all the changes mean that 2.4 will be released sooner than originally anticipated, later or pretty much as you intended? I'm not nagging in any way; I'm just interested to find out what the impact on changes of this type are likely to have.

*Although I don't claim to understand the detail of all the changes, it's clear that there is a lot going on and that a lot of areas of the code are being made more logical and robust. It's interesting stuff to watch.
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: 2.3.2 not compatible with older versions' saves?

Post by Graf Zahl »

2.4 will be released when I consider the amount of new features sufficient and the engine has gone through a testin period with no new critical bugs being reported. I wish it could be sooner but I am a bit busy with work right now so I haven't even started with the statusbar stuff I'd really want to have ready for 2.4.
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: 2.3.2 not compatible with older versions' saves?

Post by Rachael »

Speaking of version bumps - with QZDoom releases, up until recently I have been bumping NETGAMEVERSION. Mostly because of what it says here: (version.h)

Code: Select all

// Version identifier for network games.
// Bump it every time you do a release unless you're certain you
// didn't change anything that will affect sync.
#define NETGAMEVERSION 235
User avatar
Nash
Developer
Developer
Posts: 1226
Joined: Sun Sep 25, 2005 1:49
Location: Kuala Lumpur, Malaysia
Contact:

Re: 2.3.2 not compatible with older versions' saves?

Post by Nash »

Graf Zahl wrote:For the record, 2.4 will also break savegame compatibility, because there have been many changes already which move some saved values to different places
What does it mean when you "move saved values to different places"? The deserializer can't handle new serialized variables being added into the save file?
User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: 2.3.2 not compatible with older versions' saves?

Post by Graf Zahl »

For scripting some variables have been moved into the script code, using the automatic serializer which saves them under different names. For my internal testing I can live with that but in an official release it'd only generate bug reports, especially if I also do this for a large quantity of Actor's own serializable properties, which I eventually plan. Implicit serializazion is a lot less susceptible to errors than explicit one.
Locked

Return to “GZDoom”