Opened 17 years ago

Closed 17 years ago

Last modified 17 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 17 years ago.
Bobbin in the cell, before falling asleep
loomcd.s14 (42.1 KB ) - added by eriktorbjorn 17 years ago.
Bobbin at the Great Loom, before Chaos arrives
loomcd.s25 (42.2 KB ) - added by eriktorbjorn 17 years ago.
More convenient save game for the second phenomenon
guardhack.diff (497 bytes ) - added by eriktorbjorn 17 years ago.
Experimental patch against a September 13 CVS snapshot

Download all attachments as: .zip

Change History (11)

by eriktorbjorn, 17 years ago

Attachment: loomcd.s10 added

Bobbin in the cell, before falling asleep

by eriktorbjorn, 17 years ago

Attachment: loomcd.s14 added

Bobbin at the Great Loom, before Chaos arrives

by eriktorbjorn, 17 years ago

Attachment: loomcd.s25 added

More convenient save game for the second phenomenon

by eriktorbjorn, 17 years ago

Attachment: guardhack.diff added

Experimental patch against a September 13 CVS snapshot

comment:1 by eriktorbjorn, 17 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, 17 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, 17 years ago

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

comment:4 by SF/ender, 17 years ago

Owner: set to SF/ender

comment:5 by eriktorbjorn, 17 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, 17 years ago

ok, closing then.

comment:7 by SF/ender, 17 years ago

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