[SOLVED] "Bad opcode $4e" crash re: "setLocales" in Sierra Script SCI0 game

[MusicallyInspired]

I decided on a whim to revisit KQ2SCI0 and wanted to convert the whole thing to Sierra Script. It all compiles fine and works but on one screen in-game in particular that has a certain Locale set, when I exit it into a room that doesn't have a Locale the game crashes upon entering the new room saying "bad opcode $4e." If I comment out setLocales in the previous room the crash goes away. The only thing different about this room compared to others is that it changes rooms based on the ego being inRect. Other inRect codes work fine elsewhere in the game, including ones that change rooms. So I'm guessing something in the Locales code is broken in the conversion to Sierra Script in certain cases maybe when disposing or something? But only sometimes? Because there's another room with "forestLocale" and an inRect code to change rooms and the code is virtually identical.

Sierra debug Send Stack readout displays:

Code: [Select]

(??? doit:)
(??? doit:)
(regions eachElementDo:)
(Game doit:)
(KQ2 doit:)
(KQ2 play:)
The Locale is set in its script with the "(public)" code block as "forestLocale 0", which is also what the Locale instance is called.

[troflip]

Possibly. What does the resulting Locale code look like?

Have you tried it in ScummVM to see if it gives a better error message for the crash?

[MusicallyInspired]

I can't seem to run it in ScummVM. It just says "Game data not found" even though it recognizes it as an SCI game of some kind and gives a message to report the file hashes to the ScummVM team.

Here's the setLocales method code block from Game.sc:

Code: [Select]

(method (setLocales scriptNumbers &tmp i scrNum hScript)
(for ( (= i 0)) (< i argc)  ( (++ i)) (= scrNum [scriptNumbers i]) (= hScript (ScriptID scrNum)) (hScript number: scrNum) (gLocales add: hScript) (hScript init:))
)
Comparing to the SCI Studio code original it looks pretty good. I don't get it. I can just not use Locales for that room to get around it as it seems to work everywhere else, but if it's a problem with the compiler or something or the conversion process I'd figure it would be important to point out.

[lskovlun]

It looks like something is being miscompiled in a bad way. But the send stack looks like the problem is not in the locale at all, but in regions? Are you using regions in the game as well?

[MusicallyInspired]

Yes, but there are no regions in either of those two rooms. Are Locales sub-objects of Regions? I didn't think so but...

[lskovlun]

Yes, but there are no regions in either of those two rooms. Are Locales sub-objects of Regions? I didn't think so but...

No, what I was really getting at is that there is something stuck in the regions list, possibly in a script that has been disposed (i.e. a dangling pointer). If so, the next step would be to find out what that is (check before entering the faulty room). From the debugger. press 'g' (inspect global variable) and select number 6. Then press 'c' to step through the list. Then repeat after the crash dumps you in the debugger. (oh, but I don't think it does, does it?)

Come to think of it, if you have leftover files from the SCI Studio era, you may need to delete some of them to make sure you are really compiling from scratch. Some variable numbers were out of sync between Brian's template game and the SCI Companion one (the current room number being a notable example; the usual methods for room teleportation didn't work with Studio games).

[MusicallyInspired]

No, what I was really getting at is that there is something stuck in the regions list, possibly in a script that has been disposed (i.e. a dangling pointer). If so, the next step would be to find out what that is (check before entering the faulty room). From the debugger. press 'g' (inspect global variable) and select number 6. Then press 'c' to step through the list. Then repeat after the crash dumps you in the debugger. (oh, but I don't think it does, does it?)

Yes, if you launch SCIV.EXE with "-d" it'll drop you into the debugger on a crash before it exits to DOS. That's how I got that send stack list. I'll do that.

The only regions I have in the game are waterRegions and beachRegions. The game starts off on a screen on the beach so right off the bat you're in a region. The BeachRegion is used to control ego's change in view resources as he moves deeper into the water until he's swimming via control colours painted into the Picture. It also has custom said statement responses. waterRegions are the same except they don't have unique said statement handling and they don't handle control colours that get deep enough to swim in.

I tested navigating through the game and avoiding all waterRegions to enter the room that crashes and it still crashes.

Also, global variable 6 in my game's case is gIntro (the introduction sequence). gRegions is number 8, is that the right one? It just says "regions" when I look at it in the debugger both before and after the crash.

I tried removing the setRegion line in the first room and then navigating to the crash room and it still crashes. gRegions still says "regions" in debugger.

Come to think of it, if you have leftover files from the SCI Studio era, you may need to delete some of them to make sure you are really compiling from scratch. Some variable numbers were out of sync between Brian's template game and the SCI Companion one (the current room number being a notable example; the usual methods for room teleportation didn't work with Studio games).

Ok, which files should I delete? Does it not convert over every script in the game to Sierra Script when making the conversion?

EDIT: This seems to be inconsistent. Before I distinctly remember removing the setLocales line in the previous room would avert the crash. Now it's crashing regardless but it's giving a different error this time: "$52" instead of "$4e". I even removed all regions and locales from the beginning of the game to the crash room and it still crashes. Same send stack. I've recompiled a few times since so this may point to a compilation error of some kind after all?

EDIT 2: Something residual is definitely going on. I just painstakingly removed all lines of code that sets regions and locales and it still crashes on this one room alone with the same error. No regions or locales anywhere in the game.

[troflip]

I tried removing the setRegion line in the first room and then navigating to the crash room and it still crashes. gRegions still says "regions" in debugger.

It's just using the actual instance name of the regions list, which is "regions" (defined in Game.sc). It doesn't know anything about gRegions, the global variable that points to "regions".

EDIT 2: Something residual is definitely going on. I just painstakingly removed all lines of code that sets regions and locales and it still crashes on this one room alone with the same error. No regions or locales anywhere in the game.

Well, the room you're in is also added to the regions list. So that must be what's going on. Somehow a room is still in there but it's been unloaded. The difference in which "bad opcode" you're seeing is just a red herring... it's basically calling into code that *was* a room, but is now something else - so it's just garbage.

Anyway, with this new info, either this means:
- the room you're coming from got unloaded (as expected) but not removed from the regions list, or
- the new room you're in somehow go unloaded. (Make sure its script number isn't in the DisposeLoad call in startRoom in Main.sc, or that you don't have a call to DisposeScript somewhere with that script number)

Can we see the code that calls newRoom based on the ego being inRect? It doesn't accidentally call gGame's newRoom, does it? Because (see attached) if I do that I get a stack very similar to what you're seeing:

[MusicallyInspired]

Can we see the code that calls newRoom based on the ego being inRect? It doesn't accidentally call gGame's newRoom, does it? Because (see attached) if I do that I get a stack very similar to what you're seeing:

Oof.

That was it. It was gGame not gRoom. I guess it wasn't as identical to another room's inRect changeroom call as I had thought. That was a silly mistake I should have caught beforehand. Thanks, guys. Sorry to waste everyone's time!

[troflip]

I hate that Sierra chose to name those two very different methods the same!