Opened 12 years ago
Closed 6 years ago
#6180 closed defect (fixed)
SCI: QFG1VGA - game hangs in the tavern
Reported by: | misterhands | Owned by: | bluegr |
---|---|---|---|
Priority: | normal | Component: | Engine: SCI |
Version: | Keywords: | script | |
Cc: | Game: | Quest for Glory 1 |
Description
Latest Win64 daily build QFG1VGA ENG
In the tavern if you use the hand icon on the goon the game hangs and you have to reload the game. In other circumstances the goon says : "Oh yeah, what's the password?", and the game does not freeze. 2 savegames uploaded, one for each case.
This freeze also happens in DOSBox.
Ticket imported from: #3585189. Ticket imported from: bugs/6180.
Attachments (4)
Change History (12)
by , 12 years ago
Attachment: | Goon freeze.zip added |
---|
comment:1 by , 12 years ago
Summary: | SCI: QFG1VGA : game hangs in the tavern → SCI: QFG1VGA - game hangs in the tavern |
---|
comment:2 by , 12 years ago
comment:3 by , 12 years ago
Thanks for your report. This is an edge case, where scripts are trying to move Ego to an unreachable spot and wait forever.
The bug has been fixed in commit b0cfe96 by changing the expected location that Ego should be at the end of his movement. The fix should be available in the next daily version.
comment:4 by , 12 years ago
Owner: | set to |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:5 by , 6 years ago
Resolution: | fixed |
---|---|
Status: | closed → new |
In the tavern, if you talk to card players (or just going to their table) and then use the hand icon on the goon the game hangs.
In other circumstances, the goon says : "Oh yeah, what's the password?", and the game does not freeze.
It happens in DOSBox and in ScummVM. Video from DOSBox, savegames from DOSBox and savegames from ScummVM are attached.
comment:6 by , 6 years ago
This is a different bug than the original, although they both leave you stuck when clicking on crusher.
This is a script bug that's unrelated to pathfinding. rm331:doit stops the ego's current script when ego walks away from the card players, assuming it must be cardScript. They didn't consider that it could be moveToCrusher, and so ego reaches the intended coordinate but no longer has a script to continue the sequence and re-enable controls.
comment:7 by , 6 years ago
Thanks for reporting this, I've created a new ticket #10826 as this one turns out to be a different bug under the hood. Setting this one back to closed.
comment:8 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
The reason why it's hanging is because the game scripts try to move the hero when he's not close to the crusher, via calling MoveTo, which in turn calls kInitBresen, kDoBresen, kGetAngle and kGetDistance, among others. kAvoidPath is not used in this case. The problem lies with the fact that the game scripts try to move the hero behind a barrier. In the original, he moves one step closer than in our implementation. This distance causes the scripts to infinitely wait for Ego (the hero) come closer to the crusher.
The most likely culprit seems to be kDoBresen.
Some screenshots, when clicking on the crusher: DOSBox: http://img703.imageshack.us/img703/669/scidhuv000.png ScummVM: http://img717.imageshack.us/img717/6374/scummvm00001.png and a screenshot with the barriers: http://img11.imageshack.us/img11/4822/scummvm00002.png