Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#6794 closed defect (fixed)

ZVISION: Yoruk's coffin instant death

Reported by: SF/ojolkir Owned by: bluegr
Priority: normal Component: Engine: ZVision
Version: Keywords:
Cc: Game: Zork Nemesis


ScummVM 1.8.0git2708-ga48a6ad (Jan 29 2015 23:23:22) win32-version on windows 7(64-bit)

Zork nemesis version: CD-version (activision essential collection)

I am in the cellar of the monastery, and I have a lit torch (cf. attached save game). If I walk towards the coffin I get a game over immediately.

Ticket imported from: bugs/6794.

Attachments (2)

znemesis.003 (7.6 KB ) - added by SF/ojolkir 9 years ago.
NEMSAV7.SAV (117.2 KB ) - added by eriktorbjorn 9 years ago.

Download all attachments as: .zip

Change History (11)

by SF/ojolkir, 9 years ago

Attachment: znemesis.003 added

comment:1 by eriktorbjorn, 9 years ago

It's probably been more than ten years since I played through the game, so I don't remember this part at all. My understanding of how the scripts work is also pretty limited, but I think this is the part of mq80.scr that's handles killing the player:

~~~~ puzzle:14823 { # mq 80 death end pzl criteria { [14822] = 2 # INITIAL MQ80 (no light)_bg_task } results { action:assign(159, 9) action:dissolve event:change_location(G,J,DE,0) } flags { ONCE_PER_INST } } ~~~~

The location G,J,DE,0 is the game-over screen, and as far as I can tell the state value 14822 keeps track of the status of the sound of you being eaten. I think 0 means the sound isn't played at all, 1 that it's currently playing, and 2 that it has finished playing.

Oddly enough, it's 2 in the savegame you provided. But the only script I can find that's supposed to set it is also in mq80.scr, presumably when you enter the room with the coffin:

~~~~ puzzle:14108 { # INITIAL MQ80 (no light) criteria { [12762] ! 5 # g mp torch state [12762] ! 3 # g mp torch state } results { action:assign(14104, 1) # INITIAL MQ80 (final torch,coffin closed) action:assign(14105, 1) # INITIAL MQ80 (final torch,coffin opened) action:assign(14106, 1) # INITIAL MQ80 (held lit torch, coffin closed) action:assign(14107, 1) # INITIAL MQ80 (held lit torch, coffin opened) action:assign(16014, 0) # g mq gru on action:set_screen(mq80s51c.tga) action:disable_control(14119) # mq 80-8e action:disable_control(14109) # mq 80 put torch ctl background:music:14822(0 mq00h3sc.raw 0) } flags { ONCE_PER_INST DO_ME_NOW } } ~~~~

State 12762 keeps track of the torch's state. It seems that 3 means the torch is lit and carried, and 5 that it's lit and put in the holder near the coffin. So if it's not lit, it will start to play the sound of you being eaten (mq00h3sc.raw), setting statevalue 14822 to 1, and then to 2 when it has finished.

I can't understand how state value 14822 is 2 in your savegame, unless you've already been to the coffin. But then you would have been killed, so that doesn't work either. I don't get it, but I'll leave these notes here anyway in the hope that the next one to look at it will find them useful.

comment:2 by digitall, 9 years ago

Summary: Yoruk's coffin instant deathZVISION: Yoruk's coffin instant death

comment:3 by bluegr, 9 years ago

That saved game is buggy indeed. I have the exact save game (before lighting the torch), and it works correctly.

I can fix this save game by typing: statevalue 14822 0 in the debugger

I don't understand how this value got set to 2...

comment:4 by eriktorbjorn, 9 years ago

I'll have to play around with it more when I get to that point in the game. I don't know how long it would take me, though. I haven't played the game for ages, and I don't want to just walkthrough may way through it. (Even if it's the kind of game where I often have to look at hints to progress.)

I wonder if it would be sensible for the ActionMusic constructor to initialize the state value to 0, or if that would break other things.

comment:5 by SF/tnm23, 9 years ago

I have found an effect that may shed some light on this, if you'll pardon the pun:

If you go into the dark area without a lit torch, it is currently possible to run away from the grue and survive if you spin around quickly and walk back out again (it's pitch dark, but the cursor will turn into a "walk forward" arrow on the right spot behind you), even though the "getting eaten" sound effect begins to play instantly. However, after doing this, walking back into the grue area again will result in an instantaneous transition to the game over screen without sound or pause, regardless of whether you have the lit torch or not. I'd guess that running away after the sound begins to play is what is setting state 2. To the original submitter of the bug: can you remember if you did this before saving the game?

I'm pretty sure (not entirely; it's been ages) that it was possible to run away from the grue in the original game, although I think there might have been a short delay between walking into the grue area and the "eaten" sound effect starting to play when one could do this. I think maybe there's supposed to be a short pause to give you a chance to realise you're in danger and escape, then once the sound starts playing it should be too late and you can't leave? Alternatively, of course, this could just be a script bug that was always there.

comment:6 by eriktorbjorn, 9 years ago

Ah, I can indeed reproduce the problem that way: I cleared the state variabe so that I could survive without a lit torch, ran away before the sound had finished, then tried to go back with a lit torch and died immediately.

The workaround I suggested (clearing the state value when the ActionMusic object is created) does seem to fix this problem, though I still don't know if it's the Right Thing to do.

by eriktorbjorn, 9 years ago

Attachment: NEMSAV7.SAV added

comment:7 by eriktorbjorn, 9 years ago

I was able to reproduce the bug when running the original in DOSBox as well. The only difference from the behavior in ScummVM was that in DOSBox, I saw the room with the coffin for a moment, before dying.

I think I've attached the correct savegame, and it was made before attempting to run from the darkness.

So I guess this means we're free to implement any workaround we can think of. I rather like the idea of being able to cheat death by running away, so I suggest we keep that behavior. Actually, the workaround I've already suggested before still seems pretty reasonable to me, but perhaps restrict it to cover only this one particular case?

comment:8 by bluegr, 9 years ago

Owner: set to bluegr
Resolution: fixed
Status: newclosed

comment:9 by bluegr, 9 years ago

Fixed in commit 60c06b84b, using eriktorbjorn's workaround suggestion. Thanks! :)

The fix will be available in the next daily version of ScummVM. Closing as fixed

Note: See TracTickets for help on using tickets.