This should be an error, as we've effectively reached a non-existing
scene (such as in bug #6780), or we haven't parsed script files of a
scene fully, thus unexpected behavior will likely occur
If seeking to the final frame of an edit, _nextFrameStartTime wouldn't be adjust properly and would wrongly say that it's at the end of the edit. This never affected anything because of the edit "-1" hack.
Because we use Common::String to store UTF-8 data, the font
renderer will draw the wrong glyphs for non-ASCII characters,
unless we first convert the string to UTF-32. (I thought the same
change would have to be made for the ZGI game over screens, but
apparently they work anyway. At least the German version, I'm told.)
I've discussed this change with [md5], and while it would probably
be more correct to make the engine use UTF-32 throughout, that is
also rather painful.
A condition in a criteria is made up of three tokens: An id, an
operator and an id/value. However, in my copy of ZGI, puzzle:07507
has "[00202] !3 # SPELL_12_IN_BOOK", i.e. there was no space
between the second and third tokens. This caused the "glorf" spell
to not be properly inscribed in your spell book.
To fix this, if the second token is more than one character we use
the rest of it as the third token.
In the Zork: Nemesis version bundled in the ZGI SE DVD, the bell rope
puzzle has been modified so that it's non-interactive, i.e. there isn't
a hotspot to click while the video is playing, and the player is
transported to the next room. In the patched script, all criteria of
that puzzle were commented out, resulting in an invalid criteria list.
Skip any commented out criteria, to avoid ending with an invalid list.
Fixes bug # 6771
We don't need to change locations, since we use the ScummVM save dialog instead
of the original one (which is actually a location). Instead we just need to reset _nextLocation to
_currentLocation so the engine can stop trying to save. If we change locations, the
StateKey_LastWorld/Room/etc. end up being overwritten with the current room. So if a script
refers to location 0, 0, 0, 0 (aka, the last room), the engine will try to change location to the same room.
On restore, we have to force a location change, just in case we restore to the same room. (Since the logic
will only do a location change if _nextLocation != _currentLocation)
Fixes bug # 6771
We don't need to change locations, since we use the ScummVM save dialog instead
of the original one (which is actually a location). Instead we just need to reset _nextLocation to
_currentLocation so the engine can stop trying to save. If we change locations, the
StateKey_LastWorld/Room/etc. end up being overwritten with the current room. So if a script
refers to location 0, 0, 0, 0 (aka, the last room), the engine will try to change location to the same room.
