| Age | Commit message (Collapse) | Author |
|---|
|
|
|
ENGINES: Allow detection entries to match on full paths
|
|
GUI: Fully hide GMM save/load buttons if not supported by engine
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The ScummVM implementation of class SciArray::fill() has a bug where it
will overwrite the array[index] with the value count times, rather than
fill the array starting from index count times.
This patch fixes that behavior. This was noticed because the LSL7 dice
game was broken, it was impossible to lose. After this patch the dice
game works as expected.
Closes gh-953.
|
|
|
|
|
|
Previously, they were only greyed out. According to the discussion on
patch #8925, this was a limitation of the GUI layout engine when these
buttons were introduced in 2008. This no longer seems to be a problem.
|
|
|
|
This issue also happens when using the original interpreter.
|
|
Room 540, was game breaking, but effectively a script
bug, that just happened to work in SSCI.
|
|
|
|
LSL7 originally came with music in two qualities in subdirectories of
the 'music' directory, 22s8 and 22s16. The gog.com release doesn't do
this and only ships the hq music in the root of 'music/'. This PR adds
it to the search path.
Closes gh-951.
|
|
Fixes Trac#9796.
|
|
|
|
|
|
|
|
Currently translated at 100.0% (957 of 957 strings)
|
|
Currently translated at 100.0% (957 of 957 strings)
|
|
|
|
|
|
|
|
|
|
On macOS, the return code from OSystem::openUrl was the opposite
of what it was supposed to be; it is now fixed, so this caller
needs to be fixed too.
|
|
|
|
This allows an engine to match files that exist multiple times
in the same game directory with the same basename.
For example, different releases of Torin's Passage in SCI engine
come with zero or more GERMAN, FRENCH, ENGLISH, etc. directories,
all containing files with the same basenames but with different
contents per language. Because the allFiles map used only the
basename of a file as a key, it could not match more than one of
these localization directories, which made it impossible to select
from all the possible languages.
Refs Trac#9772.
|
|
|
|
Currently translated at 99.8% (956 of 957 strings)
|
|
Currently translated at 100.0% (957 of 957 strings)
|
|
Closes gh-948.
|
|
Currently translated at 100.0% (957 of 957 strings)
|
|
Bad resources that need to be blacklisted sometimes seem to have
the same size as good resources. In such cases, the bad resources
can be identified by hash instead. Adding a hash output to
resource_info will make it easy for users to provide the hash of
questionable resources inside of resource bundles that we do not
have access to.
Refs Trac#9797.
|
|
|
|
When a game deletes a script and then loads the same script again
before it has been fully deallocated,
SegManager::instantiateScript tries to reuse the same script
& locals segments, but it was failing to reuse the old locals
segment because Script::freeScript would unconditionally clear
the old locals SegmentId, which meant the old locals segment would
just leak.
This patch does not fix old save games which may contain orphaned
locals segments, but should prevent the problem from occurring
going forward. (It is possible to clean up these old save games,
but this is not a big leak so it doesn't seem worth the extra
effort to do so.)
|
|
This situation occurs rarely, but normally, when unreachable but
not yet GC'd objects use a superclass which has already been GC'd.
Thanks to @wjp for looking at this with me and clarifying what
was going on.
|
|
|
|
See code comment in Object::init for more details.
Fixes Trac#9780.
|
|
This groundwork enables an object to look up its static name
separately from the normal process that is used to populate
Object::_variables when an object is first constructed.
(The static name property needs to be able to be retrieved from
objects inside of earlier save games whose name properties may
have already been modified at runtime, so the code cannot simply
pluck the value out of Object::_variables when they are first
initialised and then persisted into the save game, as nice and
easy as that would have been.)
This commit also helps to clarify the situation with relocation
tables in SCI1 games that start with a zero entry.
Refs Trac#9780.
|
|
While extremely rare (only Rama script 64948 seems to have this
profile), it *is* possible for an object to have zero properties
(and thus, zero property offsets).
|
|
|
