Opened 2 years ago

Closed 5 weeks ago

#13379 closed defect (fixed)

AGI: KQ3: Infinite animation when falling to death off ladder

Reported by: salty-horse Owned by: sluicebox
Priority: normal Component: Engine: AGI
Version: Keywords: original
Cc: Game: King's Quest 3

Description (last modified by sluicebox)

Observed in Twitch stream: https://clips.twitch.tv/EphemeralRacyCrowTBTacoLeft-roJnxqG_N00fx7tA

When climbing down falling off the ladder from the treehouse, when the room changes to the tree trunk, an infinite falling animation starts playing, while keeping the character in place.

I don't know the ScummVM version, but I can try to find out if needed.

Attachments (3)

vod-1432961001-offset-13782.mp4-00.00.22.235-00.00.28.402 2.mp4 (2.0 MB ) - added by m-kiewitz 2 years ago.
capture
kq3.025 (2.8 KB ) - added by sluicebox 5 weeks ago.
kq3.039 (3.1 KB ) - added by sluicebox 5 weeks ago.

Download all attachments as: .zip

Change History (11)

comment:1 by m-kiewitz, 2 years ago

attached video

comment:3 by eriktorbjorn, 2 years ago

Are you supposed to be able to reproduce this simply by climbing up the ladder and then walk back down again? I wasn't able to with my old savegame and the current development version of ScummVM.

comment:4 by salty-horse, 2 years ago

I think this is an edge case that requires more than just climbing up and down.
At the very least, you're supposed try to fall down to trigger it.

Can you share the savegame so I can try it myself?

Last edited 2 years ago by salty-horse (previous) (diff)

comment:5 by m-kiewitz, 2 years ago

Another question is if this occurs also in the original interpreter, or not.

comment:6 by tag2015, 9 months ago

Summary: KQ3: Infinite animation glitch when climbing down ladderAGI: KQ3: Infinite animation glitch when climbing down ladder

comment:7 by sluicebox, 5 weeks ago

Description: modified (diff)
Keywords: original added
Summary: AGI: KQ3: Infinite animation glitch when climbing down ladderAGI: KQ3: Infinite animation when falling to death off ladder

This is an original game bug. I can reproduce it in DOS and ScummVM with KQ3 2.14. It occurs in at least this room and the staircase room 64.

This bug does not occur when *climbing* the ladder, it occurs when *falling*. You're already dead when it happens, and you can still Restore. I'm updating the title and description.

The problem in both of these rooms is that there's a black priority line that overlaps with the fall path. When falling from the ladder, the black priority line is at the base of the tree that is behind ego. In cave room 64, there are several.

If ego falls at the right place then his movement doesn't advance, because AgiEngine::checkPriority returns false if ego is on a black priority line. This causes AgiEngine::updatePosition to reject the new position and roll it back. This happens forever.

I'm attaching a save game of the ladder falling in progress, and a save game in staircase room 64 where walking straight down will reproduce.

I don't think this is worth a workaround. Even if we had a script patcher, it doesn't seem to be a script bug, but an unfortunate placement of black priority lines that are unrelated to falling. I see no property that could be set to prevent the priority line from blocking the motion. (There may be a potential patch, I'm just saying that even if we could patch scripts, I'm not sure what we could do.)

Given that this is original behavior that occurs after you're already dead, and isn't easily fixable without cluttering up core motion code, I think it should be closed as wontfix.

by sluicebox, 5 weeks ago

Attachment: kq3.025 added

by sluicebox, 5 weeks ago

Attachment: kq3.039 added

comment:8 by sluicebox, 5 weeks ago

Owner: set to sluicebox
Resolution: fixed
Status: newclosed

Fixed in: https://github.com/scummvm/scummvm/commit/942303bbc6a002e0557f7939521d8f57d29ac76f

I changed my mind =)

It's a simple check at the end of checkPriority; it doesn't clutter the code too much. Seems like more work to explain why not to fix it than to just fix it so... it's fixed!

I'm not including this in 2.8.1 though, the deadline is soon and this isn't urgent so i don't want to risk a regression in a bugfix release over it.

Note: See TracTickets for help on using tickets.