Opened 22 years ago
Closed 21 years ago
#467 closed defect
ZAK256: torches are initially lit
| Reported by: | SF/martingu | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | script | |
| Cc: | Game: | Zak McKracken |
Description
some areas in the game (cairo pyramid, mexican temple, ...) are lit from the beginning on allthough the player has to lit them by using the lighter with the torches. on mars there is a room which doesn't at all the possibility to make light but it's lit (so the flashlight is useless)
Ticket imported from: #609961. Ticket imported from: bugs/467.
Attachments (1)
Change History (15)
comment:1 by , 22 years ago
comment:2 by , 22 years ago
ScummVM version: Sep16 Win32 Snapshot Language of game: English Version of game: FM-Towns Platform and Compiler: Win 32 pre-compiled Daily Snapshot
comment:3 by , 22 years ago
What do you mean with "on mars there is a room which doesn't at all the possibility to make light" ? This sentence no verb :-)
Also, can you please attach a savegame (or multiple for each case if possible) that allows to reproduce this?
comment:4 by , 22 years ago
- Language of game: English - Version of game: FMTowns - Platform and Compiler (Win32, Linux, etc)
I've gathered more information about the bug using the latest snapshot (Sep23 Win32, savegame included)
It mustn't at all be possible to make light in room 32 (entrance of huge face on mars). Nonetheless the room is lit from the beginning on. Check savegame. It shows Melissa standing in this room which is lit but mustn't be.
comment:5 by , 22 years ago
To clarify:
The Maze on Mars is supposed to stay dark--it has no torches. The only way through, technically, is to take the Flashlight from the Hostel and poke your way through. It's currently lit, which is never supposed to happen.
comment:6 by , 22 years ago
To clarify:
The Maze on Mars is supposed to stay dark--it has no torches. The only way through, technically, is to take the Flashlight from the Hostel and poke your way through. It's currently lit, which is never supposed to happen.
comment:7 by , 21 years ago
I think we might be hitting an unimplemented / wrongly implemented opcode here... notice that when you load that save game and leave to any room, you will trigger the warning/FIXME in o5_pickupObjectOld (negative object index). Together with the fact that the descumm3 of script 34 (the one calling the offenseive pickupObject) contains Illegal opcodes, and the incorrect light behaviour, that is a strong hint that something deeper is wrong here. Hence my suggestion.
comment:8 by , 21 years ago
| Owner: | set to |
|---|
comment:9 by , 21 years ago
The invalid opcodes simply where there because descumm3 was incomplete, that is fixed. Still, look at this disassmbly from script 34:
[004B] (48) if (Var[303 + 0] == 50) { [0054] (0C) loadRoom(Var[302]) [0058] (32) setCameraAt(39986) [005B] (2E) Delay(4724737); [005F] (00) stopObjectScript() [0060] (**) } [0060] (48) if (Var[303 + 0] == 80) { [0069] (0C) loadRoom(Var[302]) [006D] (50) pickupObject(40016) [0070] (2E) Delay(3348481); [0074] (00) stopObjectScript() [0075] (**) }
These Delay seem to be as bogus as the pickupObject parameter (note that 3348481 is actually passed to o5_delay(), so it's not just descumm3 being bogus again). If we eat some bytes to much or to little at some place, that'd explain what we are seeing here.
comment:10 by , 21 years ago
We fixed the invalid opcode problem now (but there are still 5 new new opcodes that are not yet implemented). Lights are still on, though.
comment:11 by , 21 years ago
The weird part: the entry script for room 32 explicitly calls lights(11,0,0) - which turns on all lights as normal (11 is the default light mode). It's the very first command in the script, thus we can be pretty sure that it is not interpreted incorrectly due to bugy commands before it.
I also checked all other scripts that are run when you enter/leave/walk the room; the only place where a light call is made that could turn off light, it is done in script-1612 and only if Var[9] (the light var) is not 11 - so that code can never be reached (I am pretty sure this code is used to control the flashlight, anyway).
So right now, as far as I can tell, the only possibility left is that one of the so far unknown sub opcodes of o5_resourceRoutines() might affect light in some way (it's subopcode 0x23 + 1 is called in the entry script for 32, after all). But that seems a bit weird - why not simply use the lights call?!? Hrmpf.
comment:12 by , 21 years ago
I just spent a couple of hours playing the FMTowns-version of Zak McKracken (I even completed the whole game in one session). I used the Unz-emulator, data files I got from a CD- image, which I think is made from the original FMTowns Zak CD and audiotracks I burned on CD from MP3-files. This, I think, is the closest I can get to the original experience, without getting an actual FMTowns console and an original copy of the game, so I figured whatever happens while I play, also happens in the real deal.
* Martian pyramid: lit
* Martian maze (in the Huge face): lit
* Egyptian pyramid: corridor is lit, but not the sargophagus room
*Mayan (Mexican) Maze: partially lit, but there are dark rooms in which you have to light torches
comment:13 by , 21 years ago
well, what qtio explains matches with what I found when debugging the scripts. Phew, I already thought I am nuts or we are doing something completly wrong. Seems not.
THe attached save game is only for mars. So, does ScummVM render the egyptioan sarcophagus room as dark, and the dark rooms in the maya/martian mazes? If not, somebody please attach save games for me for those rooms (or preferably, save games where one can get into the rooms which should be dark with one click; this way, the entry script is guranteed to be triggered.
Thanks!
comment:14 by , 21 years ago
| Status: | new → closed |
|---|
To process your bug report appropriately, we need to provide the following information: <ul> <li>ScummVM version (scummvm -v)</li> <li>Bug details, including instructions on reproducing it</li> <li>Language of game (English, German, etc)</li> <li>Version of game (Talkie, Floppy...)</li> <li>Platform and Compiler (Win32, Linux, MacOS, etc)</li> <li>Attach a save game if possible</li> <li>If this bug only occurred recently, please note the last version without the bug, and the first version including the bug. That way we can fix it quicker by looking at the changes made.</li> </ul>
This should only take you a little time but will make it much easier for us to process your bug report in a way that satisfies both you and us.
Thank you for your support!