Certainly it's not commonly downloaded, as it's brand new! That message really means "This file might be dangerous, on the evidence that it's not often downloaded" - there's no actual looking for malicious code before the warning is displayed. You can open it up in a text editor to check first, all it's doing is searching for a few quake engines, copying one file, and running the engine that it found. 

It is always good to heard about an update to Quoth, and the launcher looks good to have things tidy. Thank you!

Feedback: so far i have tried it with e1mquotha and hrimsp3 in Quakespasm 0.58.7 in Windows xP sp2. No bugs so far, but i encountered one thing that i don't know how to classify.

I get a ''method compression not valid'' error with 7zip and with Winzip when decompressing the .pk3 file. No issues with the text file or if i use the zip extractor that comes with windows or others. 

It's not a pk3, it's a pak file. They're the more primitive version that Quake support. It's entirely uncompressed, but you can open them and fiddle about if you download Pak Explorer from http://www.quaketerminus.com/tools.shtml 

I have been working with Darkplaces lately.

About my last post, I was referring about when extracting the .pak file from the zip.

Good to know of another tools to open .pak files. I always used Quark for that. Thanks. 

That's funny, I just used Windows to make the zips. I did re-add the pak files after making some changes, so I suppose either:

a) Windows does some non-standard stuff when it replaces files in zips
or
b) Windows does something unusual but within the zip spec, and it throws 7zip and winzip for a loop 

Thanks! 

Keep those reports coming in, each confirmation it works takes the patch a little bit closer to release... 

I've repacked the uploads to hopefully fix those compression errors and update the text file instructions.

PLUS
Distrans has offered dis_sp6 for use with the launcher, so you can grab the package from here:
dis_sp6 

I didn't tested it yet, but I am going to do it soon... so far i am already honored to see my last 4 maps in the pack: thanks a lot Preach :)
I'll provide feedback later, but I can't wait anymore for a Quoth update now. 

it works like a charm, thanks preach!
Launching custom pak files too. 

Cool!


A couple of bugs:

- Every time you use the EXIST test on a variable (which can contain some arbitrary path string), you need double quotes around the variable.

- I see a "GOTO PakError" in the batch file, but no PakError target.


A few quirks:

- I noticed a comment about "First we check the engine specified at the top of this file", but I don't see any place earlier in the file that initializes the engine variable. Maybe this was a leftover comment from some earlier scheme?

- The batch file resets the video mode to 800x600 (with the "-width 800" option) unless I'm specifically pre-setting the engine var. I'd bet you have a good reason for this, but it makes the auto-engine-selection kind of unattractive. Can that be omitted when a "modern" engine is selected?


And one last pie-in-the-sky thing: it would be great if I didn't have to manually extract the pak out of the zipfile. :-) I wonder if there's some way to use Window's native unzipper to deal with zipfiles. If not, you should probably specifically recognize the error case when someone drags a zipfile onto the launcher, and give them some instructions in an error message... as things stand right now it will just start the engine and fail to find the map. 

Actually let me get a little more specific about the quoting thing.

I was dragging the pak file from a location under my home directory, so that path had a space in it. I needed to change this bit of the batch file:

REM We might have been called with a command line to a non-existent pak
IF NOT EXIST %~f1 (
GOTO Prelaunch
)

To be like this instead:

REM We might have been called with a command line to a non-existent pak
IF NOT EXIST "%~f1" (
GOTO Prelaunch
)

in order for the pak copy to be done correctly.

I thought that there was some other bit of the batch file that I also needed to quote-ify for the engine selection to work properly, but now that I go back and test/examine it again, that doesn't seem to be the case. Anyway it doesn't hurt to give the variables a look and quote any of them that could contain paths. For example maybe %~dp0 in the CD up near the top. It looks like most of the other EXIST tests aren't in trouble since they are just checking a filename. 

Thank you for taking such a thorough look at everything. Few quick replies:

re: -width 800, I think you're right. The intent was to help out people with GLQuake where the resolution can only be selected at launch time, but the option is applied too broadly. I'll move that to only the point where the glquake engine is selected.

re: "engine specified at the top of this file", that is a misleading comment, which I'll update to say "engine specified by environment variable". That's the mechanism that the pre-launcher from the FAQ uses. It's also a potential escape hatch for someone with a map that breaks lots of limits, and so needs a specific engine and command line parameters to run it. They can supply a pre-launcher that does all that with their pak.

re: Quoting, I'll go and update that. I've also added quotes around the first IF EXIST %engine% test, in case someone provides an absolute path to an engine containing spaces. Like you say, the other ones we get away with it because the filenames are hard coded.

re: Missing Pakfile error - yeah, that's a goof on my part. There used to be lots of complicated pak file juggling, and it was more error prone. When we cut all that stuff out, I took out the warning at the same time, so I'll restore that.

re: Auto-unzipping. There's appeal to the idea, but it doesn't look like there are any good ways to do it. All the "native" batch file solutions I can find involve running an extra VB script to use explorer through activex - yuck! This is only the first version of the launcher, so I'm inclined to keep the supported features list for v1 short but sweet, and have that idea in mind for a future version if a good implementation can be made. 

apart from not requiring java (and an internet connection) what would be a reason to use this launcher instead of the quake injector? 

I don't want to drown Spirit's question in my post-flood, so make sure not to miss that above, but I had one more thing to comment on.

About the Steam check that you have in there:

Among Steam Quake users who care enough to patch/mod/modernize their installation, the popular thing to use is something called the "Ultimate Quake Patch". This is an NSIS installer that puts DarkPlaces (unfortunately, a pretty old version of DP at this point) and soundtrack files into the Steam Quake directory. Specifically it replaces Steam's version of glquake.exe and winquake.exe with copies of the DarkPlaces executable, using those same filenames. (It overwrites the existing filenames so that DP will be launched through Steam whenever "Quake" or "GLQuake" is launched.)

So: among potential users of this batch file who are also Steam Quake users, probably a significant proportion of them have installed that "Ultimate Quake Patch". For those folks, the batch file will refuse to start Quake because it doesn't see darkplaces.exe, even though they actually are using DP.

Maybe there's some way to detect if DP is being used, other than looking for the executable filename. Or perhaps specifically a way to check whether the "Ultimate Quake Patch" is installed... registry entries, or some other files that it dumps into the Quake directory, or some characteristic of the "glquake.exe" file that shows it is actually DP. I dunno, haven't thought much more about that yet.

I was curious though about what issue the Steam check is meant to avoid. If this batch file did try to launch the Steam version of glquake.exe or winquake.exe with those command-line options, what bad thing would happen? 

apart from not requiring java (and an internet connection) what would be a reason to use this launcher instead of the quake injector?

It's a lightweight thing that comes as a pack-in, just an alternate way of making thing easier to use, and makes sure Quoth comes "with batteries included" in that regard. Quoth is in a bit of an unusual position, where you get a bunch of potentially conflicting content poured into a single mod directory, so making sure everyone who has the mod also has a means of keeping the content organised is helpful to the ecosystem.

The Ultimate Quake Patch...replaces Steam's version of glquake.exe and winquake.exe with copies of the DarkPlaces executable, using those same filenames.

Ok, that's useful information to know, thanks! I'll grab myself a copy and try to adapt the launcher to recognise this case. My initial thought is that if the two replacement exes are identical, then a reasonable heuristic would be to turn the steam flag back off if the glquake and winquake files are the exact same size. That should hopefully be future-proof.

I was curious though about what issue the Steam check is meant to avoid. If this batch file did try to launch the Steam version of glquake.exe or winquake.exe with those command-line options, what bad thing would happen?

Nothing that bad, it just doesn't work. The steam versions insist on being child processes of steam.exe, and if they detect they aren't, then they look for steam.exe and ask it to relaunch the engine. Unfortunately when they do so, they don't pass the rest of the command line they were called with, so quake launches, but without running the mod. 

We will show you how to install the required packages [...] to create a shortcut - Brought to you by Ubuntu, the user friendly distro. Nevertheless, the new version is uploaded to the link in the OP, with the fixes discussed above, plus support for linux users as well. Note that it's all still a single file, it's a polyglot bash/batch script*.

The linux launcher has been adapted to align with the corresponding OS philosophy better than a port of the windows launcher would. Specifically, it doesn't go to any effort trying to second-guess which engine you'd like to use. If you don't configure it, you're stuck with the default of quakespasm. One of the changes to both sides of the launcher is a renaming of the environment variables to quothengine and quothoptions - intended to be unique enough that you could set them globally.

* One of the interesting side effects of this is the line endings involved. The initial portion of the file has unix-style line endings, which give way to windows-style endings once the bash script exits. Many text editors will try to be helpful and unify the line endings one way or another - but this is probably unwise here. 

Tried the new one on Windows using preset quothengine and quothoptions environment vars. Works for me.

I tested it on apsp3, which BTW is damn cool and I don't think I've ever seen it before. Probably I missed out on several Quoth maps. :-( 

Speaking of Quoth and apsp3: I got punished for not finishing it in one sitting. When I loaded my savegame (in QuakeSpasm), the 3 runes I had were gone, so I can't progress.

I'm not sure if the rune loss is a QuakeSpasm or a Quoth thing, but I do have a specific Quoth question so this may be the best current thread for it:

I think in the base progs, impulse 11 gives a rune, but in Quoth 2 that doesn't appear to work. Has that function been changed? 

Actually impulse 11 may be doing its thing to muck with serverflags (judging from the savegame content), but I guess that's not what the progs use to determine which runes I'm holding. Neither is the items bitflag on my player entity.

FYI I guess, if this is a thing you cand and want to fix/address in the upcoming Quoth release. I'm noclipping ahead... 

I've just been messing about with the runes in the standard quake maps - if I use the runecheat alias or impulse 11 three times, then collect the rune in e4m7, I get both bits of text when I exit the level - the usual plus the second one that tells you all four runes have been collected and you can go visit Shubby. It can be a bit difficult to keep track of what's going on in Quoth with runes because we use the hipnotic hud to display the extra powerups and weapons instead of the runes.

I think the thing with apsp3 is that although it tells you that you need x amount of runes to progress, the mechanism works a bit differently in practice. Than could probably confirm or deny this, but from what I've seen the level actually updates the breakables when you touch one of the runes in the level, rather than actually testing the player's serverflags. So impulse 11 doesn't help, it gives you the runes on paper, but doesn't trigger the events in the same way.

If you are stuck then there is something wrong though, can you upload the save game somewhere so I can take a look? 

So that does explain why impulse 11 didn't change my HUD's rune display or let me pass the blocks. At this point, if you told me I was just mis-remembering how many runes I had, I'd believe you. :-)

But if you do want to look at saves...

Here's one save which is the soonest one I have after the point where I noticed the issue. Unfortunately this isn't super-scientific because I manually edited the save to return the serverflags to 7 (to undo the results of a lot of "impulse 11" tests). And I actually don't know if serverflags really was 7 before I started impulsively impulse-ing. https://dl.dropboxusercontent.com/u/11690738/temp/s17.sav 

(And after finishing the map now I'm pretty sure that I just mis-remembered my rune count.) 

Getting away from runes for a bit: :-)

FYI it looks like there is a way to externally launch a Steam application with command-line arguments. The icky thing for Quake is: for games that have several different "variants" that can be launched, this method is only able to launch the first variant. So you can only start Steam's Winquake.exe this way... not GLQuake.exe or either of the QuakeWorld variants.

Just for testing though, I munged launch.bat a little so that it would generate this command line when I dragged a pak onto it (in this case e1m5quotha.pak):

C:\Games\Steam\Steam.exe -applaunch 2310 -hipnotic -game quoth +map e1m5quotha

"-applaunch 2310" is the special sauce there that runs Quake, and gives Quake the remaining options. The unmodified launch.bat can't quite generate this command line, because:

- If I include "-applaunch 2310" in quothengine, the EXIST check on %quothengine% fails.
- If I include "-applaunch 2310" in quothoptions, it doesn't get sent to Steam.exe as the first option (which is necessary).

But with a little re-arranging this works... launch.bat runs Steam's Winquake.exe with the desired options.

The bummer about this situation is that it can only launch Winquake.exe. Obviously you can replace Winquake.exe with whatever you want, and that's helpful for some groups of users, but not others.

Something to chew on maybe. 

Thanks for the info, that eliminates a major failing of the steam version! I think I might have to accommodate it differently though, because there's less freedom to choose the order of options than would allow for applaunch to always be first.

As an example, the randomiser code always prepends the map command to the supplied options. This is necessary so that if a user supplies a map command in the options, it overrides the one that the randomiser supplies. Conversely, -width specified for glquake at the bottom of the engine selection is appended, because first entry wins for that command line option, and again it ought to be user controllable.

So instead what I've done is rework the messy engine selection stuff at the end of the batch to incorporate this new feature. Now there's no error message path in the batch - instead if we detect steam then:
1. We check for the ultimate quake patch and use glquake if we think it's there
2. If not we set the engine to be "..\..\..steam.exe -applaunch 2310". Because we're already at past the engine checking step the problem with trying to do this manually is gone. This version is now uploaded.