Opened 18 years ago

Closed 18 years ago

Last modified 18 years ago

#454 closed defect (outdated)

LOOM: silly walks

Reported by: eriktorbjorn Owned by: SF/ender
Priority: normal Component: Engine: SCUMM
Keywords: Cc:
Game: Loom

Description

ese buglets happens in recent CVS snapshots, but I think it's been like this for quite some time now. I have a nagging feeling that they are related, which is why I report them as one bug instead of three.

1. When Bobbin wakes up in the cell in the Forge, he starts walking on the spot, without getting anywhere.

2. Then, after he has twisted or unsharpened the final sword, two guards start walking toward him. They should end up on either side of him, except the one on the right keeps walking an imaginary downward slope, so he ends up somewhere near the lower left corner of the picture area.

I added some debug printf()s to startWalkActor(), classChanged() and o5_setClass(), and this is what I found:

0x8189a10: o5_setClass cleared ignoreBoxes and forceClip 0x8189a10: classChanged(22, 1) 0x8189a10: classChanged(21, 1) 0x8189a10: startWalkActor(304, 47, -1)

(So far it works. The right guard's ignoreBoxes is true, so he walks towards the destination in a straight, diagonal line.)

0x8189b90: o5_setClass cleared ignoreBoxes and forceClip 0x8189b90: classChanged(22, 1) 0x8189b90: classChanged(21, 1) 0x8189b90: startWalkActor(161, 47, -1)

(The left guard's ignoreBoxes is also true, so he will walk in a straight horizontal line towards his destination.)

0x8189a10: o5_setClass cleared ignoreBoxes and forceClip 0x8189a10: classChanged(21, 1) 0x8189a10: startWalkActor(193, 47, -1)

(The right guard can't walk to the intended destination because his ignoreBoxes is false, and the destination is outside all boxes.)

So I can easily fix this second problem, but all such fixes of mine have either been specialized hacks, or they have (probably) broken other stuff as well.

3. During the confrontation with Chaos at the end of the game, by the time Bobbin says "Over my dead body!" Chaos will have moved to the center of the screen. Then, after she replies "Preference noted.", she suddenly pops back to the left side of the screen again.

I'm attaching some save games. The twisting draft is "c f c c", and the opening draft is (as always) "e c e d".

Ticket imported from: #605970. Ticket imported from: bugs/454.

Attachments (4)

loomcd.s10 (42.1 KB ) - added by eriktorbjorn 18 years ago.
Bobbin in the cell, before falling asleep
loomcd.s14 (42.1 KB ) - added by eriktorbjorn 18 years ago.
Bobbin at the Great Loom, before Chaos arrives
loomcd.s25 (42.2 KB ) - added by eriktorbjorn 18 years ago.
More convenient save game for the second phenomenon
guardhack.diff (497 bytes ) - added by eriktorbjorn 18 years ago.
Experimental patch against a September 13 CVS snapshot

Download all attachments as: .zip

Change History (11)

by eriktorbjorn, 18 years ago

Attachment: loomcd.s10 added

Bobbin in the cell, before falling asleep

by eriktorbjorn, 18 years ago

Attachment: loomcd.s14 added

Bobbin at the Great Loom, before Chaos arrives

by eriktorbjorn, 18 years ago

Attachment: loomcd.s25 added

More convenient save game for the second phenomenon

by eriktorbjorn, 18 years ago

Attachment: guardhack.diff added

Experimental patch against a September 13 CVS snapshot

comment:1 by eriktorbjorn, 18 years ago

New theory about the second problem, i.e. the one with the walking guards:

As I said above, the right guard is first moved with ignoreBoxes set to 1. This causes his walkbox is set to 0. Then, when he's moved with ignoreBoxes = 0, the code will try to find a path for him from box 0 to his destination, which will fail even though he actually is in the correct box already.

If I ensure that adjustActorPos() is called first, it will work. I'm attaching a patch, but I'd appreciate if someone who, unlike me, actually understands the walking code could take a look at it and tell me if I'm completely off-base.

comment:2 by fingolfin, 18 years ago

We discussed this a bit on IRC, and I thought that probably walbox should not be set to 0 in the first place, at least not for GF_SMALL_HEADER games (walkbox 0 is a special walkbox in a newer games, but not in GF_SMALL_HEADER games). Well that didn't
help. And setting it to -1 just leads to to a crash.

I am not entierly happy with it, but I'll commit this patch anyway, with a FIXME comment.

comment:3 by SF/ender, 18 years ago

Um, so with the latest patch and various hacks, which of these glitches still exist?

comment:4 by SF/ender, 18 years ago

Owner: set to SF/ender

comment:5 by eriktorbjorn, 18 years ago

None, I think. The latest patch fixes 1 and 3. (At the very least, 3 is no longer obviously broken.) 2 was fixed, or hacked around, long ago; see FIXME in startWalkActor().

Actually I haven't checked if the adjustActorPos() call to fix 2 is still needed, but if memory serves me it also fixed a glitch when encountering Rusty's ghost. I tend to trust one-liners that fix more than one problem. :-)

comment:6 by SF/ender, 18 years ago

ok, closing then.

comment:7 by SF/ender, 18 years ago

Resolution: outdated
Status: newclosed
Note: See TracTickets for help on using tickets.