Old SCI0 Template Save Bug

[Doan Sephim]

While patching the old project (Betrayed Alliance book 1) I've run into a Save issue that I have also found in all the old fan games I've seen. If you run out of save spots, and save over a different file, sometimes I've experienced restoring that file only to discover that the new save did not overwrite the old.

I looked at the code for this, but the problem wasn't obvious to me.

Code: [Select]

(method (save)
(var strDescBuf[20], gameNum, oldCursor, hSound)
        Load(rsFONT gSaveRestoreFont)
Load(rsCURSOR gLoadingCursor)

= oldCursor (self:setCursor(gNormalCursor))
= hSound (Sound:pause(1))
(if(GetSaveDisk(TRUE))
(if(gPrintDlg)
(send gPrintDlg:dispose())
)
= gameNum (Save:doit(@strDescBuf))
(if(<> gameNum -1)
= oldCursor (self:setCursor(gLoadingCursor 1))
(if(not SaveGame(objectName gameNum @strDescBuf gVersion))
Print(
"Your save game disk is full. You must either "+
"use another disk or save over an existing saved game."
#font 0
#button "OK" 1
)
)
(self:setCursor(oldCursor HaveMouse()))
)
  GetSaveDisk(FALSE)
)
  (Sound:pause(hSound))
)Any thoughts?
Also, I know no one still uses the old template, and I am moving on from it myself for the next project. So these problems I'm experiencing with the old template will soon be no more!

[lskovlun]

I don't think the problem in in this procedure. It just calls save:doit to do the heavy UI lifting, and then SaveGame (a kernel call) to do the actual saving.

[Doan Sephim]

I captured the bug on video in a playthrough of jummybummy 2

Save is at 5:40 and death at 7:10 then restore doesn't load properly.

Thanks the the help locating the problem Iskovlun. I looked and am still looking. Will update if I find anything

[Doan Sephim]

I ran some tests to see if I could replicate this issue and here's what I found:

If you have your max 20 saves anytime you replace a save over a save file that is not the most recent, it seems to fail to save.

If you are replacing the top save file (the most recent), the save seems to work as normal.

So far, I have not been able to locate the the problem in the code, which isn't surprising to me as programming is my weakest area. I've focused my search in the Game Script, but haven't turned up anything except the save method I posted earlier. I suppose there could be a problem in the restore method, not the save...

[lskovlun]

@EricOakford had some problems with the saving code when he was doing the SCI01 port a while back. I don't know what came of it, but I think it was some sort of corruption bug. Another corruption bug (or perhaps the same one) came up with his port of sciAudio recently. At least some of that was due to a parsing bug in Companion (didn't like backslashes), which @Kawa fixed.

[Kawa]

If the save/load scripts don't have path separators in any of their strings, they're not affected by what I fixed.

[Doan Sephim]

If the save/load scripts don't have path separators in any of their strings, they're not affected by what I fixed.

Which fix is this? Will I be able to fit it with the old template?

I'd really like to resolve this as I think it is a big issue for the user. Players are going to want to save over earlier files, not the most recent.

[lskovlun]

@Kawa and I were referring to a fix for escape sequences and the use of '\\' for a path separator in particular. sciAudio wants to create a file in a subdirectory of the main game dir, and therefore failed. It manifested differently in SCI0 somehow.

The thread is here.

The second issue, which may be more relevant, took some digging to find, but it's here. It seems it was never resolved properly, only worked around.

[Doan Sephim]

Thanks for the links. So if I'm understanding correctly, it's not a problem in the template code at all. In that case, I'm even more at a loss! That's frustrating!

[gumby]

I've been bitten by this before as well.  EricOakford - you managed a workaround for SCI01, would that (or a similar approach) work for SCI0?

If not, a potential workaround could be to check the number of save games before launching the save dialog and if it's more than 20, delete the oldest one (or better yet, move it to an 'archive' directory).  Admittedly, not a great user experience but it might work.

[Doan Sephim]

If not, a potential workaround could be to check the number of save games before launching the save dialog and if it's more than 20, delete the oldest one (or better yet, move it to an 'archive' directory).  Admittedly, not a great user experience but it might work.

It'd be a better user experience than the game not saving at all! And while I like a lot of saves, I can't think of a single time I open one up more than 3 or so down.

[Collector]

Or automatically create a new "SAVE" subdirectory appended with an incremental number. I would not like a feature that automatically deleted any save games, even if the oldest.

[EricOakford]

I've been bitten by this before as well.  EricOakford - you managed a workaround for SCI01, would that (or a similar approach) work for SCI0?

No workaround here - the old template's save bug may be related to a newer issue I had in the SCI01 template. Specifically, SRDialog:doit. It can't be decompiled and thus falls back to disassembly. Somewhere in there, something didn't disasemble correctly, resulting in the duplicate saves bug.

The newer templates shouldn't have this problem to begin with, as they use the original source scripts as a basis. With SCI01, all that was needed was changes for the new FileIO function.

[Doan Sephim]

No workaround here

Sounds like I would need something like Gumby and Collector are suggesting then. When at 20 saves, to either archive the other saves to a new directory, or force new saves to a new directory.

[troflip]

I took a quick look at this.

It seems like even if you save over the most recent, it doesn't work properly. For instance,
- I save 20 games, A through T
- Then I try to save over T and give it the same name
- The result is that it deletes game A, and now there are two game T's.