Re: openrct2 & game-data-packager
> Le jeu. 7 déc. 2023 à 13:15, Mathias Gibbens <gibmat@debian.org> a écrit :
I try to answer everything into a logical order:
about the main game versus extensions:
We try to support the old - unpatched - CD someone
would find on a flea market or their parent's basement;
not only the fully patched GOG.com version
roller-coaster-tycoon2-data should provide
a minimum viable game without the extensions
that may not be available on CD1
roller-coaster-tycoon2-wacky-worlds-data
& roller-coaster-tycoon2-wacky-time-twister-data
are stubs for the expansions packs, on Debian & Debian-derived systems,
the "expansion_for:" will be turned into a "Depends:" relationship at build time
The main data packet will Depends: on the engine (openrct2)
data variation:
> I have the following RCT/RCT2 game sources I can test with:
> * GOG RCT2 Triple Thrill Pack exe v2.0.0.6
> * GOG RCT2 Triple Thrill Pack exe v2.01.043
That's great, hopefully the data difference would be only in unused .exe files
& unshield/innoextract archives.
If some graphical/sound/scenario assets have been changed,
thet can be handled by "alternatives:" tag.
If these are availble in a patch online that can be supported too.
----
about patches:
there are about 10 archive formats supported, but ...
https://www.patches-scrolls.de/patch/3481/7/49297/download
This one patch is not supported, unless someone wants to spend
days reverse-engeneering RTPatch. (non-free xdelta alike)
$ strings RCT2_EURO_V32.EXE | grep -i copy
"RTPatch Software Update System DLL version 6.50 (C) Copyright Pocket
Soft, Inc. 1994-2002. All Rights Reserved."
But someone can evaluate what it does with Wine
Or openrct2 can cope with unpatched assets too :-)
(scummvm does that for many games)
> How are variations of possible game sources handled?
Multiple versions of a same file name are handled with a "?" suffix,
this character being illegal on most filesystems,
it will never show up in the actual file name.
For example, morrowind.yaml support a lot of unshield archives:
934266 ecaf363400f177e3366e3819e8e1806d data1.cab?bloodmoon_goty
9731354 f96a09d4a63984a4d29e10c7b2ba4c59 data1.cab?fr
6810903 ec3802c2fc76d6e56ecbcd9abc8dda96 data1.cab?fr_construction_set
6740293 bc13a9d547eca346510fc471ecd60677 data1.cab?en_construction_set
9662742 5103b37a67672b2d3a44abf0d44574f7 data1.cab?en_goty
2028548 a163b5711f58e94753b8fd92dfff4eba data1.cab?tribunal_goty
9661851 60ee053dd29bd55f80b6131a09760a31 data1.cab?en_1.0
> I see there's a stub definition for splitting out the WW/TT expansion
> pack files into separate .debs; is there another game that does a
> similar thing that could be used as an example?
Yes, many games with "expansion_for:"
> OpenRCT2 can also directly import original RCT scenarios/tracks if
> people have the RCT installer(s) available. Since there's no game
> engine for just RCT, what would be the best way to build a .deb(s) for
> those game assets as well? Extending the RCT2 definition, or adding a
> separate one for RCT?
I think that roller-coaster-tycoon2.yaml will get really long
& overwhelming when this is dones so it's better
and cleaner to have a separate roller-coaster-tycoon.yaml.
compet-n.yaml is such game definition with a "expansion_for_ext:"
tag, that behaves like a hyperlink between two .yaml files.
core GDP will need to be adapted to gently inform end user
that RCT1 data without also owning RCT2 has no pratical use;
because they will end-up with with a .deb Dependings on
another one that is not installable.
(but GDP evolves organicaly with the data, so no problem)
Finally, another reason is that the .yaml name should match how
the general public know about the game, not be engine specific,
users want to play a game, they don't want to feed a specific engine.
In an idea sitatuation they should not even need to know what openrct2
is beforehand, it will get installed automatically with the assets.
Greetings,
MR welcome
And of course I could afford to spend 2x10€ on this game
but it's refreshing to get external input from time to time.
:-)
Reply to: