Opened 11 years ago
Closed 7 years ago
#6382 closed defect (invalid)
TUCKER: Traffic Cone/Drainpipe Swap Bug
| Reported by: | (none) | Owned by: | bonki |
|---|---|---|---|
| Priority: | normal | Component: | Engine: Tucker |
| Version: | Keywords: | original | |
| Cc: | Game: | Bud Tucker |
Description
The original game has a "data bug". I give full detail. The game uses the file CSDATA.ENC (it is encrypted, you need to decrypt it to see the plain text), to read and execute instructions. These instructions are like: add X item to the inventory, remove X item from the inventory, show 3 answers in a conversation, etc. They are composed of three letters like "ofg","c0s","bus","pan","bua", etc, and some numbers then.
In the third part of the game, in the park, you need to talk to Royston to do an object exchange. Bud will give him a traffic cone, and Royston will give you a drain pipe. The line in the CSDATA.ENC that do that, it does more things apart of the object exchange. There are TWO LINES that do that (the object exchange). The line that the game will execute depends on your gameplay and the order of resolving puzzles. OK, the problem is that, ONE of the TWO lines, is missing the object exchange! So you will read (if you activate the subtitles) or hear the voices, that Bud and Royston are exchanging the objects but when the conversation ends, you continue having the traffic cone, and you don't get the drain pipe. So if you have bad luck (like me), and the game is executing the line without the object exchange, you will never get the required object. This can be resolved (i have successfully tested it) modifying the file CSDATA.ENC, but users must specifically know that, so i propose a workaround in ScummVM to correct this.
The instruction to interact with objects is "ofg". It has two parameters: the object number (a value that identifies an object in the game), and the action to do (00=remove the object from the inventory, OR 01=add the object to the inventory).
These are the two lines in the CSDATA.ENC file. They are similar: dw ssp,160,060,tpo,0880,bus,094,wa+,c0s,095,wa+,bus,096,wa+,c0s,097,was,gv,09,wat,050,bus,078,wa+,gfg,090,01,end//09 dw ssp,160,060,tpo,0880,bus,060,wa+,c0s,061,wa+,bus,062,wa+,c0s,063,wa+,gv,09,bus,064,was,bus,078,wa+,ofg,036,00,ofg,035,01,end//10
As you see, the second line is correct, it has at the end "ofg,036,00,ofg,035,01", that is, remove the object 36 (traffic cone) from the inventory and add the object 35 (drain pipe) to the inventory. But the other line not!!! So, in the game, anytime you talk to Royston (having done some previous puzzles), if you have the bad chance, that the first line is executed (like me), you will never get the drain pipe, that occurs to me, and i solved it adding "ofg,036,00,ofg,035,01" to the first line and it worked perfectly as it has to be (as i told, you can read or hear Bud and Royston doing the object exchange). If you try to speak again with Royston, to see if the game will execute the other line, it doesn't work, because once the game as chosen the line, it will always execute the same one...
So, original problematic line: dw ssp,160,060,tpo,0880,bus,094,wa+,c0s,095,wa+,bus,096,wa+,c0s,097,was,gv,09,wat,050,bus,078,wa+,gfg,090,01,end//09 Modified (problem solved) line: dw ssp,160,060,tpo,0880,bus,094,wa+,c0s,095,wa+,bus,096,wa+,c0s,097,was,gv,09,wat,050,bus,078,wa+,gfg,090,01,ofg,036,00,ofg,035,01,end//09
As i told, this also happen in the original game running it from Dosbox.
CAN ANY DEVELOPER ADD A WORKAROUND FOR THIS BUG PRESENT IN THE ORIGINAL GAME?
THANKS!
Ticket imported from: #3614702. Ticket imported from: bugs/6382.
Attachments (2)
Change History (17)
by , 11 years ago
| Attachment: | Dosbox_savegame_original_game_bug.zip added |
|---|
by , 11 years ago
| Attachment: | CSDATA.zip added |
|---|
Modified CSDATA.ENC to fix the problem (overwrites it to the original)
comment:1 by , 11 years ago
I added a savegame from Dosbox. Load the savegame, and speak to Royston. You will see the problem.
I added also, a modified CSDATA.ENC, overwrite it to the original. Then load the savegame, and speak to Royston. Now you will get the drain pipe (problem is solved). So, a workaround is needed if we don't want to distribute the modified CSDATA.ENC file...
comment:2 by , 11 years ago
| Summary: | TUCKER: VERY IMPORTANT BUG: Cannot get an object → TUCKER: Traffic Cone/Drainpipe Swap Bug in Spanish Version |
|---|
comment:3 by , 11 years ago
| Keywords: | original added; script removed |
|---|
comment:4 by , 11 years ago
Unamed Google User: Thank you for reporting this bug. As it occurs in the original, we will try to add a workaround to the code to detect the problematic script line and inject the missing object exchange instructions, but this is not trivial and may take some time to do. Also, bugs present in the original games receive a lower priority, so this will be dealt with when an engine developer has some time to look at it.
P.S. Please do not add "VERY IMPORTANT BUG" or similar to any future bugs. Priorities are determined by the team anyway and this only serves to irritate.
comment:5 by , 11 years ago
| Owner: | set to |
|---|
comment:6 by , 11 years ago
| Owner: | removed |
|---|
comment:8 by , 11 years ago
I have edited the bug title to remove "spanish version" because THE SCRIPT BUG IS ALSO PRESENT IN THE ENGLISH VERSION, not only the spanish...
comment:9 by , 11 years ago
| Summary: | TUCKER: Traffic Cone/Drainpipe Swap Bug in Spanish Version → TUCKER: Traffic Cone/Drainpipe Swap Bug |
|---|
comment:10 by , 11 years ago
We should figure out which condition triggers this "no swap" behaviour before changing anything, to see if it is intentional somehow, or if the condition is broken, or if indeed the swap is missing.
comment:11 by , 11 years ago
I think there is no need to figure it out...
You can see Bud and Royston talking about the object exchange and they "SUCCESSFULLY" DO THE EXCHAGE if you read the conversation (Bud express gratitude to Royston for the object). When i was playing the game in dosbox i get stuck so many hours because that, i tried so many times to speak with royston again but the exchange never happen so i did a trick: i edited manually the savegame with an hex editor, so i overwrite the drain pipe value over my traffic cone value. So that makes me have the pipe in my inventory. But also, i needed one more thing, also i put an 1 (0x01) over the offset 1500 in the savegame (this is the flag that tell the game you have the pipe, so the Professor will detect you have the pipe and Bud successfuly will give it to him). Without this flag setted, you have the pipe in the inventory but the professor will not detect you have it. Then, after completing the game, investigating, i discover that the original developers forgot the object swap i told in one of the two lines, so i add it, load the old savegame and... it works!
People that haven't got this problem, is because the game readed the other line (that has the object swap exchange).
comment:12 by , 11 years ago
Still, I'd rather know why it decides to take the working or broken line than modify a script without understanding it.
comment:13 by , 7 years ago
Action 9 (the first line) seems to depend on you having both the traffic cone and the raincoat (I base this on "bus,094" which makes Bud say "Hey Royston! I've got the traffic cone and the raincoat").
However, I cannot seem to replicate this and trigger said action.
I've tried trading the raincoat for the fish to get the traffic cone and then traded the orange ni object to get the raincoat back so I ended up having both the cone as well as the raincoat. Yet, action 10 (the second line) is triggered.
I'll have to take a closer look at the scripts when I have more time.
comment:14 by , 7 years ago
The state of flag 93 is hardcoded (see execData3PreUpdate_locationNum61()) and based on the inventory state of the tuple (cone, raincoat).
Flag 91 is scripted and gets set to 2 when you trade the raincoat for the fish (still uncertain under which circumstance(s) it gets set to 1).
Flag 92 gets set the first time you talk to Royston it seems, doesn't really matter though in this case.
flags
91 92 93 actn verb state
dw 02,02,016,00,000-092,00,000,00,003,00,016,04,092,01-00,00 . 0 . 16 talk
dw 02,02,016,00,000-091,00,093,00,003,00,013,04,000,00-00,00 0 . 0 13 talk !cone, !coat
dw 02,02,016,00,000-093,02,091,00,003,00,031,04,091,02-00,00 0 . 2 31 talk !cone, coat; trade coat for fish
dw 02,02,016,00,000-093,02,091,01,003,00,011,04,091,02-00,00 1 . 2 11 talk !cone, coat; trade coat for fish
dw 02,02,016,00,000-093,01,091,02,003,00,010,04,000,00-00,00 2 . 1 10 talk cone, !coat; has had fish
dw 02,02,016,00,000-093,03,091,02,003,00,010,04,000,00-00,00 2 . 3 10 talk cone, coat; has had fish
dw 05,03,036,02,016-093,01,091,02,003,00,010,04,000,00-00,00 2 . 1 10 give cone, !coat; has had fish
dw 05,03,036,02,016-093,03,091,02,003,00,010,04,000,00-00,00 2 . 3 10 give cone, coat; has had fish
dw 02,02,016,00,000-093,03,091,00,003,00,005,04,000,00-00,00 0 . 3 05 talk cone, coat
dw 02,02,016,00,000-093,03,000,00,003,00,009,04,000,00-00,00 . . 3 09 talk cone, coat
If I haven't done any mistakes it seems as if action 5 and 9 trigger if you manage to hold both the cone and the raincoat without ever having had the fish. I'm not sure how to acquire the cone without the fish, though.
If I set game state manually I can reproduce this and it certainly looks like a bug (in both cases actually, i.e. action 5 AND 9), but I'm not 100% convinced yet.
comment:15 by , 7 years ago
| Owner: | set to |
|---|---|
| Resolution: | → invalid |
| Status: | new → closed |
I'm closing this for now as OP only referred to the original game and didn't state if this even occurs in ScummVM. Furthermore, I don't see how it's possible to end up with this game state, that is, how to acquire the cone without having had the fish first. OP mentioned hex-editing savegames both in this and another ticket so it's certainly possible that this gamestate didn't occur "naturally". It's not entirely impossible either that earlier versions of ScummVM never set some required flags, i.e. the bug might have been fixed in the meanwhile.
If someone can confirm that this bug actually exists in current ScummVM (this includes explaining in detail how to trigger it and attaching a working savegame) we can reopen the ticket and the above information should be enough to facilitate implementing a workaround.
Dosbox savegame to reproduce the problem (simply talk to Royston)