[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [game-data-packager] Optional licenses

Le jeudi 7 janvier 2016, 09:03:07 Stephen Kitt a écrit :
> But when preparing updates to the YAML files,
> I like to ensure the new description is complete and
> self-sufficient

Indeed, it's hard to get the balance right between usefull
information and noise.

What is needed ?
Hashes of original .exe's ? (now kept in raw make-template output)
Running "strings x.exe | grep -i version" ?
Barcode of the CD boxes ?
Photo of original media ?
Addresses & dates in the original license files ?

That also shouldn't make people afraid of providing game info.


We have already done that right one year ago for Wolf3D.

There's even more info in Joe Siegler interview here;

and yet extra clarifications here:

But, this is only a reference needed to build the yaml definition;
that shouldn't end-up as is in the yaml as-is.

If that kind of information is really usefull for end-users
it should end in /usr/share/doc/ of generated .deb.

> *and* tries to only pick a single set of resources; otherwise I often end up
> with a generated .deb which works but picked things up from 
> a bunch of different places 

In development mode you should consider using --no-search
to disable all automatic file detection.

> (in this particular instance I was bitten by old forgotten
> installations in /usr/local/share/scummvm).

Yes, iter_extra_paths() will automagically find games listed in ~/.scummvmrc
those being in /usr/local , /home/... or even /mnt/windows/ .

> The features which are great for end-users make it harder
> to be 100% sure a set of asset descriptions is accurate...

There's for example the latest Doom version where the Red Cross
symbol has been replaced by a pill symbol...

Should that end-up in the game long-description maybe ?

But for Cruise what would that mean for a normal user:
"you have the game with an XOR-ed version of digtxt.res" ?

> > We're trying to identify the different versions in the most accurate way;
> > instead of having "GOG's version", "Simon's version", "Fabian's version".
> Indeed. "GOG's version" would make sense in some cases perhaps

GOG is not an absolute reference, they sell some versions tagged by Scummvm as cracked. 
and rely on end-users to provide rare dubs they can't find themselves.

Steam also sold for a while the 1.0 version of Blake Stone instead of latest one.

So only thrustworthy reference is the original media
or engine maitainers that know the games closely.

> ... should really end up being "Kixx release" or "LucasArts
> Classics Collection French CD" or something like that... Unfortunately this
> tends to not be well documented. Should we start systematically adding
> provenance to the checksums we add?

Maybe doing it "just-in-time" when a different version comes up ?
I'll go back in my CD pile to see if I find someting usefull to add.

> One thing I noticed when preparing these updates is that we can't use the
> checksums we have in g-d-p to cross-reference releases documented in ScummVM;
> they limit their checksums to the first 5000 bytes by default.

Yes, it's much worse, sometimes 5000, or 1024 or 4096 or 512 or 1024 * 1024.
And it's only the hashes of an handfull of key files.


The size in bytes can be a hint though.

Some ScummVM users complained and said they wanted a reference
with hashes on the whole files & sev (project lead) agreed
that it would be nice but "nobody has the time/will for that" :-)



Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: