Due to poor translation of the v2 script to v5 an if statement jumps in the
middle of a cutscene causing a endCutscene() without a begin cutscene()
Previous "fixes" do improve the code, but do not fix this cutscene issue.
See also
https://bugs.scummvm.org/ticket/3099https://bugs.scummvm.org/ticket/5624
and commits
1d40f7849965e8b758b88197820daf9c6af4d120
Fixes the mistranslation of getState08(465) into classOfIs(465,[0]) at 001A
0725be325f60fa578b918aaaaef1d5f4008d310a
Fixes several mistranslations of setClass
This situation is triggered normally when _currentScript is 0xFF,
but it could potentially also happen if _currentScript is some
other number >= NUM_SCRIPT_SLOT, so the check is a bit more
conservative than it might appear to need to be.
The initializeLocals() function assumes that it can copy 25
elements when being provided an array of values. But this array
was frequently a lot smaller than that. I've introduced a constant
for the number of locals (though VirtualMachineState has one more
for some reason), and fixed the array sizes in a number of places.
CID 1003951, 1003952, 1003953, 1003955, 1003956, 1003959, 1003960,
1003961, 1003963, 100394, 1003965
Unlike the EGA DOS version, it doesn't seem to be the scripts
that keep track of double-clicks. Instead, the engine sets a
variable to indicate them. Unlike the DOS version, we don't check
that the second click happens close enough on the screen to the
first one. We could, but it seemed needlessly complicated.
command in v0
If for instance an object necessary for the sentence command is not reachable or pickupable (try to use faucet (object 55) with jar with water in microwave (object 50), the pick-up script of the jar will tell the actor to pickup object 99 (jar not in microwave)) the actor will try to pick-up the jar infinitely.
This is fixed by counting the amount of nested scripts the sentence command has called (directly or indirectly) so far and aborts it if there have been too many.
- getVerbEntrypoint() should not handle walk-to differently (revert 0x0D handling back to original behavior)
- VAR_ACTIVE_ACTOR actually is VAR_ACTIVE_OBJECT2
- runSentenceScript(): "if (_cmdVerb == kVerbWalkTo)" must be "if (_cmdVerb != kVerbWalkTo)"
- MM C64 uses command stack (SentenceTab, doSentence()) now
- _cmdObject... added for current SentenceTab. The _active... variables are only used to build a sentence in the inventory but never by a script.
-> many routines are not needed anymore and are removed
- removed complicated and unnecessary _v0ObjectIndex, _v0ObjectInInventory, _v0ObjectFlag vars
- started to merge object id and type into one object value (type<<8|id)
- verb preposition ids do not dependent on language -> remove from VerbSettings
Note:
- objects with type=0 are foreground objects. They have a state, an owner and a bg overlay image.
- objects with type=1 are bg objects. They do not have a state or owner and are already contained in the bg image. The do not have an entry in objectState/OwnerTable
The sound of trickling water in the spider lair is started, but never
explicitly stopped, so it keeps going. (Possibly not forever. When I
tried it in DOSBox, it finally stopped when I got back to the Nexus.)
The same sound effect is used the underwater cavern, and in that case
the exit script does fade out the sound so this workaround emulates
that behaviour.
Previously, we had a couple of arrays of size N (where N = number of
resource types), one for each attribute of a resource type (such as as
the number of resources of that type.
Now, we have one array of size N, whose elements are a record
aggregating all the attributes of each resource type.
MKID_BE relied on unspecified behavior of the C++ compiler,
and as such was always a bit unsafe. The new MKTAG macro
is slightly less elegant, but does no longer depend on the
behavior of the compiler.
Inspired by FFmpeg, which has an almost identical macro.
In particular, it might happen that ScummEngine::resStrLen is called
while the _scriptPointer is stale. In that case, it would be working
with the stale pointer. If the code calling it then uses fetchScript*()
methods to read the string whose length was just computed, then it would
read potentially *different* data (e.g. copyScriptString or
loadPtrToResource could have been affected).
I am not sure if this actually could have caused bugs somewhere; it might
even be provable that a script relocation cannot happen in all places
that invoke resStrLen. But for now it's much easier to make the code
safe than to verify that theory ;).
Also simplified some related code.
svn-id: r53572
The new method is called refreshScriptPointer(). Also renamed
getScriptEntryPoint() to resetScriptPointer() in an attempt to highlight
both the similarity and difference between the two.
svn-id: r53571
