SCI0: RegionPath Wandering

[Kawa]

Clearly the stack is read bottoms-up, considering the bottom item is (LSL4 play:).

[robbo007]

Clearly the stack is read bottoms-up, considering the bottom item is (LSL4 play:).

Just checking

[doomlazer]

BTW. scummvm does not seem to "recognise" my game hash. So I never got it running with it.

You likely need to compile a custom version of ScummVM with your game added to the SCI detection table. While in development, only check for hashes which aren't going to change, so checking against resource.000 is a bad idea (until the final release).

When you release, you can either supply the custom SVM exe (ideally with the non-SCI engines removed so it's not 300+ MBs) with your installer or submit the hashes to SVM (which can take a while to get included in a formal release).

Since it seems to be pointing at the nextroom method, why not do what Kawa suggested and use "Print" to determine what statement is crashing the game? Try commenting out the checks in the nextroom "and" one at a time too. There's not that much in nextroom, so you should be able to find the problem with trial and error pretty quickly.

Edit: How did you see the error message in scumm if it wont run the game?

[robbo007]

BTW. scummvm does not seem to "recognise" my game hash. So I never got it running with it.

Edit: How did you see the error message in scumm if it wont run the game?

Thanks for the tips. I really appreciate this as it really helps me grasp the SCI language.
So I got the error from the SCIV debugger. I tried my game a while back in the scumm engine and that's when I got the hash error.

[lskovlun]

You likely need to compile a custom version of ScummVM with your game added to the SCI detection table. While in development, only check for hashes which aren't going to change, so checking against resource.000 is a bad idea (until the final release).

Sluicebox committed a fix recently that should hopefully fix this. It's in recent nightlies:

Date:   Tue May 7 19:15:54 2024 -0700

    SCI: Fix fallback detection for unknown fan games
   
    Fan games are now playable even without detection entries.
   
    Fallback detection takes the name of the game object and maps it to
    the ScummVM game id. Prior to this change, if we didn't know the game
    object name, we propagated this unknown internal string to the ScummVM
    game id for the entry, where it was guaranteed to fail.
   
    Now unknown game object names are mapped to the id for fan games.

[doomlazer]

Sluicebox committed a fix recently that should hopefully fix this. It's in recent nightlies:

Oh, good. I wondered why it didn't already do this.

Edit: @robbo, if you're not comfortable with the interpreter's debugger, Printf is useful for checking values. Use %s for strings and %d for numbers.

Code: [Select]

(repeat
(-= value 2)
(Printf {value: %d, (+ 1 value): %d} value (+ 1 value))
(breakif (== (self at: (+ 1 value)) 32767))
)

Looks like the sci0 template game calls this method FormatPrint instead of Printf. It also sometimes appears as proc255_4 in decompiled games. You can also do the same thing with the basic Print procedure and Format, but you'll need to have a buffer for the string, which is why PrintF is so convenient.

Code: [Select]

(method (nextRoom &tmp [str 50])
...
(Print (Format @str {value: %d\n(+ 1 value): %d} value (+ 1 value)))
...
)


[robbo007]

Thanks everyone. I got it working. It was good to see how the debugging tools work a little more also.

The problem was with the nextRoom method. It seems to need to have the previous room set and not the actual room where the bikini lady starts. (In my case the bikini lady starts walking from room 28)

Code: [Select]

(method (nextRoom)
(if
(and
(== (self at: (+ 2 value)) 3)
(== gRoomNumber 32) ; Quicki Mart
(gCurRoom notify: 0)
)
(repeat
(-= value 2)
(breakif (== (self at: (+ 1 value)) 32767))
)
)
(super nextRoom: &rest)
)
)