spicyjack

What fabian said. Mesa in version 7.5 removed all of the old drivers (3dfx/Matrox/older ATI cards) and switched to a new driver framework (Gallium) for the cards that they still do support (newer ATI/NVidia/VMware/Intel), so if you have version 7.x or 8.x of the Mesa 3D libs in your distro, expect some things to be broken. Debian Wheezy (7.x) comes with Mesa version 8.0.5, and the ATI drivers in that version work in software render mode only, but the NVidia drivers are hardware accelerated. Like you said, you're probably going to have to wait until your distro updates, since they are the ones doing all of the testing of combinations of Linux kernel + X + Mesa. Or you can compile latest Mesa and be your own guinea pig ;) List of currently supported cards in Mesa: http://mesa3d.sourceforge.net/systems.html

It's actually sort of already been done before, in the Ultimart.... For those of you scratching your head, the movie is Grosse Point Blank (Wikipedia) with John Cusack, Dan Aykroyd, and Minnie Driver.

Nope, that's close enough. Calculating runtime statistics... - Total files found in archive: 34738 - Total size of files in archive: 33.16G - Total files currently in /newstuff directory: 58

Yeah, the file paths are not shown because I'm still working on the bits that cross-correlate between the two databases I'm using, a local copy of /idgames database info as queried using the API, and a database of WAD information I'm generating using scripts that touch all of the files in an unofficial mirror I have of /idgames. FWIW, my unofficial mirror of /idgames is at: http://phobos.xaoc.org/ Please to be exercising my bandwidth quota. It's updated every 12 hours, and anyone is free to abuse^H^H^H^H^Hdownload from it. If I don't hit any snags, at some point, I would like ask Ty to become an official mirror.

!!BEGIN DISCLAIMER!! This is old data, from the beginning of February, prior to Ty's purges. !!END DISCLAIMER!! sqlite> SELECT filename, size FROM wads ORDER BY size DESC LIMIT 20; filename size bbfourty.wad 448402705 Damnation.wad 256445935 DVII-1i.wad 177678822 vg.wad 161965805 action2.wad 143208125 rod2.wad 126580515 DOOM80.wad 121200022 CIF3.wad 112680042 chemdept.wad 104857600 Tartaru3.wad 98724881 UACMN2.wad 95408720 3057hub1.wad 89378569 AVGNDOOM.wad 82540404 mangskin.wad 78205429 SCmusic.wad 74362635 dimxmus.wad 72589848 cchest4.wad 72442794 NDCP2.wad 69450467 2MusVids.wad 67907838 NeoDoom.wad 66536230 This data is from a set of WAD|/idgames tools that I'm working on, things like syncing /idgames, and going inside of zip files and figuring out what's there. Note that my tools don't handle *.pk3 files yet, that's on the TODO list. Edit: made the disclaimer stand out a bit more. Does vB code have [blink] tags?

There are tools to dump wikis. A quick Google got me: https://code.google.com/p/wikiteam/ When I helped migrate the Doom Wiki from Wikia to manc's server, the tool that someone said worked was MediaWikiDumper, so that's what I got to work. I was able to get a dump of all of the pages and the images from Wikia into a database for the pages, and into a directory structure for images. At the time I did the dump, it was about 400M of stuff. MediaWikiDumper has morphed into http://www.mediawiki.org/wiki/Manual:Grabbers, if you wanted to go that route.

Doom IRL. These are outside my office building. Every time I see them, I think of TLMP, or maybe a cross between TLMP and COLU.

I went through all of the API entries again, both in XML and JSON, and they both parsed out fine. Thanks for all of the fixes.

Colin Phipps did a wad2svg script in Perl, he has it on his doombsp project page on Sourceforge; Homepage: http://doombsp.sourceforge.net/wad2svg/ Tarball: http://sourceforge.net/projects/doombsp/files/wad2svg/0.1/wad2svg-0.1.tar.gz The only bad part about the script is that it's dirt old, I don't think it's been updated since about 2002 or so. I did a few tests with it, if you want to see what it outputs. Here's the example SVG that's listed on his page (125Kb); http://doom.spicyjack.com/pix/example.svg Not sure why Chrome won't render this as an SVG in the browser for me. Here's a try at rendering Mek Velapax... WARNING: this SVG file is about 5.7M, you might want to download it first, then open it up in a dedicated SVG program like Inkscape or Adobe Illustrator... it takes Chrome forever to render it. http://doom.spicyjack.com/pix/mek-velapax-beta1.svg The SVG Perl module should be available on any modern Linux system as a package that you can install, for example, on Debian/Ubuntu, the package is named libsvg-perl. It may also installable on Strawberry Perl for Windows via cpanm.

I vote for an API version bump because of the change in API version attribute from a stringy-quasi-float to an integer. That way, no apologies would be required ;) Also, a changelog of all of these changes somewhere on the API page itself would be awesome, so people who work with the API can match API versions to different functionality in the API. Maybe list all of the changes, major and minor, but major changes (where the behavior of the API changed) get highlighted in a different color? I'll go through all of the files via JSON API requests again in the next few days to verify they can be parsed by my parser, and will update this thread when I'm done.

Can it be replaced with some kind of URL shortening service then? A read-only by end user service that can generate the same URL every time, and not just to /idgames, but to the shovelware CDs stored on archive.org for example, in case someone actually does go through them and catalog them at some point. Or any other 3rd party site with WADs. There was another thread where someone had a giant list of sites they were going through and downloading. For URL shortening, I was thinking something along the lines of generating a checksum from domain + path + filename, turn that in to base32, and the first files indexed get the shortest URLs possible, longer URLs are generated from the hashes that are generated in order to prevent hash collisions. For /idgames files, use fullsort.gz, to generate URLs from oldest file to newest. Edit: added mention of fullsort.gz for determining order for indexing of /idgames

No, sorry, my question was for using the idgames:// URL syntax with a file ID, for example, idgames://12345. If file IDs can change in the future, what's the point of referring to files by file ID in an idgames:// URL? Will you get some kind of redirect to another idgames:// URL if the file ID changes at a later date, or ???

Does that mean that using an idgames://<file ID> URL to refer to a file shouldn't be relied on as well?

Only if you use the server for all searches. If you have a copy of the data, or even a subset of the data, then you can "solve" that problem however you want.

The issues I found would make excellent test cases for whatever implementation you decide to work out ;) As floating point values, if your version is currently 1.9, and you bump to 1.10, the trailing 0 may^H^H^Hmost likely will get truncated, making the resulting version 1.1. Same thing when moving between 1.99 and 1.100. The extra trailing zeros at the end of a floating point number are unnecessary, and most likely would be stripped whenever the first math operation took place, depending on the implementation of the math library. If the version was a string, then to the computer, all of the digits are important, and they would never be purposely stripped off. No rush on the fixes, I'm currently using the XML for everything, this is more for people who write things in the future and want to consume the JSON.