kb1
Junior Member
Posts: 167
Registered: 11-06 |
DaniJ said:
Indeed. That was sort of the reasoning behind it...
Imagine being able to click a few buttons in an HTML form on /idgames which calculates the hash and then adds it to the database alongside the addon itself. It could be easily stored in a SQL database and the whole lot could be exported using a simple script.
Sounds reasonable. But, what would the download consist of? Option files as I am suggesting? A one-line-per-map CSV file with wad hashes duplicated for each map of a wad? Or map lump hashes?
DaniJ said:
I don't like the idea of matching on file name alone because you have no way to determine if its the correct info. Say I have two files named coolmod.wad, one is for DOOM while the other is for DOOM2. By matching filenames you pass the onus onto the user to ensure they pair up the metadata with the addon in a fine-grained organisational structure which separates them. I.e., I couldn't dump all compat metadata into one file/directory without having to implement further bookkeeping to associate addon paths with addon-metadata paths. With a hash you retain this option.
Yep, all valid points. For me personally, I stopped putting all wads in the same folder a long time ago, in fact I have one folder per wad which includes the .wad, .txt, .deh, etc., with the .zip discarded, so, for me adding a single file to each makes sense. But, there is definitely some value in having them all grouped together as a single, easily downloadable database/file.
There is strength in doing it both ways, and it all boils down to how the data is to be used:
Option 1. The option file stays with the wad, and a source port can use minimal code to load the corresponding file from the same path. In this case, "coolmod.wad" for Doom would have to be in a separate folder from "coolmod.wad" for Doom II. The option file would also specify "doom.wad" or "doom2.wad", which would be even more helpful.
If it seems important, the file *could* contain a hash that the source port/launcher uses as a overridable double-check. File can contain options that, possibly, some source ports don't understand, and thereby ignore, with a console warning if so equipped.
Option 2. The data for, say, all of idgames' wads exists in a, say, comma-delimited file, one-line per map per wad. Hashes could be maybe duplicated for each line for simplicity, and, possibly sorted alphabetically to allow binary search. A launcher program could match the wad hash with all corresponding lines in the CSV file, and then would have to devise a way to pass that config to the source port, if desired. Or, the source port can perform the wad hash and lookup itself. Custom/unusual options are more difficult to handle, but could be additional columns on the line.
Maybe I'm missing something, but to me, Option 2 is *a lot* more work, without buying you much. I'm not against having the hash included, but I think the matching filename idea gets you a lot of bang for the buck. It's only real drawback is that you carry another file along with the .wad, and the .txt, or the .zip. And, could be problematic if you like to place all .wads in the same folder (of course, each .wad would have a unique filename in that folder by definition, so that's not really an issue either.)
I do like the idea of being able to submit changes via checkboxes on an HTML form. Perhaps the options themselves can, in fact be stored via bits of an integer in the database. And, upon downloading the wad, the option file could be generated using those bits. Perhaps, also a hash could be included in the file as well.
It would be nice to not require the source port to compute hashs and look up entries in a file, or file folder - to me that's just not reasonable.
Why would you want to dump all the metadata in one folder anyway? (really, I'm curious). I suppose it could be a little difficult to place the option files if you've already downloaded the entire idgames archive and structure :)
|
09-01-11 22:03 
