diff options
author | Torbjörn Andersson | 2015-10-11 08:00:23 +0200 |
---|---|---|
committer | Torbjörn Andersson | 2015-10-11 08:00:23 +0200 |
commit | 0f3e7531c1999da4c424481afd42c5380ec10103 (patch) | |
tree | 77e696fc067959cfb7cf6366e26566ff712cb7f3 /devtools/credits.pl | |
parent | 4e6cdf71fb69a9f23ea0c1ec829722248b66c5e4 (diff) | |
download | scummvm-rg350-0f3e7531c1999da4c424481afd42c5380ec10103.tar.gz scummvm-rg350-0f3e7531c1999da4c424481afd42c5380ec10103.tar.bz2 scummvm-rg350-0f3e7531c1999da4c424481afd42c5380ec10103.zip |
NEVERHOOD: Possible fix for bad car behaviour
This is something I found when trying the savegame from bug #6932,
but I still don't know if it actually is that bug.
From what I understand, there are two different cases in the
moveCarToPoint() method: One where you click on a different
section on a track than you're on, and one where you click on the
same section on the track that you're on.
In the latter case, it sends message 0x2004 to the car, which is
then handled by AsCommonCar::handleMessage(). That one will assume
that the parameter is a point, but this can also be encoded as an
integer with 16 bits for the X coordinate and 16 bits for the Y
coordinate. See MessageParam::asPoint().
If we only pass an X coordinate to the message, the Y coordinate
is assumed to be 0, and we do this in a couple of places. I do not
know the exact implications of that, but in the two cases I've
changed here, it meant that clicking on the track below the car
would still make it go up, because it thought you were travelling
towards the top of the screen.
So I think this is the appropriate fix, but even if it is, I do
not know if it's enough or if it should be changed in other places
as well.
Diffstat (limited to 'devtools/credits.pl')
0 files changed, 0 insertions, 0 deletions