#6085 closed defect (fixed)
SCI: LONGBOW: Man with Tuck in camp
| Reported by: | tsoliman | Owned by: | bluegr |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCI |
| Version: | Keywords: | script | |
| Cc: | Game: | Conquests of the Longbow |
Description
Step to reproduce:
Start a new game. Go outside the cave. Skip dialogue. Click on map icon to travel. Click on campfire icon to go back to the camp. Observe Tuck. There is a man with him that the game doesn't achknowledge.
Ticket imported from: #3540976. Ticket imported from: bugs/6085.
Attachments (2)
Change History (12)
by , 11 years ago
| Attachment: | longbow.jpg added |
|---|
comment:1 by , 11 years ago
Happens for me too.
Also tried dosbox: there it doesn't behave exactly the same as in scummvm, but it has a similar glitch for a little while at that spot.
comment:2 by , 11 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
comment:3 by , 11 years ago
In this case, both Friar Tuck and the unknown man belong to the same view (view 168, loop 2). So it's completely logical that the second man can't be interacted with, as the two are counted as the same sprite (friar Tuck). Therefore, this seems like a normal game animation, which is supposed to be shown that way. Closing as invalid.
comment:4 by , 11 years ago
| Resolution: | invalid |
|---|---|
| Status: | closed → new |
comment:5 by , 11 years ago
That doesn't change that the same loop isn't being used in dosbox in that scene, though.
comment:6 by , 11 years ago
Ah, that wasn't apparent from the previous replies.
This is a script bug, game scripts set an invalid cel number for Friar Tuck. In this case, this invalid number gets fixed inside GfxAnimate::adjustInvalidCels() but the original interpreter also sets the loop to 0, which we don't do (thus a wrong loop is shown).
This is just bad design from the original engine. It's not very safe to change this check unless we can absolutely verify it against disasm (and how it has been changed with each SCI version). Alternatively, we could put a game ID/room check for it
comment:7 by , 11 years ago
Some experimenting seems to point at subtle numerical differences in GetAngle being responsible for this.
Switching to an atan2-based GetAngle instead of the current approximation makes scummvm behave like dosbox for me.
comment:8 by , 11 years ago
The problem has been narrowed down to our implementation of kGetAngle.
I've added a hack to fix this for now, but kGetAngle will have to be revised so that it's closer to the original behavior after the 1.5.0 release.
comment:9 by , 11 years ago
kGetAngle was changed from SCI1 (QFG2 onwards)
Properly fixed in 9568b78babdbdf350fd6c47b261c3f21902c31fc
comment:10 by , 11 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
Screenshot