Opened 10 years ago
Closed 8 years ago
#6385 closed defect (fixed)
TONY: Vanishing Cursor at Ferris Wheel
|Reported by:||raziel-||Owned by:||dreammaster|
ScummVM 1.7.0git (Aug 2 2013 11:24:20) Features compiled in: Vorbis FLAC MP3 RGB zLib MPEG2 Theora AAC FreeType2
Pretty late in the game when one has to trick the castle guard with the ferris wheel, there is a bug where the cursor does not return when the whole scene of "fishing" the guard is over.
One can still move the cursor and open/close the bottom inventory, but clicking anything does take no action. Also, after this scene, no in-game keyboard command is taken into account which means, no menu is reachable either.
This draws the game incompleteable from this point on, i'm afraid
Tony Tough and the Night of Roasted Moths (Windows/English)
AmigaOS4 - PPC - SDL - BE gcc (GCC) 4.2.4 (adtools build 20090118)
Ticket imported from: #3614869. Ticket imported from: bugs/6385.
Change History (7)
by , 10 years ago
comment:1 by , 10 years ago
comment:2 by , 10 years ago
It looks like the idle action returning the guard to his post is running and calling disableInput.
comment:3 by , 8 years ago
comment:4 by , 8 years ago
Okay, I've done some further analysis of the bug, as best I can:
When you pull the lever, several co-routine "threads" are started, which use the "actionThread" method to handle executing a series of script instructions. For our purposes, the two important ones have a "_dwRes" of 0 and 9. The 0 one has 22 instructions, and it's this one that calls the RMGFXEngine::disableInput at it's start. The 9 one has 56 instructions, and it's the one has the full logic for the overall cutscene - the guard being pulled up, him shouting, and Tony's final quips.
The problem seems to occur in part due to the scene change from the Ferris wheel to showing the guard in the next room. This doing so causes the LocationPollThread to unload action _dwRes 0 before it finishes. And it never gets to it's end, which I presume was intended to happen once the other action thread, dwRes 9 with 56 instructions, finishes.
Of course, the further question is why isn't the 56 instruction thread for handling the cutscene not also unloaded when the scene change occurs. I'll have to look into it a bit further.
Worst case, though, we can simply put a workaround in ActionThread that when it gets to instruction 55 (i.e. the last opcode) of that specific script, then it manually calls enableInput(). That actually may be safer than fiddling around with the the threading code of Tony, since anything I did to try and stop the thread being unloaded prematurely could have side effects on other scripts in the game.
comment:5 by , 8 years ago
On further experimentation, it looks like script 0 isn't even getting as far as disabling input on the times when the cutscene works successfully. I didn't have much luck pinning down why/how it's killed, but I have a supposition that the script is associated with the default animation of the Ferris wheel - when the full "capture" cutscene starts up, it's meant to disable the other thread and take over to do the full sequence. But due to an original script bug, they simply relied on the full cutscene script getting to the point it could kill the other thread as quickly as possible. Depending on timings, though, the other script can at least get as far as disabling input before it is killed. And since the cutscene script never disables input (it simply has active "actions" for each step of the cutscene), it doesn't do an "enableInput" at the end, and so player input remains disabled.
Thread timing is definitely not something I want to start playing around with, so I'm going to simply put in a workaround for that specific script, as I suggested above.
comment:6 by , 8 years ago
|Status:||new → closed|
Go right, blow the whistle, go left, pull the lever