[Scummvm-tracker] [ScummVM :: Bugs] #14737: SCUMM/HE: Blue's Birthday - Carrying over Red/Yellow CD savegames (fix included)
ScummVM :: Bugs
trac at scummvm.org
Mon Apr 1 10:51:57 UTC 2024
#14737: SCUMM/HE: Blue's Birthday - Carrying over Red/Yellow CD savegames (fix
included)
----------------------------+----------------------------------------
Reporter: fusefib | Owner: (none)
Type: feature request | Status: new
Priority: normal | Component: Engine: SCUMM
Version: | Resolution:
Keywords: | Game: Blue's Birthday Adventure
----------------------------+----------------------------------------
Description changed by fusefib:
Old description:
> ''Blue's Clues: Blue's Birthday Adventure'' is a two-CD game with four
> pathways, two on each disc. The original behavior is that savefiles are
> partially common for both CDs. In the original game, the following
> savefiles are generated:
> {{{
> (for Yellow CD)
> Blues1.nam
> [PlayerName1].bca
> [PlayerName1].sga
> [PlayerName1].sgb
> ...
> (for Red CD)
> Blues1.nam
> [PlayerName1].bca
> [PlayerName1].sgc
> [PlayerName1].sgd
> ...
> }}}
> ''Blues1.nam'' and ''[PlayerName1].bca'' are shared between the CDs and
> contain the game profile, i.e. sign-in information and overall game
> progress across e.g. minigames from all four pathways. The .sga to .sgd
> files are pathway-specific savefiles that get generated once you enter a
> pathway and the game saves progress. [PlayerName1] is whatever gets
> chosen.
>
> ScummVM generates the same type of savefiles, but its behavior is to add
> "[gameID]-" as a prefix to these savefiles, and to increment gameIDs (or
> targets) when adding what is considered ID-wise the same game. With the
> Yellow CD and Red CD being considered separate games with one default
> gameID, we get "**BluesBirthday-**" and "**BluesBirthday-1-**" as default
> savegame prefixes, thus:
> {{{
> BluesBirthday-Blues1.nam
> BluesBirthday-[PlayerName1].bca
> BluesBirthday-1-Blues1.nam
> BluesBirthday-1-[PlayerName1].bca
> }}}
>
> The result is needlessly getting separately loaded game profiles and
> progress by dint of ''not loading the same files'', when ScummVM would
> otherwise manage common savefiles for both game entries just fine.
>
> Here is a proposed fix to easily restore original functionality:
>
> [https://github.com/scummvm/scummvm/blob/98df6023f5699545770d30ee74f7b7ff9037b2d9/engines/scumm/he/script_v60he.cpp#L155
> /engines/scumm/he/script_v60he.cpp#L155]
>
> {{{
> // Prepend the target name
> filePath = _targetName + '-' + filePath;
> }}}
>
> ->
>
> {{{
> if (_game.id == GID_BIRTHDAYYELLOW || _game.id == GID_BIRTHDAYRED) {
> // Prepend generic name for shared game profile between targets
> // for Yellow CD and Red CD of Blue's Birthday Adventure
> filePath = "BluesBirthday-" + filePath;
> } else {
> // Prepend the target name
> filePath = _targetName + '-' + filePath;
> }
> }}}
>
> Per MD5s and detection entries, there is only one known Red version and
> Yellow version of the full game and demos don't create these files, so
> probably zero compatibility issues on that account.
>
> The prefix remains useful so users can distinguish these savegames among
> other ScummVM saves as well as partial overlap with the existing default
> naming.
>
> A minor drawback is the "BluesBirthday-1-" progress gets reset to zero,
> unless the user manually swaps the savesets which would still exist. I
> would say the drawback is minimal and the possibility of restoring game
> profiles by renaming can simply be documented in the game's Wiki entry.
>
> A seamless user experience fix might be to newly add a game configuration
> key by default (e.g. boolean "sharedsaves") when adding these games going
> forward, and to add a check for that configuration key in the code above.
> This way, (the other half of the) existing entries will continue to work
> with the current savegame naming convention and newer entries will have
> shared game sign-in and progress by default. However, this needlessly
> clutters the code.
New description:
''Blue's Clues: Blue's Birthday Adventure'' is a two-CD game with four
pathways, two on each disc. The original behavior is that savefiles are
partially common for both CDs. In the original game, the following
savefiles are generated:
{{{
(for Yellow CD)
Blues1.nam
[PlayerName1].bca
[PlayerName1].sga
[PlayerName1].sgb
...
(for Red CD)
Blues1.nam
[PlayerName1].bca
[PlayerName1].sgc
[PlayerName1].sgd
...
}}}
''Blues1.nam'' and ''[PlayerName1].bca'' are shared between the CDs and
contain the game profile, i.e. sign-in information and overall game
progress across e.g. minigames from all four pathways. The first has
name/color/birthday in INI-format (when uncompressed); the other is a
light, player-specific game progress file. When you create a sign-in
profile and proceed, both get generated. ''[PlayerName1]'' is whatever
gets chosen.
The ''.sga'' to ''.sgd'' files are pathway-specific savefiles that get
generated once you enter a pathway and the game saves progress.
ScummVM generates the same type of savefiles, albeit compressed, though
its behavior is to prefix the files with the game entry's **target**.
Targets get incremented if one adds, ID-wise, the same detected game
again. With the Yellow CD and Red CD being considered separate games with
one default `gameID`, in a typical scenario we get "**BluesBirthday-**"
and "**BluesBirthday-1-**" as default savegame prefixes, thus:
{{{
BluesBirthday-Blues1.nam
BluesBirthday-[PlayerName1].bca
BluesBirthday-1-Blues1.nam
BluesBirthday-1-[PlayerName1].bca
}}}
The result is needlessly getting separately loaded game profiles and
progress by dint of ''not loading the same files'', when ScummVM would
otherwise manage common savefiles for both game entries just fine.
Here is a proposed fix to easily restore original functionality:
[https://github.com/scummvm/scummvm/blob/98df6023f5699545770d30ee74f7b7ff9037b2d9/engines/scumm/he/script_v60he.cpp#L155
/engines/scumm/he/script_v60he.cpp#L155]
{{{
// Prepend the target name
filePath = _targetName + '-' + filePath;
}}}
->
{{{
if (_game.id == GID_BIRTHDAYYELLOW || _game.id == GID_BIRTHDAYRED) {
// Prepend generic name for shared game profile between targets
// for Yellow CD and Red CD of Blue's Birthday Adventure
filePath = "BluesBirthday-" + filePath;
} else {
// Prepend the target name
filePath = _targetName + '-' + filePath;
}
}}}
Per MD5s and detection entries, there is only one known Red version and
Yellow version of the full game and demos don't create these files, so
probably zero compatibility issues on that account.
The gameID-based prefix remains useful so users can distinguish these
savegames among other ScummVM saves as well as partial overlap with the
existing default naming.
A minor drawback is the other target's (e.g. "BluesBirthday-1") progress
gets reset to zero, unless the user manually swaps the savesets which
would still exist. But the inconvenience is minor.
--
--
Ticket URL: <https://bugs.scummvm.org/ticket/14737#comment:3>
ScummVM :: Bugs <https://bugs.scummvm.org>
ScummVM
More information about the Scummvm-tracker
mailing list