Opened 12 years ago

Closed 6 months ago

#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


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)

longbow.jpg (56.3 KB ) - added by tsoliman 12 years ago.
longbow.003 (33.7 KB ) - added by tsoliman 12 years ago.
Savegame with the bug present

Download all attachments as: .zip

Change History (14)

by tsoliman, 12 years ago

Attachment: longbow.jpg added


by tsoliman, 12 years ago

Attachment: longbow.003 added

Savegame with the bug present

comment:1 by wjp, 12 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 bluegr, 12 years ago

Resolution: invalid
Status: newclosed

comment:3 by bluegr, 12 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 wjp, 12 years ago

Resolution: invalid
Status: closednew

comment:5 by wjp, 12 years ago

That doesn't change that the same loop isn't being used in dosbox in that scene, though.

comment:6 by bluegr, 12 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 wjp, 12 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 bluegr, 12 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 bluegr, 12 years ago

kGetAngle was changed from SCI1 (QFG2 onwards)

Properly fixed in 9568b78babdbdf350fd6c47b261c3f21902c31fc

comment:10 by bluegr, 12 years ago

Owner: set to bluegr
Resolution: fixed
Status: newclosed

comment:11 by sluicebox, 6 months ago

Resolution: fixed
Status: closednew

This is still an issue. Current behavior might be different than back when this was reported, but Tuck still changes loops in ScummVM instead of staying seated as in the original.

I agree that the issue is probably in the kGetAngle calculations, but the script is doing something weird.

On day one, Tuck is sitting and eating fish. The script tuckAlone calls the Face function to make Robin face Tuck, and then it also calls Face to make Tuck face Robin. That second call doesn't make sense, because Face is for actors who are standing up so they can change directions. The Tuck actor always has a looper (tuckGrooper) so changing his heading, etc sets off a series of events that *could* change his loop, depending on the angle values returned from the kernel.

In the original, this second Face call has no visible effect. In ScummVM, it changes Tuck's loop.

comment:12 by sluicebox, 6 months ago

Resolution: fixed
Status: newclosed

Closing this again; what I'm seeing is original behavior. I was testing a different version in DOS earlier.

The Sheriff flicker when Tuck stands is original behavior introduced in version 1.1. That's when they added the Face calls I described above. It's behaving the same in both interpreters.

Note: See TracTickets for help on using tickets.