This commit properly takes care of #10854 and #1016;
the previous code was retrofitted from v5 and thus potentially
presented inaccuracies (e.g. room 1 in LOOM CD shouldn't
cycle colors).
A post-load fix was also necessary for older savegames,
otherwise color cycling would not occur at all until the room
was exited and then re-entered. Being that the cycling data
was being mangled by the previous implementation, there was
no choice but to introduce a new save version to detect this.
Limited Run Games not only sold an anthology with corrupted 903.LFL
and DISK04.LEC files for the original English EGA release of Monkey 1,
the DISK03.LEC file is also corrupted, at least in costume 78-11 at the
church near the very end of the game, making it unplayable by default in
this officially sanctioned release.
We can't do anything to fix this ourselves, but it's still possible to
recover proper files from the KryoFlux dumps also provided by LRG.
So, detect this faulty DISK03.LEC file as well, and tell users that
it's corrupted before they report weird crashes which are totally out
of our scope. Hoping that LRG provides fixed files to customers who
would contact their support...
Checked against my own LRG copy and against my original Ubisoft CD of
the French EGA release for reference.
Trac#14500.
Some resource files from MM1 are opened by ID, that is hash(filename).
The ID for "049.att." file is exist and incorrect for this file.
MM4-5 games should not use IDs at all.
Not sure if here is the right place to select the way sprite loads.
But it fixes bug #14503.
When statically linked, this makes about 8000 variants.
This change takes only engines and games present in a domain into
account. This speeds up loading time on slower backends quite
noticeably.
We don't support running the game directly from it, since doing
so would bypass the need for the original game. But at least
this way, it will be recognised, and users will be given an
informative message of why the game won't run.
[Based on Director in a Nutshell, page 15]
The following properties of a sprite are auto-puppeted whenever
the property is set: backColor, blend, editable, foreColor, height,
ink, loc, locH, locV, member, moveable, rect and width. Auto-puppeting
of individual properties has no effect on the puppet of sprite property
['Lingo Dictionary' 601 Fixes]
Sprites now have a duration as specified in the (new) score view.
When lingo modifies any of the sprite properties that property
will be auto-puppeted, i.e. the value set will stick for the
duration of that sprite despite any values recorded in the score.
This can cause existing lingo which relied on setting the property
of a sprite without the use of 'puppet' to behave differently.
Calling 'puppetSprite spriteNumber, FALSE' will also clear any
currently auto-puppeted properties.
In original engine it is possible to set non-puppted sprite properties
like position, backcolor etc and then call updatestage to update the
screen according to property. This is undocumented behaviour
which is not present depicted in any books however with rigorous testing
it is found to be true. This change only persist for the current frame
and once the playback head is moving the change is lost.
`ATD\HD\bdDREAMA.DXR` of 'totaldistortion' used some of this quirk to
display moving bullets.
