| Age | Commit message (Collapse) | Author |
|---|
|
entire screen refresh
|
|
timedMessage() is always called from the scripting system. Which is updated before the rendering system.
Therefore, the message will already be rendered this frame, when the renderingManager->update() is called.
|
|
and clarify the logic. Fixes bug #6801
|
|
If we set it before the animation starts, the final turn of the
wheel won't be animated, because the puzzle will already be solved.
|
|
This is to prevent the player from entering ridiculously long
savegame descriptions.
|
|
Before this change, text was drawn in black boxes in Zork Nemesis,
so while this does make it look better (and more like the original)
this may actually make the text slightly harder to read. The
original dialogs allowed only upper-case letters, but I think that
it's better to leave that to the player.
|
|
This is a bug in the original game script of the Zork Nemesis fist
puzzle, which we now patch so that the sound checks are correct for the
left fist animation
|
|
|
|
|
|
|
|
|
|
We usually don't check a pointer before deleting it.
|
|
As suggested by Marisa-Chan. I had based my earlier implementation
on parseCritera(), and was unaware of this alternative. The good
thing is that the diff from the old code is now much smaller, which
should reduce the risk of regressions. (There is a lot I haven't
tested here...)
|
|
The volume can be either a constant or a state value. The latter is
used by ZGI to simulate a sound being heard at different distances,
e.g. the beehive in the Dungeon Master's hideout.
|
|
ZVISION: Fix sound bug #6767 by making pan_track code similar to origina...
|
|
This probably never happens, but is consistent with our common AVI
decoder.
|
|
We have to update _curChunk when decoding audio, otherwise it will
decode the entire audio track on the first frame. For the ZGI intro
this would take 700-800 ms, and since the audio started playing
before the video it looked to me as if it had to play the first bit
faster to catch up.
Thanks to fuzzie for setting me on the right track with an off-hand
remark about the Zork AVI decoder (I was looking at the standard
AVI decoder), and for finding the cause a few seconds before I did.
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
A bug in commit 21e9007d80. Thanks to fingolfin for pointing it out
|
|
|
|
|
|
|
|
|
|
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.
|
|
This prevents the cheat codes from being accidentally triggered when
using the save screen, for example
|
|
|
|
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.
|
|
A regression from commit dcac5be493
|
|
Avoid overwriting the previous location when loading a saved game
|
|
|
|
|
|
The save buffer preparation code had a bug, which triggered in the
jail area because its room is 'j'
|
|
do change location when coming back from restore dialog
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)
|
|
dialog"
This reverts commit b835eacc0cd401bb0d15a33e60d2ac47ebb4d718.
|
|
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.
|
|
|
|
|
|
A regression from commit d70503cc98. Thanks to wjp for bisecting.
|
|
|
|
|
|
This is based on Marisa-Chan's observations in commit 28e27ea1d9.
Tested with both ZNEM and ZGI
|
|
|
|
|
