#14568 closed defect (fixed)

SCI: Phantasmagoria - Dragon Bug

Reported by: DustyShinigami Owned by: sluicebox
Priority: normal Component: Engine: SCI
Version: Keywords: original
Cc: Game: Phantasmagoria 1

Description

Version: ScummVM -v2.7.1
Language of game: English
Version of game: CD, DOS
Your OS, including version and device if appropriate: Windows 10 Home, 64-bit, version 22H2, OS build: 19045.3271

I've been playing Phantasmagoria for the first time, and for the first time with ScummVM, and I've encountered a small bug in Chapter 5. After Adrienne switches on the projector that displays the dragon on the wall, if you click to go to the left of the room, and then click down to go back to the previous scene, she will be standing directly in front of the dragon. However, if you click on the dragon to interact with it, nothing happens. The red hand appears, but no cinematic plays. You have to click on the arrows to progress past the scene to carry on.

Attachments (1)

SAVES.zip (823 bytes ) - added by DustyShinigami 16 months ago.

Download all attachments as: .zip

Change History (8)

by DustyShinigami, 16 months ago

Attachment: SAVES.zip added

comment:1 by m-kiewitz, 16 months ago

Summary: Dragon BugSCI: Phantasmagoria - Dragon Bug

comment:2 by m-kiewitz, 16 months ago

It would be great if you could check if this bug also happens when using the original interpreter.
Getting that to work might be a nightmare though.

comment:3 by sluicebox, 16 months ago

Keywords: original added; Bug removed

Thank you for reporting this, and welcome back! =)

This is a script bug that would have occurred in the original. sPassageReveal:changeState(0) in room 16200 has a switch statement to set ego's heading based on her position, but it's missing a handler for the position in front of the dragon, so the script never advances to the next state.

I guess all the testers clicked the dragon right away instead of fleeing from the plot. ;)

in reply to:  3 comment:4 by DustyShinigami, 16 months ago

Replying to sluicebox:

Thank you for reporting this, and welcome back! =)

This is a script bug that would have occurred in the original. sPassageReveal:changeState(0) in room 16200 has a switch statement to set ego's heading based on her position, but it's missing a handler for the position in front of the dragon, so the script never advances to the next state.

I guess all the testers clicked the dragon right away instead of fleeing from the plot. ;)

Thanks. :) And yeah, I suspected that might be the case. I can't remember if I accidentally clicked away or wanted to check if something else in the area had changed. :p

I should note that I've found another potential bug that was probably in the original, too. I did ask about it on the forum, but no one has replied, so I'm guessing others aren't aware of it...? Should I open a ticket for that, too?

Last edited 16 months ago by DustyShinigami (previous) (diff)

comment:5 by sluicebox, 16 months ago

Thanks for mentioning the forum, I forget it exists. Most activity is on discord and this tracker and github. That's just my observation, but I don't even have a forum account and I'm not the only one so... set your expectations accordingly =)

I will take a look those chapter 7 details when I have time, but I audited it years ago, and it has holes like what you're describing. Some were fixed in some versions (which I backported through ScummVM patches) but others, as I remember, are just the way it works: "eh, they died here, just recreate the game in state X and let them run wild. no we didn't track exactly how they got here."

What I can promise you is that it's original game behavior.

As for this bug, I have a working script patch that I'll get committed soon. This is a good bug! Nice catch!

in reply to:  5 comment:6 by DustyShinigami, 16 months ago

Replying to sluicebox:

Thanks for mentioning the forum, I forget it exists. Most activity is on discord and this tracker and github. That's just my observation, but I don't even have a forum account and I'm not the only one so... set your expectations accordingly =)

I will take a look those chapter 7 details when I have time, but I audited it years ago, and it has holes like what you're describing. Some were fixed in some versions (which I backported through ScummVM patches) but others, as I remember, are just the way it works: "eh, they died here, just recreate the game in state X and let them run wild. no we didn't track exactly how they got here."

What I can promise you is that it's original game behavior.

As for this bug, I have a working script patch that I'll get committed soon. This is a good bug! Nice catch!

Awesome. Glad I could help in some way. :) Let me know if you want the Chapter 7 issue submitted as a bug once you've looked into it. I still have the save I think just before that whole chase sequence happens.

In the meantime, I should probably join the Discord. :D

comment:7 by sluicebox, 14 months ago

Owner: set to sluicebox
Resolution: fixed
Status: newclosed

Fixed in: https://github.com/scummvm/scummvm/commit/49da510f80384c476794a12ba212e4bd0b19d670

Thanks again for reporting!

Seems like promising a commit in a few days is a good way to guarantee getting sidetracked for a month and a half!

Note: See TracTickets for help on using tickets.