Opened 2 years ago

Closed 2 years ago

#13385 closed defect (fixed)

SCUMM: Loom Talkie: can't go back to the cave to get the reflection draft

Reported by: dwatteau Owned by: eriktorbjorn
Priority: normal Component: Engine: SCUMM
Version: Keywords: loom, talkie, hot spot, dead-end
Cc: Game: Loom

Description

This is with Loom Talkie, Steam/Windows/English version, on a ScummVM 2.6.0git build.

While doing his French translation of this version, Threepwang found the following behavior, which many players would call a dead-end:

  1. Go to the dragon's cave
  2. Don't learn the reflection draft (which is hidden under water)
  3. Find the cave exit
  4. Untwist the stairs and go see Rusty; once you've woken him up, you need to use your reflection draft on him… but you have never learnt it
  5. So you try to go back to the cave in order to learn it
  6. But in this version of Loom you can't: nothing happens when you try entering it again. Even if you try hunting every pixel of the cave entry. So you can't learn the reflection draft (unless you cheat with the debugger) and you're stuck, AFAICS.

The attached savegame puts you at step 3 (use the draft debugger command if you need to see the drafts). Teleporting to room 33 is also another way to test this.

When using the objects command in the ScummVM debugger, the cave object (468) does exist. But yet it seems that you can't interact with it.

The very old ticket #2088 hints at very narrow hot spots for this object, but in the EGA and the PC Engine versions here (and probably the other ones), it's really easy to go back to the cave. In the Talkie version, I really can't find any pixel that will let me go back to the cave (and I've been hunting pixels in point'n'click games for more than 20 years :p).

So, maybe the hot spot of the cave could be loosened a bit in this version, so that going back to the cave remains as easy as in the other versions?

Attachments (3)

loom-steam-win.s03 (13.4 KB ) - added by dwatteau 2 years ago.
Load this, exit the cave, and try going back to it
loom-talkie-going-back-cave-hard-pixel-hunting.mp4 (507.1 KB ) - added by dwatteau 2 years ago.
Going back to the cave requires clicking on a very very small hotspot in this version
Cave - no_name - no_miniature_drawing .png (175.2 KB ) - added by Thpwg 2 years ago.

Download all attachments as: .zip

Change History (10)

by dwatteau, 2 years ago

Attachment: loom-steam-win.s03 added

Load this, exit the cave, and try going back to it

by dwatteau, 2 years ago

Going back to the cave requires clicking on a very very small hotspot in this version

comment:1 by dwatteau, 2 years ago

So yeah, if you compare the cave hotspot (room 33) in most Loom versions, it looks like the Talkie version made it much narrower for no good reason (I don't even think that it's intentional).

Since Loom is known to be the first LucasArts game with no dead-ends and no vicious puzzle, and since ScummVM is now quite open about this kind of improvements, I think that it would be fair for players to have the same "nice" hotspot for the cave in the Talkie version, too.

comment:2 by Thpwg, 2 years ago

Here is a screenshot of Loom Talkie translated into French. The most disturbing thing is that the miniature drawing of the cave/caverne and the name are not visible. If I click on the staircase/steps/marches, there is a good indication of the name and I can clearly see the thumbnail. But for the cave, it's really difficult. On the one hand the area to enter is tiny and on the other hand, there is NOTHING to tell us that it is possible!

comment:3 by eriktorbjorn, 2 years ago

The problem seems to be that VGA Loom registers the click on the wrong object. Here are the objects in the EGA version, according to the ScummVM debugger:

+-----------------------------------------------------------+
|num |    name    |  x |  y |width|height|state|fl|   cls   |
+----+------------+----+----+-----+------+-----+--+---------+
| 542|cave        |   0|   8|   40|    40|    0| 0|$00000002|
| 543|            | 288|   0|   32|   144|    0| 0|$00800002|
| 544|steps       | 120|  16|   32|    48|    0| 0|$00000001|
| 545|            | 144|  56|   32|    80|    0| 0|$00800000|
| 546|            | 176|  64|   32|    72|    0| 0|$00800000|
| 547|            |  88|  56|   88|    80|    1| 0|$00800000|
| 548|            | 176|  64|   32|    72|    1| 0|$00800000|
| 549|            | 208|  64|   24|    72|    1| 0|$00800000|
| 550|            | 232|  88|   72|    48|    1| 0|$00800000|
| 551|            |  88|  56|   56|    80|    0| 0|$00800000|
| 552|            | 144|  56|   32|    40|    0| 0|$00800000|
| 553|            | 176|  64|   56|    72|    0| 0|$00800000|
| 554|            | 232|  88|   72|    48|    0| 0|$00800000|
| 555|            |   0|   0|   48|    40|    0| 0|$00000000|
| 556|            |   0|   0|   48|    40|    0| 0|$00000000|

Clicking on the cave registers as a click on object 542, causing you to walk towards it. Once you reach it, apparently the object's script (roomobj-33-542) takes over:

Events:
  38 - 001A
[001A] (24) loadRoomWithEgo(506,30,406,34);
[0022] (00) stopObjectCode();
END

In the VGA version, the objects are in a different order:

+-----------------------------------------------------------+
|num |    name    |  x |  y |width|height|state|fl|   cls   |
+----+------------+----+----+-----+------+-----+--+---------+
| 477|            |  88|  56|   56|    80|    0| 0|$00800000|
| 478|            | 144|  56|   32|    80|    0| 0|$00800000|
| 479|            | 176|  64|   56|    72|    0| 0|$00800000|
| 480|            | 232|  88|   72|    48|    0| 0|$00800000|
| 473|            |  88|  56|   88|    80|    1| 0|$00800000|
| 474|            | 176|  64|   32|    72|    1| 0|$00800000|
| 475|            | 208|  64|   24|    72|    1| 0|$00800000|
| 476|            | 232|  88|   72|    48|    1| 0|$00800000|
| 482|            |   0|   0|   48|    40|    0| 0|$00000000|
| 468|cave        |   0|   8|   40|    40|    0| 0|$00000002|
| 469|            | 288|   0|   32|   144|    0| 0|$00800002|
| 470|steps       | 120|  16|   32|    48|    0| 0|$00000001|
| 481|            |   0|   0|   48|    40|    0| 0|$00000000|
| 471|            | 144|  56|   32|    80|    0| 0|$00800000|
| 472|            | 176|  64|   32|    72|    0| 0|$00800000|

Clicking on most of the cave, except for a sliver at the bottom (actually below the cave entrance) registers as a click on object 482. This object has an empty object script, so you are not moved back into the caves.

I have no idea what these objects overlapping the cave entrance are used for. Here's a possible workaround, if it turns out to be a script bug rather than a ScummVM bug:

diff --git a/engines/scumm/script_v5.cpp b/engines/scumm/script_v5.cpp
index 74121f4d039..12f9e71f0c1 100644
--- a/engines/scumm/script_v5.cpp
+++ b/engines/scumm/script_v5.cpp
@@ -2385,6 +2385,14 @@ void ScummEngine_v5::o5_startObject() {
        obj = getVarOrDirectWord(PARAM_1);
        script = getVarOrDirectByte(PARAM_2);
 
+       // WORKAROUND bug #13385: Clicking on the cave entrance to go back into
+       // the dragon caves registers on the incorrect object. Redirect to the
+       // cave's object script, which handles the actual moving to the other
+       // room.
+       if (_game.id == GID_LOOM && _game.version == 4 && _currentRoom == 33 && obj == 482 && script == 56) {
+               obj = 468;
+       }
+
        getWordVararg(data);
        runObjectScript(obj, script, 0, 0, data);
 }

(If it's a script bug, I guess it should be marked as a workaround. Or maybe not. It's not a behavior I can see anyone actually wanting to disable...)

comment:4 by eriktorbjorn, 2 years ago

I was able to use debug mode in the original interpreter to teleport to the room. It appears to happen in the original as well, so I guess a workaround is good enough.

I've submitted a pull request: https://github.com/scummvm/scummvm/pull/3783

Last edited 2 years ago by eriktorbjorn (previous) (diff)

comment:5 by dwatteau, 2 years ago

@eriktorbjorn: This PR works extremely well here, thank you very much!

(As for the missing cave text that Thpwg mentions above: that's "normal" behavior though; in Loom, any door/opening is textless when it is/becomes accessible: same thing happens in the tents or in the Glass City).

So, with your PR, everything now looks good, to me! Thanks again.

comment:6 by eriktorbjorn, 2 years ago

I updated the pull request to be more like the recent workaround for Bobbin escaping through the locked cell door. Should still behave the same, though.

comment:7 by bluegr, 2 years ago

Owner: set to eriktorbjorn
Resolution: fixed
Status: newclosed

The PR has been merged. Thanks for your work!

Note: See TracTickets for help on using tickets.