Nice! I always wanted to make an API for Quaddicted, ok if I copy some of your scheme? I will only make that get request I think.

Allowing the Quake Injector to actually post comments and ratings is long on my wishlist, but I have not fully thought through how one would design the API for that on the remote server.

Thanks for the Injector love. :)
We envisioned it to be rather easy to make it support other games too but sadly the coder has not much time nowadays (and I am way too dumb to work on it myself). It would be extremely easy to just fork it for Doom/Quake games though, at least if Doom wads are packaged and installed and launched similarly. You guys have the benefit of having idgames being the one and only and stricly moderated repository for content. With Quake there was a gap when idgames2 "died" and people released their stuff all over the place, packaging their files in the worst ways imaginable.

Spirit said:
You guys have the benefit of having idgames being the one and only and stricly moderated repository for content. With Quake there was a gap when idgames2 "died" and people released their stuff all over the place, packaging their files in the worst ways imaginable.

I couldn't much agree. I am struggling searching for Quake 2 SP maps actually, with the longterm objective to make a Quake 2 Injector a reality. [Kona] helped me gathering maps from 1998 to 2001 but it appears a lot of maps are still released, lost in the tenfour forums with ephemeral links.

PS: I am the Kusanageek actually bothering you with bugs on the QI in Quaddicted forums hehe.

I am finishing up the first version (BETA) of the "idGames Assistant" and I need either: A) A decent icon for it, or B) Permission to use this cartoonish version of Hissy that I found at the wiki. The problem with B is that I can't find who made it, so I can't contact them for permission.

So, If anybody could fulfill either A or B, that would be great.

INCOMING SCREENSHOT/PLUG OF AN OLDER WAD I MADE:

To clarify, it will automatically figure out the game and port for you, but it still has trouble with some ports and can't detect when maps/wads need "limit removing" ports.

How does it handle mistakes such as an Ultimate Doom wad stuck in the Doom2 folder?

It searches for things like texture use, map entry names, music entries, graphic entries, sound entries, and line types to determine whether something is for Doom or Doom2, and doesn't rely on idGames's folder structure at all. It works for regular DOOM, Hexen, and UDMF-formatted maps. It generates some false positives with Wads that use another game's resources, but it isn't terribly common. If you believe that it guessed incorrectly, though, you can set it yourself on the screen. It sticks to whichever file was downloaded.

K!r4 said:
Wow, great job! Looks like being able to access the txt will be enough to figure out which sourceport is the best. Can we add command-line arguments before launching a wad?

Yup. It can be set by game-and-port, so DOOM and DOOM (vanilla) could have a potentially different set than DOOM and BOOM. I was thinking about adding a small wizard or dialog box for setting them on the settings dialog, but I decided that I could add it in a later version once everything written worked. You are not forced to use any particular executable when it finds the port, so you can still point it to ZDOOM for DOOM and BOOM, and set command-line options appropriately to limit it to Vanilla behavior, if applicable.

I'm also currently testing "Portable Mode" which will store paths to files as relative paths and store settings under the application directory for all users (or no specific user, depending on how you look at it). It normally stores settings under your user application directory, or Home in OSX and Linux. Also need to test the latter two. I have a distro of Linux, but OSX will be a problem, since I don't own a Mac.

GhostlyDeath said:
Looks pretty cool. Although shouldn't there be API to search for actual WADs to find the ID to actually use?

I know you could write something that uses the standard search but doing it with the API would be much cleaner and simpler to implement.

Yeah, it's in the works. Current plans at the moment are to stick a URL on the idGames pages near the FTP section ("idgames://14488" for the above file in the screenshot), but a richer tool will be made after the file handling stuff gets finished. Map statistics/diagrams will also be a thing that I plan on implementing client-side.

It requires at least Java 1.6.0 to run, and it will send you to a download page if you don't have it installed. So far, I'm supporting Windows but I'm testing this for Linux, as well. Obviously, you can't run the EXEs in Linux. Shell scripts or some other wrappers will be forthcoming, whenever.

Running the idgames-registry.exe file will bind the "idgames" protocol to the idgames-protocol.exe file in the same directory. Say "yes" when it asks if you REALLY want to merge the keys into the Windows registry. From then on, opening those "idgames://whatever" links will open in the assistant. Running idgames-protocol.exe by itself will ask for an id.

You may also want to run idgames-settings.exe to set up a bunch of additional options, such as primary FTP. You can actually edit/add FTPs to the list via the data/ftp.cfg file in the program directory.

You can also use idgames-portable.exe to set Portable Mode, which will save settings and all paths to files/directories to paths relative to the program directory. Just make sure you have permission to write to the directory (may not be an issue in Windows XP, but is in Vista, 7, and Linux or whatever).

So, which brave souls would like to step up? :)

Be mindful that this is a BETA; the next version may be incompatible with whatever settings you set, so don't get too attached to them.

If need be, I'll open a separate thread for this.

EDIT: Also to clarify some things -

Yes, this will run both WADs and PK3 files, and automatically load Dehacked patches, both DEH and BEX, should it find them in the ZIPs. It also understands DOOM/Hexen/UDMF map data.

Even though I can download them just fine from Florida through my browser.

HTTP code 403 is "Forbidden". I get the same thing when I try to download ANYTHING from Florida. It may discriminate against Agent types that it doesn't recognize (in this case, Java itself). Someone's going to have to talk to the owner of the mirror, or I'll have to eliminate it as an option.

EDIT: Similar thing happens for the HTTP flavor of Texas (MancuNet), but not the FTP.

DuckReconMajor said:
Then I switched to New York and it downloaded AV just fine but when I hit Play It! the window just disappeared and nothing happened.

What do your setup options look like for the selected game type and port? Is anything not set? There may be an error in my config detection.

EDIT: Or maybe, depending on the port that you are running, it ran, had an error itself, and then the assistant thought that it was a successful execution.

Without the download directory set, it may want to try to move the file downloaded to C:\, or the root drive of where it is installed. Not a huge issue for earlier versions of Windows, but Vista and 7 don't like programs without elevated privileges mucking around with the root of the system drive.

It may not be moving the file after it was downloaded, and may cause an error when the port launches. Try specifying a download directory like "C:\Doom\wads\doom", re-download the file (click the button, not just re-open it from idGames), and see if that makes a difference. The directory will get created if it doesn't exist.

EDIT: If that doesn't work, go to your application data folder:

[userdirectory]\AppData\Roaming\idGames\temp

And send me the cmdline.cfg file. The command line may be getting screwed up somehow.

EDIT2: Also, if it's not in Roaming, it may be in Local.

EDIT3: Just re-created it. Do NOT make your download directory C:\, either accidentally or on purpose!

It looks like the exception was caught in the AWT-EventQueue threads. I'll have to see how to make that propagate up or do some error logging. Great find!

Mista_T said:
Without the download directory set, it may want to try to move the file downloaded to C:\, or the root drive of where it is installed. Not a huge issue for earlier versions of Windows, but Vista and 7 don't like programs without elevated privileges mucking around with the root of the system drive.

It may not be moving the file after it was downloaded, and may cause an error when the port launches. Try specifying a download directory like "C:\Doom\wads\doom", re-download the file (click the button, not just re-open it from idGames), and see if that makes a difference. The directory will get created if it doesn't exist.

Installed new version and did this. It worked. Thanks. This is really cool. Thanks a bunch for making this!

I'm having some frustrations with changing settings, though. Under "Game Types," it seems that all five settings are stored per GameType+PortType combination, even though "EXE Path" and "Working Directory" only logically depend on Port Type and "IWAD Path" depends only on Game Type.

The net result of this is that I have to browse to my IWAD and EXE every single time, and the Settings app also does not remember the last saved directory (starting me in "My Documents" instead). With 56 possible combinations of GameType+PortType and 4 paths to set, that's 224 trips through my file system all the way to the Doom folder, which is not going to happen. It shouldn't be necessary to set some of these for every possible combination.

[EDIT] Changing "Game Type" resets "Port Type" back to the vanilla option as well, regardless of what was already selected. I guess it's not too bad considering it's a settings app that shouldn't have to be used more than once, ideally, but it makes selecting things a bit harder.

Also, my numeric estimate is a bit off since not every port supports every IWAD, but it's still in the hundreds.

I'm thinking that the download directory should be a part of Game Type, but it may cause conflicts if there are files with the same name that exist somewhere. Maybe I should just have one download directory and rename the files to their id numbers when I download and move them.

If you're talking about renaming the wad/zip names after downloading, definitely don't. That'd make them no longer human readable when browsing the filesystem. Different download directories for game type would work for me, mostly because that's how they're categorized in /idgames in the first place (/ports directory notwithstanding, which is a useless categorization nowadays).

The setting separation would definitely help, though. :)

[EDIT] While I'm thinking of it, it's probably worth adding Skulltag as a port type as well, since there's plenty of wads out there designed for it that regular ZDoom won't tolerate. Even though it's a multiplayer-centric port and Assistant is SP-oriented, that's not to say there's not SP wads out there.

Xaser said:
The net result of this is that I have to browse to my IWAD and EXE every single time, and the Settings app also does not remember the last saved directory (starting me in "My Documents" instead).

Yeah, is this a Java thing? I've had the same problem with other Java programs.

Anyway, I agree with the change to the game/port settings, makes things much easier, thank you.

When I'm opening up a file chooser, the default starting directory on the chooser is null, which Java Swing interprets as "home," unless the field has a file/directory in it, so I'm using that file's parent as the starting one. There is no such thing as "last saved" in Swing, so I'll have to see how I can fudge things cleanly to get this to do better.

In my Java applications I have a settings.xml file (in the home directory so it can be written to without admin privileges) that saves state information automatically on exit, like last saved path, window size and position, etc.

Yeah, I'll probably have to do something similar, but store it in the settings.db file that I use to store the rest of the info. Same permission space there.

On a side note, the setting storage method is the only reason why the download is so large at 3MB, since the SQLite libraries take up that much (it bundles shared objects into the JAR). I could try to write a different config storage, but SQLite is nice and atomic and better suited for periodic micro-transactions and bulk retrievals than dumping whole setting trees into XML or what-have-you.