SCI: QFG1 EGA: Obscure Freeze in Brigand Fortress Entrance

[ArthurWalden]

I am using ScummVM version 2.9.0.

In the EGA version of Quest for Glory 1, if you set off the jack-in-the-box alarm by opening the cabinet (i.e. typing that command), alerting the archers, and THEN trip over the trip rope, the game freezes.

I admit this is a very obscure bug and may not be worth fixing, but I thought I'd bring it up anyway.

On a related note (so that I don't think I need a separate ticket for it), if you simply look at the cabinet containing the jack-in-the-box alarm (so the game mentions the hasp on it) and then trip over the trip rope, the alarm doesn't go off, which doesn't make logical sense. (The game doesn't freeze in that case, however.)

I am playing the GOG version of the game.

I am running the game on Windows Home 11, version 24H2.

[ArthurWalden]

I just discovered that the game also freezes if you set off the alarm by typing "open cabinet" and then type "step over rope."

[sluicebox]

This appears to be a scummvm bug; the freeze does not happen in the original. I can reproduce using several qfg1 versions.

It worked in scummvm 1.3.0 (2011) but not in 1.5.0 (2012)

To reproduce from scratch in original or scummvm:

1. Create a character and start the game
2. Type razzle dazzle root beer
3. ALT+T to teleport to room 94
4. Walk right (and up a little) to the box and type open box
5. Walk up to trip

The script is stuck waiting a motion to complete from egoTripsSouth:changeState(0)

[eriktorbjorn]

I tried bisecting, and landed on this commit:

bfa26ffc44f80e4eb3d8590f5f865cda6a5188b7 is the first bad commit
commit bfa26ffc44f80e4eb3d8590f5f865cda6a5188b7
Author: Filippos Karapetis <md5@scummvm.org>
Date:   Mon Jun 13 16:43:04 2011 +0300

    SCI: Reverted commit db7dea3

    The original check was correct, and the associated MG bug (#3049515) has
    actually been fixed with another commit.

    Fixes bug (regression) #3315639 - "Character Glitches in KQ4 SCI".
    Many thanks to waltervn and wjp for their help on this

 engines/sci/graphics/compare.cpp | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

The reverted commit was to address https://bugs.scummvm.org/ticket/5278 but I have no idea what the current status of that bug is.

Re-reverting (deverting?) the commit seems to fix the QFG1 problem, but presumably breaks https://bugs.scummvm.org/ticket/5755 again?

I'm way out of my depth here...

[sluicebox]

I understand the bug. It's a script bug in the original that only works by accident due to undefined out-of-bounds memory read by a garbage instruction produced by a bug in Sierra's script compiler.

The ScummVM behavior is correct, and it's what the original would have done if its collision code actually ran. It will take some kind of workaround to satisfy the broken script, but unfortunately it runs all the time and appears in several games, so this could be tough to fix.

[sluicebox <22204938+sluicebox@…>]

In 4fa1d891:

SCI: Fix QFG1 trip wire lockup

Fixes bug #15736

[sluicebox]

Fixed in: 4fa1d891d8d2a290d1e4469bc2b17364e3572891

It turns out that this bug does occur in some versions of the original, due to the effectively random outcomes of testing undefined memory to determine if collision checks occur. I was able to reproduce in version 1.001.

Fortunately there is also a normal script bug in the trip wire script. Fixing that fixes this scene in all versions in ScummVM, regardless of the Actor:canBeHere invalid-property bug.

[sluicebox <22204938+sluicebox@…>]

In 9bd9686c:

SCI: Fix QFG1 trip wire lockup

Fixes bug #15736