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; http://legacy.3drealms.com/tech/wolf3d.html and yet extra clarifications here: https://forums.3drealms.com/vb/showthread.php?t=20855 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. http://wiki.scummvm.org/index.php/Reporting_unknown_MD5_checksums 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" :-) Regards, Alexandre
Attachment:
signature.asc
Description: This is a digitally signed message part.