Community
SCI Programming => SCI Syntax Help => Topic started by: Doan Sephim on December 27, 2020, 10:42:15 AM
-
How difficult would it be to create an autosave function that runs whenever the player enters a new room?
Ideally, it would always replace the previous autosave file and be located at the top of the restore window with the name "autosave"
I'm looking in the Game script and found the Save method, but I'm not sure how to call this method without producing a window. I'd like this to go on "behind the scenes," as it were.
(method (save &tmp [strDescBuf 20] gameNum oldCursor hSound)
(Load rsFONT gSaveRestoreFont)
(Load rsCURSOR gLoadingCursor)
(= oldCursor (self setCursor: gNormalCursor))
(= hSound (Sound pause: 1))
(if (GetSaveDisk TRUE)
(if gPrintDlg (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)
)
Not having a feature like this isn't a big deal and I place a low priority on implementing it, but it certainly would be nice!
I'm going to experiement with this bit of code here, but if anyone has better ideas or guiding thoughts, let me know.
(SaveGame objectName gameNum @strDescBuf gVersion))
-
You actually have most of the answer right there already: (SaveGame (gGame name?) 0 "Autosave" gVersion), in perhaps Main::newRoom.
-
Has anyone tried decompiling QfG4 yet? It has an autosave.
-
You actually have most of the answer right there already: (SaveGame (gGame name?) 0 "Autosave" gVersion), in perhaps Main::newRoom.
Wouldn't that save on every new room? I would think you would want it to only auto save on entry to a dangerous room. Perhaps have a flag for new room that can be set if there is any danger.
-
Or just put that line in the init for those specific rooms lol.
How difficult would it be to create an autosave function that runs whenever the player enters a new room?
It wasn't specified that it should only autosave in dangerous rooms~
Has anyone tried decompiling QfG4 yet? It has an autosave.
Picking a random room, 600, I found this at the bottom of its init:(if (and (proc0_4 380) (!= gPrevRoomNum 810))
(gGame save: true)
)Notice the extra parameter. Normally, Main::save just calls Game::save. QFG's Glory::save only does that if false or nothing is given. If it's true, it does a lot of stuff but ultimately saves "Automatic Save".
-
Remember that it names the autosave "Automatic Save" and overwrites any previous autosave, so there is more to the save method than previous SCI versions, as I would assume you would realize. Also, the game control has an autosave option for the player to be able to turn it on and off.
-
You actually have most of the answer right there already: (SaveGame (gGame name?) 0 "Autosave" gVersion), in perhaps Main::newRoom.
Yup, this does it very cleanly! Simple and effective. And I suppose I could make a toggle if someone wants to turn off the autosave and have a more *authentic* Sierra game experience :P
Thanks again Kawa!
Here's the code in the Main script if any one needs it:
(method (newRoom roomNum picAni)
(DisposePrintDlg)
(Load rsFONT gDeadFont)
(Load rsFONT gDefaultFont)
(Load rsFONT gSaveRestoreFont)
(Load rsCURSOR gNormalCursor)
(Load rsCURSOR gLoadingCursor)
;(SaveGame (gGame name?) 0 "Autosave" gVersion)
(super newRoom: roomNum)
(if (< argc 2)
(= gDefaultPicAni (Random 0 5))
else
(= gDefaultPicAni picAni)
)
(SaveGame (gGame name?) 0 "Autosave" gVersion)
)
-
Can you call it a "more *authentic* Sierra game experience" when QfG4 had it?
-
Can you call it a "more *authentic* Sierra game experience" when QfG4 had it?
Showing my ignorance here. I never played QfG4! Watched my bro play it a million times, but never got familiar with it's save features.
My guess would be that "auto-save" and "Sierra adventure" are two terms not generally thought of together, outliers notwithstanding.
-
QfG3 had autosave, too... although they only used it like 2 or 3 times, if I recall right.
-
QfG3 had autosave, too... although they only used it like 2 or 3 times, if I recall right.
Confirmed, looks about the same as in QfG4. Twelve hits for (gGame save: 1).
-
While the autosave feature does work as intended, it does have a side effect that I'm not sure how to best handle.
With the autosave code in, it has led to the "change directory" button in the "save game" window to cause a "oops! You tried something" error and crashes. Not sure how to fix that. If worse comes to worst, I could just delete the "change directory" button from the game. I think that would bother less than 1% of people.
Any ideas?
-
Does it also happen in ScummVM? That might give more information.
-
I wouldn't recommend testing against ScummVM in this case (is that a first?), at least not at first. ScummVM does weird things in order to cope with unusual saving schemes in various games (think Phantas, Shivers, Mother Goose...). Also replaces the save UI.
-
Well, unless you can find a debug build of the correct SCI so you can see the whole error message instead of only a number...
Also, you can turn off the new save UI.
-
I have not tested with ScummVM, which I think uses it's own save system (but I'm no expert).
I want to make sure this is ironed out for people who want to play on era hardware, too. I think just removing the change directory will be my go to answer, which I thought would be easy enough, but I cannot even find WHERE that logic is!
-
How exactly the files themselves are saved doesn't matter. If the SaveGame kernel call ends up doing some Weird ScummVM Stuff behind the scenes, nothing about the "change directory" button oopsing out would change in any way, because the classic UI is handled in script.
More to the point, in SCI0 the save/restore dialog box is in script 990, syswindow.sc, as SRDialog.
-
Thanks Kawa! With you pointing me to the correct script, I was able to remove the change directory stuff. Loses a touch of old school authenticity but I don't think anyone will mind. Also, can't crash the game if you can't push the button ;D
-
The best solution of course would be to not have it crash at all. All a release terp's oops message would give is a number, which may help a lot depending on the number.
-
Yeah, it sounds like removing that button is really just papering over a latent problem.
-
Yeah, it sounds like removing that button is really just papering over a latent problem.
I agree, but it's the best available solution for now, and it's one that is easy to reverse if/when the time comes. It's also a very low cost to pay seeing as how I think it is very few people who even use that availability. Plus it does save ever so slightly on heap ;D
-
Does the change directory button in the restore dialog cause the same crash?
-
Does the change directory button in the restore dialog cause the same crash?
Yes it does...well, it did until I removed it
-
ScummVM does allow the original save GUI but it grays out the Change Directory button.
Aldo, in Ryan's case it's a SCI0 game so debug is built in.
-
Aldo, in Ryan's case it's a SCI0 game so debug is built in.
I'd say the "oops" error would be more of a "PMachine" error if it had the full debugger, with details like "heap at odd address" (oops #15) or "foo is not a selector for bar" (#5). But that's going by what SCI11 does so I wouldn't rightly know either way. Which brings me to the question, does clicking the CD button say just "oops", or does it include an error number?
Makes sense that ScummVM would disable the CD button though, considering it also lifts the 20 game limit.
-
Is the the 20 game limit in the interpreter or one of the system scripts? If that limit was removed it would make the need of the change directory button/function irrelevant.
-
The 20-save limit is not really the reason why Change Directory is disabled/unsupported. Rather, it's because ScummVM is rather restrictive on what you get to do with paths. You can read files (i.e. game assets) in directories below the game dir, but not create or change them. Many SCI games create files to save various preferences and such (and for the custom save schemes I mentioned). This was one of the big changes during the FreeSCI takeover; FreeSCI just accessed paths as usual.
And the reason for all this is platform support.
-
And the reason there's a 20 game limit is, I think, because that's roughly how many copies of the heap you could fit on a single diskette, with compression, including the catalog file.
-
I have never thought about the why of the 20 game limit, but that would make sense. It is possible to change the save games in the middle of playing. It seems to read the catalog file every time the restore dialog is called.
-
Well, how else are you gonna display an up-to-date list of saved games, knowing that the player can at any point in time switch to a different diskette?