#6034 closed defect (fixed)
SCUMM: ZAK Can't get objects in the bus on Mars
Reported by: | SF/henry170 | Owned by: | bluegr |
---|---|---|---|
Priority: | normal | Component: | Engine: SCUMM |
Version: | Keywords: | ||
Cc: | Game: | Zak McKracken |
Description
Within the bus I can't get any object (like the recorder, the tape etc.). When I choose an object "I can not reach it" is sayed.
This problem happens with the DOS-version and the C64-version. Both are the german versions.
With the FM-TOWNS-version (german) this problem doesen't happening.
Ticket imported from: #3526089. Ticket imported from: bugs/6034.
Attachments (2)
Change History (21)
comment:1 by , 13 years ago
Summary: | Problem with the objects in the bus on mars → Zak McKracken - Problem with the objects in the bus on mars |
---|
comment:2 by , 13 years ago
Summary: | Zak McKracken - Problem with the objects in the bus on mars → SCUMM: ZAK Can't get objects in the bus on Mars |
---|
comment:3 by , 13 years ago
comment:4 by , 13 years ago
6. Please can you also attach a text file to this bug containing a file listing of your ZAK datafiles with MD5sums so we can check that this is not due to corruption in your datafiles from a bad media copy. The output of a tool such as http://md5summer.org/ would be optimal.
comment:5 by , 13 years ago
I use the latest version of Scummvm and the newest dayly snapshot, but the problem in the bus is still there. The system is Windows XP.
I don't find the file of the savegame that I made on my harddrive.
comment:6 by , 13 years ago
I've found the file with the savegame. It's a hidden file. That was the reason why I didn't found it. ;) Hopefully it is usefull to fix the problem.
comment:8 by , 13 years ago
henry170: Thank you for the savegame to aid replication. Unfortunately, I only have the English version of Zak, so not sure if I can investigate this, but there should now be enough information for our German developers to take a look. Please standby...
by , 13 years ago
Attachment: | zak-v2.s01 added |
---|
comment:9 by , 13 years ago
I've installed Scummvm (scummvm-1.4.1-win32.exe) anew and did not update the latest dayly snapshot. So, my Scummvm is version 1.4.1. dated january 18th 2012.
Anyway, now the problem with the objects is no more. With this version Zak runs correctly. Maybe this information is useful for later versions of Scummvm. ;)
comment:10 by , 12 years ago
Using a build from the latest sources (git rev eba2ed99f8b8bf0d3aaf6a314ffbd9e196da8c8c), I'm seeing this with all of the English V1-V2 versions: C64, PC Classic, PC Enhanced, and Amiga.
comment:11 by , 12 years ago
See bug #3543335 for a savegame (Amiga) demonstrating this problem - seems I can't attach files to other people's bug reports.
comment:12 by , 12 years ago
Ok this is all strange. I have made the same experience on a Mac OS X 10.7.2 with ScummVM 1.5.0. I did the following test: I have a save game from a windows machine where things work and the glove compartment was opened already. The same save game gives the message "I can't reach it" whenever I do something in the shuttle on the Mac computer. Both versions of "Zak McKracken" are identical. So this is really a problem in ScummVM. Does anyone here have any more information on this? ScummVM is not new. So why has this bug not been solved yet?
comment:13 by , 12 years ago
For everyone who is looking for a fast solution: Download an old version of scummvm: E. g. v 1.1.1: http://scummvm.softonic.de/mac/download and everything works fine.
comment:14 by , 12 years ago
In case it might help, I opened up the debug console in ScummVM 1.4.1 (where things work find) and 1.5.0 (where I get "I can't reach it") and invoked the commands 'actors', 'objects' and 'scripts' and the results are below.
1.4.1 actors: # x y w h cos box mov zp frm scl dir cls 3 1 0 24 29 0 0 0 0 4 255 180 $00000000 4 1 0 24 29 0 0 0 0 4 255 180 $00000000
objects: num x y w h state fl cls 496 240 104 40 24 0 0 $00000000 495 200 40 96 32 2 0 $00000000 493 232 56 32 8 10 0 $00000000 71 200 40 96 32 0 0 $00000000 72 144 112 32 8 1 0 $00000000 73 264 80 16 16 1 0 $00000000 74 224 88 32 16 1 0 $00000000 488 296 0 24 128 0 0 $00000000 489 216 72 80 32 0 0 $00000000 494 8 8 296 64 2 0 $00000000 490 136 48 56 48 0 0 $00000000 491 112 0 88 16 0 0 $00000000 492 128 104 64 16 0 0 $00000000 75 0 0 0 0 3 0 $00000000
scripts: # num offst sta typ fr rec fc cut 2 6 0007c 2 2 0 0 0 0 4 9 00008 1 2 0 0 0 0 5 488 01e1b 2 1 0 1 0 0 6 84 00008 1 2 0 0 0 0 8 12 00019 1 2 0 0 0 0
1.5.0 actors: # x y w h elev cos box mov zp frm scl dir cls 3 1 0 24 29 0 0 0 0 0 4 255 180 $00000000 4 1 0 24 29 0 0 0 0 0 4 255 90 $00000000
objects: num x y w h state fl cls 496 240 104 40 24 0 0 $00000000 495 200 40 96 32 2 0 $00000000 493 232 56 32 8 10 0 $00000000 71 200 40 96 32 0 0 $00000000 72 144 112 32 8 1 0 $00000000 73 264 80 16 16 1 0 $00000000 74 224 88 32 16 1 0 $00000000 488 296 0 24 128 0 0 $00000000 489 216 72 80 32 0 0 $00000000 494 8 8 296 64 2 0 $00000000 490 136 48 56 48 0 0 $00000000 491 112 0 88 16 0 0 $00000000 492 128 104 64 16 0 0 $00000000 75 0 0 0 0 3 0 $00000000
scripts: # num offst sta typ fr rec fc cut 1 6 0007c 2 2 0 0 0 0 4 9 00008 1 2 0 0 0 0 5 488 01e1b 2 1 0 1 0 0 6 84 00008 1 2 0 0 0 0 11 201 01a1e 0 1 1 1 0 0
The differences I note from the two results are actor #4 "dir" (value is 180 in v1.4.1 but 90 in 1.5.0) and the scripts don't match (scripts # 2, 4, 5, 6, 8 in v1.4.1 but # 1, 4, 5, 6, 11 in 1.5.0)
Performed with Zak McKracken V2/DOS/ENGLISH
comment:15 by , 12 years ago
Fridvin Logi: Thank you for the debug information.
To explain to all affected users, this appears to be a regression between v1.4.1 and v1.5.0. With the attached savegame, which is from v1.5.0, on Zak/V2/DOS/English, I can replicate the problem... However, the issue is that Zak lacks boot params to jump to this point in the game: http://wiki.scummvm.org/index.php/Boot_Params and the attached savegame will load in v1.5.0, but not in earlier version such as v1.4.1.
If a user could play to this point and attach a v1.4.1 savegame (which v1.5.0 can load as we maintain backward compatiblity here as far as possible), then I can look at bisecting to work out where this regression was introduced.
comment:16 by , 12 years ago
Attaching Zak V2/DOS/English savegame from v1.4.1 (Version 88) at the mars bus, which shows no bug in v1.4.1, but shows the described bug in v1.5.0. Running bisection to locate the cause of this regression.
comment:17 by , 12 years ago
Located the regressive commit. This is de0b5f76749add219a6b667d5d2d69fb8a86d959 :
Author: Tobias Gunkel <tobias.gunkel@gmx.de> 2012-01-08 22:51:13 SCUMM: use command stack and SentenceTab in mm c64
- MM C64 uses command stack (SentenceTab, doSentence()) now - _cmdObject... added for current SentenceTab. The _active... variables are only used to build a sentence in the inventory but never by a script. -> many routines are not needed anymore and are removed
Unfortunately this is quite a large and complex change, so it will need a SCUMM engine developer to look at this and work out why this causes the problem with Zak.
comment:18 by , 12 years ago
Fixed in commit 023f6f1 (fix was also verified by Kirben). The fix should be available in the next daily version of ScummVM.
Thanks to digitall for his investigation and bisecting work, which aided a lot in locating the problematic commit. Also thanks to wjp for pointing out the code change that could have caused this.
Closing as fixed
comment:19 by , 12 years ago
Owner: | set to |
---|---|
Resolution: | → fixed |
Status: | new → closed |
henry170: Thank you for the bug report. However, some of the information needed to progress this is missing. Can you provide the following: 1. Please attach a savegame from the DOS version, in the bus and any detailed instructions needed to replicate the bug. This will enable us to replicate and investigate quickly without having to replay the game to this point. 2. Please list the version of ScummVM you are using and your Operating System? i.e. ScummVM v1.4.1 latest stable on Win32. 3. If you not using the latest stable version i.e. v1.4.1, please try replicating from a savegame on that and report the results here. 4. Please try replicating with the latest Development Daily build from your savegame: http://www.scummvm.org/downloads/#daily 5. If the bug is still occuring, please try playing from a clean start with the latest Development Daily build to see if the bug still manifests from a clean new game i.e. your savegame state may be corrupted by a bug in the earlier versions (A number of issues have been fixed in the SCUMM engine since v.1.4.1 release and will be included in the upcoming v1.5.0)