Quake One-Click Installer

I developed a tool to enable a One-Click install like is used for some games on GameBanana. This is an alternative to an Injector type program that will continue to drive traffic and hopefully encourage engagement on sites that provide Quake packages.

The link protocol is shown in the repo’s readme. I am open to supporting any site owner who wishes to use it. (wink wink)

Currently, it supports 3 types of well-formed packages. Planned for future releases are automatic installation of dependencies and a custom install option to massage non-well-formed packages.

Informational page here:
https://jjelliott.github.io/quake-one-click

Release here:

Very cool! I will definitely add support for that on the new site’s pages.

Looking through the database your three variants match what we got very well.

I think type and gamedir are a bit redundant though? One could just specify the directory to extract to:

  • Extract zip into quakedir/gamedir/ (where gamedir might be eg. id1, ad, wicked, copper)
  • Extract zip into quakedir/gamedir/maps/ (eg. id1/maps/, quoth/maps/, drake/maps/
  • Extract zip into quakedir directly

That’s basically what the zipbasedir in the current DB does. By simply specifying the target extraction base dir it would be possible to support much more than “just” maps and mods, e.g. skins, skyboxes, etc.

Do you see other uses of the separated parameters for more sophisticated file handling?

There are many files that are not packaged well though. For those I think we (as in people who care about nice installers) will have to find and agree on some sort of “list of included files and where they should go” format. I haven’t thought of anything to handle the more evil releases with zips inside zips or even random packages with other archive formats in them though. Is that kind of craziness also something you are interested in?

I plan to have a custom type that takes a set of commands for massaging non-well-formed packages. I have some ideas on what to do for it, I’ll reach out when I have a draft. Right now, the plan is a set of json objects that lay out an exact set of steps, but we’ll see how it evolves.

The “redundancy” eliminates the need for a commandline arg, by just supplying the gamedir I can use it for both extraction purposes and run purposes. I could try a more generic version but the gamedir would still need to be supplied to launch the game. That being said, if renaming something would make it clearer why something is required feel free to file an issue and we can work through that.

I did some work today to integrate this but stopped because on a second look it will only work for very specific kinds of files and that’s not really suitable for Quaddicted.

For example:

  • Some releases require multiple game dirs or a special commandline (e.g. -game quoth -game foo or -quoth) so I see no way around a dedicated parameter that includes that.
  • Some releases have multiple maps of equal “rank” without a dedicated start map, e. g. all those speed mapping packs.

Those a things that regardless of packaging will not work with the current design.

Sorry to be such a downer after my initial enthusiasm, I should have taken a closer look immediately.

The new site has an API where you can fetch a single package’s metadata easily, maybe that would be a good alternative vs stuffing lots of info into a single href? I’ll send you a link to check it out. Totally different kind of approach though so I understand if you prefer yours.

Yeah that seems like the best approach. It should be enough to have just a couple of verbs (like “move” or “extract”) and then have tools interpret those as necessary on the OS they run on.

So, if you’re interested in using this, I could provide a small amount of JS that you could embed to make a map-selection dropdown that functions like the Injector right on the review page.

Also, I plan to have support for command-line args by placing them at the end of the string. Since most command line arguments used in the current database (and just in general) are for just the -game parameter, I didn’t implement that yet.