[Not (really) a bug] 48.cab and savegames
Moderator: GZDoom Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
48.cab and savegames
Noticed that previous version savegames (all from 47i.cab I think) are going strange in the texture department with 48.cab.
This is marswar.wad map04.
http://pritch.mancubus.net/zdoom47-48.png
This is marswar.wad map04.
http://pritch.mancubus.net/zdoom47-48.png
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49074
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: 48.cab and savegames
Doesn't surprise me. ZDoom saves textures as indices in the texture table and as everybody knows the texture handling has been seriously altered for the latest version. The only really safe way to save a texture is with its full name.pritch wrote:Noticed that previous version savegames (all from 47i.cab I think) are going strange in the texture department with 48.cab.
This is marswar.wad map04.
http://pritch.mancubus.net/zdoom47-48.png
Re: 48.cab and savegames
That is correct. The texture indices have changed, so the textures stored in old save games have changed as well. I considered disabling loading of earlier demos but decided not to. Or is it just too annoying playing through a level in a savegame with incorrect textures until you reach the next level? I could rip out a bunch of savegame compatibility code if I dropped support for earlier savegames.Graf Zahl wrote:ZDoom saves textures as indices in the texture table and as everybody knows the texture handling has been seriously altered for the latest version.
Last edited by randi on Thu Oct 23, 2003 3:32 pm, edited 1 time in total.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49074
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: 48.cab and savegames
I don't think it is useful to keep compatibility with old savegames if they are screwed like this. A simple workaround that at least keeps all the textures that haven't changed would be to simply ignore all textures in older savegames. The best solution would be to store the textures' names. The new texture management is much more sensitive to any kind of change than the old one. Even small changes in a WAD that don't necessarily break a savegame can screw this up.randy wrote:That is correct. The texture indices have changed, so the textures stored in old save games have changed as well. I considered disabling loading of earlier demos but decided not to. Or is it just too annoying playing through a level in a savegame with incorrect textures until you reach the next level? I could rip out a bunch of savegame compatibility code if I dropped support for earlier savegames.Graf Zahl wrote:ZDoom saves textures as indices in the texture table and as everybody knows the texture handling has been seriously altered for the latest version.
Anyway, why is it necessary at all to save all the textures that haven't changed? Isn't it possible to save only those that are not the same as when the level started?
I know someone is bound to yell at me for this, but IMO keeping savegame compat at all seems pretty irrelevant.
Yes, some people might be half way through some megawad or something at the time of a version change - but they can just hang on to the older version until they finish - or warp to the level concerned in the new version - it's pretty easy to make your stats and inventory match what you had before if that is important.
The only time I can see losing a save being of any importance is if you had something special or unusual that you wanted to keep for posterity. But, if it's that important, just keep an old copy of the appropriate Zdoom exe handy to load the save.
Yes, some people might be half way through some megawad or something at the time of a version change - but they can just hang on to the older version until they finish - or warp to the level concerned in the new version - it's pretty easy to make your stats and inventory match what you had before if that is important.
The only time I can see losing a save being of any importance is if you had something special or unusual that you wanted to keep for posterity. But, if it's that important, just keep an old copy of the appropriate Zdoom exe handy to load the save.
Re: 48.cab and savegames
Because the game just dumps the current state of the level. It doesn't track what textures have and have not changed.Graf Zahl wrote:Anyway, why is it necessary at all to save all the textures that haven't changed?
- Ty Halderman
- ... in rememberance ...
- Posts: 282
- Joined: Thu Jul 17, 2003 9:53 pm
- Location: New Orleans LA
- Contact:
That would suck. I have about 15-20 savegames here (I usually play a wad until I get bored, then switch to another, etc.), and say, if I were to upgrade to a newer version with all those savegames still here, then all my progress will be lost. I'd rather have partial earlier savegame support with screwed textures than no earlier savegame support at all.Ty Halderman wrote:I fully agree with not keeping savegame compatibility across versions. In particular,Less is more. Nuke it and be cleaner, I say.Randy wrote:I could rip out a bunch of savegame compatibility code if I dropped support for earlier savegames.
- Ty Halderman
- ... in rememberance ...
- Posts: 282
- Joined: Thu Jul 17, 2003 9:53 pm
- Location: New Orleans LA
- Contact:
Why can't you keep your previous version of the EXE to play your previous version of the savegames? I've got every version back to 1.18 available to run on this PC.
The point is, if Randy's having to waste time and effort trying to be sure demos and savegames are backward-compatible, he's spending time he could better make use of on stabilizing and releasing 2.1 (not to mention the DS in WFDS!)
The point is, if Randy's having to waste time and effort trying to be sure demos and savegames are backward-compatible, he's spending time he could better make use of on stabilizing and releasing 2.1 (not to mention the DS in WFDS!)