Bug#869630: game-data-packager: Please add support for Heroes of Might and Magic III

[Simon McVittie]

On Tue, 25 Jul 2017 at 20:47:01 +0200, Johannes Schauer wrote:
> Quoting Simon McVittie (2017-07-25 09:01:45)
> > If there are files in "$dest_dir" that are edited at runtime, we will also
> > need to know which ones (compare the clean "$dest_dir" with the one you moved
> > out of the way). If there are files that you know are not strictly required
> > (the music?) we would also like to know about those.
> 
> I understand that g-d-p does not want to package files that are not needed at
> all but why does it need to know about optional "nice to have" files as well?

Sorry, I might have been unclear. The piece of information we really
want is: of the files you listed, which ones do you know to be optional?

g-d-p is aware of four categories of files: known and required;
known and optional; known and unwanted (rare, mostly only used for
known-to-be-obsolete versions of data files); and unknown/unwanted
(it will issue a warning if the unknown file resembles a known file
but doesn't match exactly, on the assumption that it might be a new
version that we need to be told about).

If a required file is missing, g-d-p will fail to create a package (but
it might automatically package a demo/shareware/cut-down version
instead, and it might still package the base game if the file was only
required for an expansion like Quake III Team Arena). If an optional
file is missing, g-d-p will still create the package (with less content!)
- we are not dogmatic about these packages being deterministic, because
that's a losing battle when some games have trivially-different versions
of the same file, like the subtle differences between different releases
of Unreal and the many equivalent versions of Doom.

Typically, optional files are used for things like READMEs and licenses,
which might be different or absent in some releases. If an identifiable
group of files are all optional (like maybe the music in HoMM3) we tend
to split it out into an "expansion" package, which is a separate binary
package. Each YAML file in data/ is analogous to a dpkg source package,
and can produce multiple binary packages if it needs to.

> > If there are several alternative versions of HoMM3, we will need similar
> > information for each one. If you have the GOG version but not the CD version,
> > or vice versa, then different people can submit the two sets of sizes and
> > hashes.
> 
> I own it on GOG and I have the CD version. But since the CD version is with my
> parents it will have to wait until I visit them again.

There's no urgency, but when you get a chance, it would be nice to
confirm what's in it.

> vcmi is already able to decode the original mp3 just fine. Converting the audio
> with the vcmibuilder script is also completely optional.

Then I think it'll keep things simple for g-d-p to be completely unaware
of the Vorbis versions, and have the MP3s in its data (flagged as
optional or separated into a heroes3-music package if desired).

> > Finally, vcmibuilder puts the data files in ~/.local/share/vcmi, but
> > game-data-packager produces .deb files which need to install in /usr. If vcmi
> > follows the XDG Base Directory specification correctly, it should also
> > recognise these files in /usr/share/vcmi.
> 
> There is an upstream bug about it http://bugs.vcmi.eu/view.php?id=2189 and a
> bug in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783030

Ah, I see it already looks in /usr/share/vcmi (which we can work with)
but Alexandre would prefer /usr/share/games/vcmi. I'm personally less
convinced by the usefulness of the /usr/share{,/games} split than
Alexandre is, but I can see the reasoning for wanting to separate it.

I'm a little surprised vcmi doesn't have an equivalent of the Quake
engine's -basedir option. That would perhaps be useful if you want to
support side-by-side installation of the demo and the full game.

    S