http://i.imgur.com/2uX1W1g.png

Does anyone know how to get QS to run through the TB compiler? I tried using -game ad instead of +game ad but it just gave me an error about having the shareware version of the game (?!).

MarkV runs fine through this :( 

Your working directory needs to be where the engine is.

If Mark V starts with a working directory and can't find Quake there, it will check and see if Quake lives in the folder where the .exe is .. and use that as working directory instead. 

Baker that is a nice feature, it sounds like something QS should steal. 

Also, "couldn't load gfx.wad" has never been a helpful error message, that could be rewritten to suggest the most likely fixes. 

I have tried to get other engines to steal that for years. Tends to get dismissed out of hand as a non-problem. If Mark V actually does get the gfx.wad it very clearly says what is wrong, and then pops a message saying "Opening folder c:\path_to_engine ..." and opens the folder.

/Brief gentle tangent, .. hopefully not much disruptive to the TB thread 

I am officially taking Baker's side on this one, it's a serious pain having to use the game dir as your working directory... Especially because the compile tool doesn't have a working way to get the map's directory...

http://i.imgur.com/3i0nthn.png

I think I can use fully qualified names to avoid this, but it makes the parameters of my tools into even more of a mess than before...

Could someone tell me if i'm using ${MAP_DIR_PATH} wrong or something? I think this should probably have a github issue if it's genuinely broken. 

engine -basedir ${GAME_DIR_PATH} -window +map foo
or something.
(or +set fs_basedir foo for q2/q3)

some engines ignore -basedir. those engines are annoying.
an explicit path should always take precedence over a fallback/guess.

That said, default compile rules for TB would be really nice... it would save quite a bit of frustraction... at least until someone uses a path with spaces in it, anyway. 

Hehe

(I didn't have Spike in mind. He even has a different objection than I've seen before )

/@Spike - Mark V honors basedir and can handle paths with spaces in them like -basedir "Path to Quake". 

I've been pushing TB2 pretty hard this week especially using undo many more times than I would ordinarily do while mapping (a dozen or more steps back) and have had zero issues. Am I dreaming or did some of the default keyboard shortcut change or go away though? I think the only weird thing I've noticed was the transparency bug noted elsewhere on this thread and on Github. Amazing work guys. 

I never knew about this functionality in Hammer! 

I was able to make that work with QS, but only by using a fully-qualified path rather than the ${GAME_DIR_PATH} one you suggested. Did your suggestion work for you? Maybe there's something wrong with how my environment is set up. 

I remember someone setting up their preferred engine in one of the "Tool" slots in the compiler. Bit more intuitive, imo. 

That's what I've done. It's nice because it only takes one click to start the process and when it's done you're instantly in-game with your map.

It's less nice because of all the issues I've had trying to make it work with something that isn't MarkV. 

Pretty much the only reason I use JACK more. That and primitives.

All on Sleepwalkr's list I'd imagine. 

If you read this, please contact me. It's about your TofuQake (hehe). 

Tried to load the .map from The Hell That's Coming in TB2 today but it returned this error message and crashed:
Expected integer or decimal, but got '[' (raw data: '[') (line 15, column 96]

Is this worthy of a bug report or is it perhaps already reported? Note that I was still using RC1 in WinXP, will have to check in RC4 to see if it still happens. 

In the Open window select Map Format "Valve". 

...but it's a Quake level! And it doesn't happen with any other Quake map I've tried to load. Why is this happening? 

Because that map you are trying to load uses "Valve" texture mode. Most other dont/didnt until recently. 

 

I posted this on Github but thought I'd share for discussion.

I'm an video editor and in my editing software I can raise audio levels relative to each other. So if one track is -5dB and another is 5 I can raise them both simultaneously by 2 dB to make them -3 and 7. A real time saver when mixing audio. This gave me an idea for TB. It would be great to be able to select multiple lights and raise their values relatively as opposed to just absolute values. I'm not sure if this would apply to any other key/values. Nothing else comes to mind. It would be wonderful to tweak lighting in large areas in one operation. Just an idea!