LSL5 initial videopoker jackpot value discrepancy DosBox/ScummVM

[miracle.flame]

Again this is about SCIC decompiled scripts and my suspected scripts are Cycle.sc where $1000 is directly mentioned or Main.sc...

The matter is the Tramp casino jackpot value which starts at $1000 in DosBox playthrough with decompiled scripts while in ScummVM the same scripts result in $0 value... which is wrong I presume. Any idea how to fix this?

[Kawa]

First of all: $1000 as a raw literal value means 1000 in hexadecimal or 4096 in regular people numbers, not to be confused with 1000 dollars. Now that that's out of the way...

Looking at the original code, I can find exactly one instance where the jackpot is set to 1000 (dollars, that is) and that's when you win whatever the jackpot is at the time. You win it, you get so many silver dollars, and the jackpot resets to 1000. Which tells me that it doesn't actually start at 1000 dollars at all, not by any script's doing.

But looking at Sluicebox's decompilation, there's an extra bit in script 155, the password room, in the LoadPassword function. In the original source, it tries to open the password file, and if that succeeds it reads the password and jackpot value. But in Sluicebox's decompilation and mine alike, there's an else: if it failed to open MEMORY.DRV, it defaults to "NONE" and 1000 dollars.

Another funny part is that ScummVM, for intricate technical reasons involving some of the platforms it can run on being overbearing about file security, does not necessarily use the same files in the same position, both for gimmicks like the above and saved games.

[miracle.flame]

Ouch, I've realized this was submitted on incorrect board, should have been SCI Syntax Help. Any way to move it?

That MEMORY.DRV condition sounds cryptic... why on earth would there be such logic? I suppose finding MEMORY.DRV is the more likely scenario so what then?

[Kawa]

If you can't open a file for reading, it may not exist. If you can't open it for writing, you may be on a write-protected disk. That's why you check. This goes for everything involving files, not just in SCI.

[miracle.flame]

I've got an e-mail from sluicebox I guess which helped me to understand that MEMORY.DRV is actually a dummy name for file containing only the password and jackpot value. Did not strike me as obvious until now. He also wrote a ScummVM patch for this issue
https://github.com/scummvm/scummvm/commit/5ffad3bbfeafbb56b4c2c22cd0cb1a7cb4d46ae1

I've tried to implement it in my Main.sc this way
before:
   global160
   global161
   global162
   global163
   gBlondeX
   gBlondeLoop
   gRedHeadX

after:
   global160
   global161
   global162
   global163 = 1000
   gBlondeX
   gBlondeLoop
   gRedHeadX


After compiling the patch I've deliberately restarted the game twice and played to the point of casino just to see the jackpot is $5 which may be a value remembered from the previous playthrough. Now I'm puzzled, not sure if I've made incorrect code change but I would expect the value to be either 0 or 1000.

[miracle.flame]

Jackpot!
After searching for ScummVM equivalent of MEMORY.DRV as this one seemed to be ignored I've found
lsl5-memory.drv
lsl5-fallback-memory.drv
lsl5-fallback-1-memory.drv
under %AppData%\Roaming\ScummVM\Saved Games\

Removing those prevented loading the value from them and a proper global163 value loaded.

[Kawa]

The patch note says that the value is read from MEMORY.DRV on starting a new game. When restarting from anywhere after the intro sequence, the password screen is skipped -- you end up right in the PornProdCorp lobby, with the two points from getting and spilling the coffee already there. Since these things start at zero by default if not specified otherwise, restarting leaves the jackpot at that default zero. That's why the patch changes the initial value to 1000 in the heap section itself, not in any actual code. The fix in that patch doesn't bother calling LoadPassword.

In my test just now on a ScummVM that doesn't have this patch yet:

• Opened the debugger on the Sierra Logo screen. vv g 163 said zero.
• Skipped ahead to the password screen, why bother, new game. The debugger now replied 1000, as expected.
• Restarted the game, from the in-game control panel. Since we've already seen the intro, we end up in the lobby again. The debugger says the jackpot is zero, because restarting causes all those variables to be reset and we skipped the introduction and therefore the password screen.

All this is as expected.

Your "after" is basically identical to what Sluicebox did in that patch, and you already figured out why you couldn't see a difference.

[lskovlun]

The patch note says that the value is read from MEMORY.DRV on starting a new game. When restarting from anywhere after the intro sequence, the password screen is skipped -- you end up right in the PornProdCorp lobby, with the two points from getting and spilling the coffee already there. Since these things start at zero by default if not specified otherwise, restarting leaves the jackpot at that default zero. That's why the patch changes the initial value to 1000 in the heap section itself, not in any actual code. The fix in that patch doesn't bother calling LoadPassword.

And it's annoying too, because LSL5 already uses the MemorySegment kernel call to retain some data across restarts. But not the poker stuff 

[Kawa]

To be fair, does MemorySegment-ed stuff survive cold starts?

[lskovlun]

To be fair, does MemorySegment-ed stuff survive cold starts?

No it doesn't.

[Kawa]

Well, there you go.