When skipping the intro via 'Esc' and 'Skip' the script
sets up a pause which it won't release later. This brings
our pause counters out of sync and triggers an assert.
This fix should work around this...
Even though strcpy in SegManager isn't a problem, our forbidden symbols
list being defined at preprocessor level, we won't be able to use this
name anymore.
This is similar to what we recently fixed for the saving. It does concern only the loading from the SCI menu and from the SCI death dialog (that's how it got my attention).
I have written a long comment in SciMusic::resetGlobalPauseCounter() which explains it.
I have decided to make this very obvious (you could say: more ugly), so it won't cause confusion in the future. Of course, it could be just hidden somewhere deep in SciMusic::saveLoadWithSerializer() and noone would ever notice. But the "ugly" way seemed the safer thing to do...
`SavegameDesc::name` is now easier to understand and safer to use.
Fixes Phant2 regression from 913d943a09
Fixes Phant2 out-of-bounds read in `Console::cmdListSaves`
This was originally always a null terminated string but when SCI32
was added the terminator became optional, leading to a confusing
situation. `name` is now always terminated internally. SCI16 interfaces
continue to terminate the 36th element and SCI32 interfaces continue
to use the first 36 elements as-is.
See: 4357809ce8
It's normal for fewer charcters to be available than the maximum buffer
size . Confirmed that nothing depends on not zeroing out the remaining
bytes. (In fact, we've had problems before when not zeroing out buffers
in other kernel functions as scripts have been known to assume success
and use the buffer regardless of the return value.)
The existing workarounds for this game's unique way of handling saves
assumed that the player restored a game at some point before the end.
Starting a new game and playing to the end would still cause an error
in the SCI1.1 floppy version because the game's save global would
contain an SCI id instead of our virtual id; we were only patching the
global when restoring.
Now we also patch the global on kSaveGame so that it always contains a
virtual id when there is a saved game.
Note that the existing uninitialized read workaround had no effect since
the read occurred in a local procedure but the workaround entry didn't
include a local procedure signature. Updating that workaround wouldn't
fix this; there would still be scenarios where the wrong save would be
auto-deleted.
Fixes bug #5294
With the latest changes to savegame streams, seeking to a location
past the end of a file results in an assert. Restore the previous
behavior, where the file pointer seeks to the maximum available
file location.
This easter egg is present in script 805. In this easter egg, Gabriel
draws a doodle of Jane Jensen in the whiteboard, if the player uses the
operate action below the whiteboard's eraser. This easter egg looks for
a file named "buster" to be present, so that it is enabled. We always
report that this file exists, to unlock the easter egg.
Special thanks to sluicebox for his awesome work on discovering this
easter egg: https://www.benshoof.org/blog/gabriel-knight-1-easter-eggs
Make sure that Hebrew save games are using UTF8 (otherwise, when saving
in Hebrew it works well from original Sierra save/restore dialogs, but
when loading from ScummVM's dialog, it looks garbled)
Fixes KQ7 deleting the wrong save game and other bugs.
Most of these digit strings start with zero and so they've
been parsed as octal instead of decimal.
Factors some common save game code into functions and creates an
overload of GuestAdditions::runSaveRestore that doesn't rely on
SCI memory for returning the description string, all of which will
be used by the custom save/restore kMacPlatform32 subops.
These are structures which are stored in the ARC files of the Behind
the Developer's Shield and Inside the Chest demos, included in several
editions of the King's Quest Collection.
The number of elements and element size of each array element are
stored with each array, and are read as raw bytes. We don't need these
in ScummVM, so we skip them.
This change allows the two demos to function fully and correctly now.
Special thanks to sluicebox for working on these files and their
associated game scripts, and figuring out these extra bytes, which
have remained a mystery up to now.
Allows patching a Phantasmagoria 1 script to copy instead of rename.
Although most games can call this through their File:copy script, none
have been discovered yet that do.
Phantasmagoria 1 save files are uncompressed because they are small
and interoperable with the original interpreter, but the game scripts
frequently rename them. Renaming save files unconditionally compresses
the result and so only some files have been interoperable.
Phantasmagoria 1 files now remain uncompressed when renamed.
Fix a number of incorrect return values from file IO functions, continuing
the kFileIOWriteString fix from 7c1fb8bee1
One of the misconceptions was that these functions return DOS error
error codes on failure. Instead, SCI16 immediately zeros those out.
Fixes bugs in trac #11029:
- Slot 1 loading when user selects slot 0 in ScummVM UI
- Slot 1 loading when slot 0 specified on command line
- QFG4 slot 0 not appearing in game's original Restore UI
This will cause non-linear time shifts in the system timer that
the game's custom save logic may not expect, but in initial testing
the game doesn't seem to care about this.
Fixes Trac#10259.
This file normally stores brightness, music volume, and most
recently used save game directory. Since we store the music volume
ourselves and don't use the save game directory, the only
potentially useful information is the brightness level, and that
is fine to just restore from the save games.
Despite what game script disassembly lead me to believe, the game
seems to create only one auto-save, which ends up being saved as
911.sg (not autorama.sg). This save file is created just before
entering the underground Avian Lair in New York, and seems to be
designed as some emergency backup since entering the Avian Lair is
a one-way trip.
The game has a feature where it will automatically create a save
game when you quit the game through the in-game control panel (or
when you die, for some reason).
Unfortunately, due to bad programming, this automatic save would
just overwrite whatever was in save slot 1 (slot 0 in the original
interpreter). Find this attempt to auto-save the game and redirect
it to the auto-save slot. This might not be totally correct, but
it is at least better than destroying a save game.
Fixes Trac#10201.
To enable the optional content censoring mode, Phant2 looks
for a RESDUK.PAT file, which is normally placed by the game's
installer if the user chose to enable censorship. If the file
exists, the game reads an unlock password out of the file and
asks the user to enter the password when starting a new game to
create an uncensored game, or to click a "less intense" button
to start the game with censoring. The censorship state of the
game is then persisted in the save game file, and installations
with the RESDUK.PAT file need to enter the password again in
order to restore any of the uncensored saves.
Since we do not have an installer that can enable this feature,
add a game option toggle to enable/disable censoring (for the
releases that have the optional censorship mode) instead so the
censored content feature is available for anyone that wants to use
it. This flag is restored from ScummVM whenever a save game is
loaded, so it can be toggled on or off at any point without
needing a separate save game, unlike in the original interpreter.
Phant2 creates save game names that append "<PROTECTED>" at the
end of the game name, with an assumption that the game name is
always exactly 36 characters long. This seems to be OK with other
games too (tested GK1, SQ6, and Torin).
Save game metadata validity checks in SCI32 should all exist within
kCheckSaveGame32 since this allows most games to recover
successfully from an attempt to load an invalid save game. If
gamestate_restore fails, the game will usually crash because the
engine is left in an inconsistent state (game scripts have cleaned
up objects in preparation for a game load that is no longer
happening).