Author Topic: [SOLVED] SCI0 - Variables that aren't reset by Restore  (Read 8298 times)

0 Members and 1 Guest are viewing this topic.

Offline Doan Sephim

Re: SCI0 - Variables that aren't reset by Restore
« Reply #15 on: December 12, 2020, 06:01:29 PM »
This is about as far as I can help.
Thanks. I appreciate all the help. I'm going to tinker about with it to see if I can get it running smoothly

Offline Kawa

Re: SCI0 - Variables that aren't reset by Restore
« Reply #16 on: December 12, 2020, 06:38:19 PM »
One thing you could try is to open the persist file in Notepad to check what's actually in there.

Offline Doan Sephim

Re: SCI0 - Variables that aren't reset by Restore
« Reply #17 on: December 12, 2020, 07:32:35 PM »
One thing you could try is to open the persist file in Notepad to check what's actually in there.

I viewed the tmp file with notepad and it looks like it recorded the variables perfectly! the first value was 3 and the other two values were 1's (which is what they were originally designated as in the main script). So it looks like all I need to do is get the inputting of these values correctly in the replay method.

The current code only pulls "0" values for the variables. I'm not sure what's going wrong though

Code: [Select]
(= fileHandle (FOpen "persist.tmp" 1)) ;there's a historical typo in SCI.SH
(if (!= fileHandle -1)
(= gPersistMe (ReadNumber (FGets @str 8 fileHandle)))
(= gAlsoMePlz (ReadNumber (FGets @str 8 fileHandle)))
)
(FClose fileHandle)

Does it have anything to do with the "historical typo"? Mentioned in the comment?
« Last Edit: December 12, 2020, 08:00:17 PM by Doan Sephim »
Artificial Intelligence Competition

Offline Kawa

Re: SCI0 - Variables that aren't reset by Restore
« Reply #18 on: December 12, 2020, 08:33:02 PM »
The typo is that the two "open for reading" modes had their numbers switched around in Brian Provinciano's original SCI.SH file, from the SCI Studio SCI0 template. Phil kept the error in, switching them right-side-up when compiling SCI11 code, so as to not re-break SCI0 games. That's why there's a plain 1 in the snippet I wrote.

Look in SCI.SH yourself, it's documented on the spot.

I'm not sure why it's returning zeros though.

Offline Doan Sephim

Re: SCI0 - Variables that aren't reset by Restore
« Reply #19 on: December 12, 2020, 08:39:10 PM »
You're a wealth of knowledge! I'll keep muddling

Offline Doan Sephim

Re: SCI0 - Variables that aren't reset by Restore
« Reply #20 on: December 13, 2020, 11:50:41 AM »
Okay! I have the code reading the file numbers into the variables now, so that's good! I'm just not finding the right place to PUT that code. I originally was putting in the Game script's "replay" method, but I don't think that's the right place. I'll keep looking.

So this is getting tricky. Basically, I don't think there is any method or procedure that runs exclusively when you restore the game, which is where I would need to put the code to re-orient the variables.

So the work-around would be to set up a variable (gRestoringTheGame) which I set to TRUE when I restore the game. Then in the Main Script's doit method, I check if this variable is true, run the "read the variable from the temp file" code, then set gRestoringTheGame back to FALSE.

Of course, the obvious hurdle I forgot about was that gRestoringTheGame ITSELF would be set back to FALSE upon the restore of the game, and then the doit method wouldn't read it as TRUE and run the code.

So, I have to write gRestoringTheGame into the Temp file also, then in the Main Script's doit method, read the Temp file for gRestoringTheGame to make it TRUE, which will in turn trigger to read the rest of the Temp file for the other variables, then set gRestoringTheGame to false, so it's not repeating this process every cycle of the game...and while I know this sounds superfluous, it's not.

If you start a new game and there is not gRestoringTheGame flag to stop the constant writing of variables from the temp file, the new game's variables will be overwritten before the player even does anything.
« Last Edit: December 13, 2020, 12:26:59 PM by Doan Sephim »
Artificial Intelligence Competition

Offline Kawa

Re: SCI0 - Variables that aren't reset by Restore
« Reply #21 on: December 13, 2020, 01:46:44 PM »
Okay! I have the code reading the file numbers into the variables now, so that's good! I'm just not finding the right place to PUT that code. I originally was putting in the Game script's "replay" method, but I don't think that's the right place. I'll keep looking.

So this is getting tricky. Basically, I don't think there is any method or procedure that runs exclusively when you restore the game, which is where I would need to put the code to re-orient the variables.
But Game::replay (in game.sc) is almost explicitly what the engine invokes when you restore a game.

It actually invokes Template::replay (in main.sc, class name may vary), but that calls Game::replay at the end. Either one of them should be a fine place to put the "reload variables from persist.tmp" code.

Offline Doan Sephim

Re: SCI0 - Variables that aren't reset by Restore
« Reply #22 on: December 13, 2020, 01:54:37 PM »
Okay! I have the code reading the file numbers into the variables now, so that's good! I'm just not finding the right place to PUT that code. I originally was putting in the Game script's "replay" method, but I don't think that's the right place. I'll keep looking.

So this is getting tricky. Basically, I don't think there is any method or procedure that runs exclusively when you restore the game, which is where I would need to put the code to re-orient the variables.
But Game::replay (in game.sc) is almost explicitly what the engine invokes when you restore a game.

It actually invokes Template::replay (in main.sc, class name may vary), but that calls Game::replay at the end. Either one of them should be a fine place to put the "reload variables from persist.tmp" code.

Sounds good! I'll defer to your knowledge and give it another looking into. It would obviously be far superior than my convoluted workaround!

EDIT: Success! It does seem to work just right in the Main Script. Although I think I tried it before, I must have put the code in the wrong place:

Code: [Select]
(method (replay)
(TheMenuBar draw:)
(SL enable:)
        ; PUT IT HERE
(if (DoSound sndSET_SOUND)
(SetMenu MENU_TOGGLESOUND #text {Turn Off})
else
(SetMenu MENU_TOGGLESOUND #text {Turn On})
)
(super replay:)
; DON"T PUT IT HERE

)
« Last Edit: December 13, 2020, 02:45:22 PM by Doan Sephim »
Artificial Intelligence Competition

Offline Doan Sephim

Re: SCI0 - Variables that aren't reset by Restore
« Reply #23 on: December 13, 2020, 02:38:25 PM »
I'm going to go ahead and call this on solved! Thanks to Kawa who did all the heavy lifting. You have now provided me with 1 more tool to play with  ;D

Offline Kawa

Re: [SOLVED] SCI0 - Variables that aren't reset by Restore
« Reply #24 on: December 13, 2020, 03:34:17 PM »
If I can't be arsed to be productive myself, at least I've helped someone else be.

Offline Kawa

Re: [SOLVED] SCI0 - Variables that aren't reset by Restore
« Reply #25 on: December 15, 2020, 02:57:08 PM »
I have found a new trick thanks to this puzzle. Unfortunately it's not available in SCI0.

While studying the LSL5 source code, I noticed two uses of the MemorySegment kernel call, regarding which room the game should restart in.

According to the SCI11 interpreter source:
Code: [Select]
/* Allow up to 256 bytes of game data to be preserved when a restart/restore
 * is performed. The first argument is a function code that determines if
 * data is being SAVED FROM the game or being RESTORED TO it.
 * SAVE FROM:
 * Argument 2 - pointer to data area to be saved.
 * Argument 3 - size in bytes of data to be saved; 0 size indicates a
 * string is to be saved. If the size of the data to be
 * saved exceeds 256 bytes, then only the first 256 bytes
 * will be saved.
 * RESTORE TO:
 * Argument 2 - pointer to data area to receive saved data.
 * Argument 3 - *** NOT required because the RESTORE TO function uses
 * the size parameter from the last SAVE FROM function to
 * determine the size of the data area to be restored.
 */
There's a word memorySegment[129] that doesn't get cleared when the engine restarts. The zeroth entry is where the size of the last save is stored.

Larry 5, during initialization: (if (GameIsRestarting) (MemorySegment MS_RESTORE_TO @restartRoom))
During restart: (MemorySegment MS_SAVE_FROM @restartRoom 2)
Once the intro finishes: (= restartRoom 160)

So that once you've entered room 160, the PornProdCorp Lobby, restarting will put you right there instead of going through the whole introduction again, even though all variables including resetRoom are reset.

This is actually a common trick in SCI1 and later!

Edit: implemented it in The Dating Pool lol
« Last Edit: December 15, 2020, 03:37:34 PM by Kawa »

Offline Doan Sephim

Re: [SOLVED] SCI0 - Variables that aren't reset by Restore
« Reply #26 on: July 08, 2022, 12:35:46 PM »
My external file to keep track of deaths is not quite working properly, to say the least.
I've attached some pictures of the file open in the notepad and the first two look exactly as they should. The first number is the total times died, so the first one is 1, then 2 for the second, but then it goes to 29558 when it should be "3". The other numbers represent certain kinds of death, so there is a "1" in the first, two "1"s in the second picture, and then the numbers go crazy again. The "2" sticks out, but that is correct, as it means the player experienced the same "death" twice. But two of the huge number ones should still be 0.

Any idea how or what might be going on to get these numbers saved out?
My writing out of numbers code looks like this:
Code: [Select]
(= fileHandle (FOpen "persist.tmp" fCREATE))
(if (!= fileHandle -1)
(Format @str "%6d %6d %6d %6d %6d %6d %6d %6d" [gDeaths 0] [gDeaths 1] [gDeaths 2] [gDeaths 3] [gDeaths 4] [gDeaths 5] [gDeaths 6] [gDeaths 7])
(FPuts fileHandle @str)
)
(FClose fileHandle)
One question I do have is what the "6" in "%6d" stands for.

I don't think it's an error in my code to change the variable in the script itself, as my code for that is simply adding by ones:
Code: [Select]
(if (not [gDeaths 6])
(++ gUniqueDeaths)
)
(++ [gDeaths 6])
(= dyingScript (ScriptID DYING_SCRIPT))
(dyingScript
caller: 711
register:
{\nHungry things have to eat. But maybe next time try not letting the food be you!'}
)
(gGame setScript: dyingScript)
It feels like the numbers must be getting mangled in the saving "out" process, but I'm kinda at a loss.

Offline troflip

Re: [SOLVED] SCI0 - Variables that aren't reset by Restore
« Reply #27 on: July 08, 2022, 01:57:26 PM »
I dunno if this helps, but those weird numbers are the following ascii letters:

svp[space]altn

which when you swap the order for each 16bit value (since SCI is little-endian), you get

"vs plant"

Sounds like maybe you overwrote the gDeath part of memory with a string? What variables come before the gDeath array in your global vars?
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline Doan Sephim

Re: [SOLVED] SCI0 - Variables that aren't reset by Restore
« Reply #28 on: July 08, 2022, 02:04:24 PM »
I dunno if this helps, but those weird numbers are the following ascii letters:

svp[space]altn

which when you swap the order for each 16bit value (since SCI is little-endian), you get

"vs plant"

Sounds like maybe you overwrote the gDeath part of memory with a string? What variables come before the gDeath array in your global vars?
Thanks for the explanation.
the gDeath array is near the top, but looks like this:
Code: [Select]
(local
fileHandle
[str 10] ; Used to read from an external file and update several variables
[gDeaths 10] = [0 0 0 0 0 0 0 0 0 0]
And the procedure I'm using to "write-in" the variables from the external file is:
Code: [Select]
(procedure (ReadTempFile i)
(= [gDeaths i] (ReadNumber (FGets @str 8 fileHandle)))
)
Is there an issue with this?

Offline troflip

Re: [SOLVED] SCI0 - Variables that aren't reset by Restore
« Reply #29 on: July 08, 2022, 02:11:56 PM »
According to the docs, FGets takes 3 parameters:

http://scicompanion.com/Documentation/Kernels/FGets.html?highlight=fgets

And it returns the number of bytes read, not the string pointer.
Unless you're using some different kernel, or the docs are wrong, it doesn't look like this code works at all?
Check out my website: http://icefallgames.com
Groundhog Day Competition


SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.024 seconds with 23 queries.