#6232 closed defect (fixed)
SCI: Pepper's Adventures in Time: Game becomes unsolvable
Reported by: | SF/nkomp18 | Owned by: | bluegr |
---|---|---|---|
Priority: | normal | Component: | Engine: SCI |
Version: | Keywords: | original | |
Cc: | Game: | Pepper's Adventures in Time |
Description
There is a bug that also occurred in the original and still persists in Scummvm 1.5.
At one point you get a jar of cabbage that you are supposed to feed to the goat in order to empty the jar. When you give the jar to the goat a message pops up "The goat would sure want to eat that, but Pepper decides to hold on to it" or something very similar to that. What should happen instead is that an animation sequence initiates with the goat bulging it's eyes and eating the cabbage.
Without being able to empty the jar, the game is unplayable. I'm attaching the saved game at that point where I am stuck.
Ticket imported from: #3601090. Ticket imported from: bugs/6232.
Attachments (1)
Change History (10)
by , 12 years ago
Attachment: | pepper[1].000 added |
---|
comment:1 by , 12 years ago
Summary: | Game becomes unsolvable → SCI: Pepper's Adventures in Time: Game becomes unsolvable |
---|
comment:2 by , 12 years ago
This is a very weird bug.
The room in question is 260, and this action is handled by the same script (260), in goat::doVerb. That function does the goat's animation when the second parameter to it (i.e. the param with an index of 1) is 0x34 (52 dec). However, in our implementation, the parameter equals 0x7d (125 dec). If I'm not mistaken, this parameter originates from a call to uEvt::new, which calls kGetEvent and then opcode SelfID, though I could be mistaken.
I placed a breakpoint in goat::doVerb, gave the jar to the goat and when the breakpoint was triggered, I set param 1 equal to 0x34 (52), i.e. the expected value, and this action worked correctly. So, this seems to be an issue with our SCI VM, i.e. the game script interpreter...
comment:3 by , 12 years ago
You say it also occurs in the original, and that the game can't be finished this way, so that would imply the original game can't be finished? That seems unlikely, though. Is there a specific thing you do to get in this stuck state?
comment:4 by , 12 years ago
I've figured out how to reproduce this in three steps. Note that the purpose of this object is to make a Leyden jar (but Pepper doesn't actually know that yet):
1. Get the jar of cabbage from the baker 2. Use an object that is NOT normally involved in the Leyden jar maklng (say, the magnet) on the jar (you can look at the object to confirm that the game now thinks it's a partially completed Leyden jar) 3. Use an object that IS involved in the Leyden jar making (say, the tin foil) on the jar.
Action 2 changes the noun and message selectors of the Glass Jar object . Action 3 partially reverts this, leading to an inconsistent game state. The code in question is located in Glass Jar::doVerb (you will need to patch ScummVM slightly to be able to set a breakpoint there because of the space character), and the offending instructions look like debug code.
comment:5 by , 12 years ago
The reproduction steps are in line with that I had tried during the game. I had tried to combine the magnet with the jar before trying the foil and got into the inconsistent state.
The reason why I believe it was in the original, is that after googling the problem I found a couple of blog posts of people who played the game back in the day and never finished it because "the damn goat wouldn't eat the cabbage", in their words.
In any case, if it's reproducible, should be very easy to fix.
comment:6 by , 12 years ago
Note that underscores can now be used instead of spaces in object names (commits 5d90c6f and cc1bb39).
comment:7 by , 12 years ago
lskovlun: we should create a script patch, then. Which ones are the offending instructions? Perhaps we could substitute them with NOPs (e.g. unused ldi calls)
comment:8 by , 12 years ago
Thanks for your report, the issue has been fixed in commit 0968acc, and should be available in the next daily build.
Many thanks to lskovlun for debugging this problem and finding the offending script code that caused it.
In your saved game, the jar is already corrupted. To fix it, open the ScummVM debugger (Control-Shift-D) and type: "send Glass_Jar message 52" without the quotes
comment:9 by , 12 years ago
Owner: | set to |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Unsolvable saved game