#2198 closed defect (fixed)
ZAK256: Non completable in post 0.7.1 versions
| Reported by: | SF/vood | Owned by: | SF/ender |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | script | |
| Cc: | Game: | Zak McKracken |
Description
In some point between 0.7.1 and lastest CVS Zak256 stopped being completable. When you are in the secret room at mar´s pyramid if you use the glowing object in the base the game crashes.
If you don´t have a proper savegame you cant test the bug easily using the console with:
room 41 object 78 pickup room 25
Then just use the glowing object at the base and prepare for crash.
Regards.
Ticket imported from: #1290485. Ticket imported from: bugs/2198.
Attachments (2)
Change History (20)
comment:1 by , 19 years ago
comment:3 by , 19 years ago
| Owner: | set to |
|---|
comment:4 by , 19 years ago
I changed the default case warning in o5_resourceRoutines() to an error in CVS, since it shouldn't be triggered.
According to the disasm. of the FM-TOWNS version, case 0 of o5_resourceRoutines() isn't valid either. The original game would just ignore it though, not error out.
Endy, could you check the script been used at this point? to see if it is script error or a bad decode of the script's opcodes.
comment:6 by , 19 years ago
It would help if you could provide a dump of the scripts used at that location and a debug level 9 log as the error occurs:
1. Create a 'dumps' directory, in the directory where ScummVM is located. 2. Start ScummVM from the command line, with the dump scripts option: ie scummvm -u zaktowns 3. Start game or load saved game, go to room near that location, since room scripts are only dumped when you enter a room. 4. Cause the error to occur again. 5. Compress and attached the *.dmp files in the 'dumps' directory.
1. Start ScummVM with a debug level of 9 and redirect output to file: ie scummvm -d9 zaktowns > debuglog.txt 2. Cause the error to occur again. 3. Compress and attached the log file.
comment:7 by , 19 years ago
Ok, Zak Mckracken is a very long game, so in order to test this bug with the lastest CVS I had to use the shortcut that triggers the error (which I got in first place by normal methods...playing from beggining). So to sum up:
1.- I loaded Zak256 , then I went to room 41 to get the glowing object, and finally to room 25 wheres supposed to be used. 2.- Then I pulled a lever in that room to open the stairs so zak could go to the next room. 3.- Finally I did a savegame in that room
Then , I loaded scummvm CVS with -u and then loaded my previous savegame. Zak entered the "buggy" room, used the glowing object on the base and...crash :
ERROR: (25:171:0x9): o5_resourceRoutines: default case 0
So heres the dumps
Regards
comment:10 by , 19 years ago
The problem is that ScummVM is loading a whole room for script 171, instead of the actual script and tries to use the room as a script. So the current error is only a side effect.
I'm not sure what is causing the resource loading problem though. The problem might have just been hidden in the past.
comment:11 by , 19 years ago
| Priority: | normal → high |
|---|
comment:13 by , 19 years ago
The current solution is to add back the original workaround
(simply changing the default case error in o5_resourceRoutines
back to a warning), or perhaps something more specific to this
particular bug.
The game can be completed with such a workaround (note:
Played to the end from an 0.7.1 save just prior to having to
insert the object into the base).
There is obviously a real bug here, which I will look into a bit
more... but this workaround has been committed for now, to
enable further testing of the game.
Not changing priority until I've looked into a proper fix.
comment:14 by , 19 years ago
I added a work around of not starting script 171 instead, since it is safer. Allowing a room resource to be executed as a script is just a bad idea...
comment:15 by , 19 years ago
Yes, it was a quick and dirty hack until I get a chance to look into it some more after work :)
comment:16 by , 19 years ago
loadResource(rtScript, 171) scummvm: scumm/resource.cpp:667: int Scumm::ScummEngine::loadResource(int, int): Assertion `roomNr > 0' failed.
That certainly doesn't help.
comment:17 by , 19 years ago
Ok, the essential problem here is that script 171 doesn't exist.
In fact, there are no scripts past 169, although the script index
in 00.LFL lists more.
These rooms have been stubbed out by setting both the room
number and offset to 0. Currently if the room number is
0 in loadResource(), we set it to the current room. So once we
try and load it, we're loading everything from offset 0 in the
current room.
The question is whats the proper solution... several other games (Monkey1, etc) also appear to have [0,0] scripts. I have not found any other instance where a stubbed script is actually called.
The current workaround of aborting runScript works for this particular bug, so I'm marking it as fixed and closing it.
It may however be a good idea to make a more generic fix by
enhancing error checking with regards to this type of case.
Abort executing the script somewhere if the roomOffs is 0,
which as far as I know is not valid in ANY scumm game.
comment:18 by , 19 years ago
| Component: | → Engine: SCUMM |
|---|---|
| Game: | → Zak McKracken |
| Keywords: | script added |
| Priority: | high → normal |
| Resolution: | → fixed |
| Status: | new → closed |
Which error message do you get in console?