I'll test out the new things today :) 

how do hint brushes work? do you literally just texture a brush in a texture named 'hint'? or are they func_hint? didn't see anything in the readme 

Yeah, just a texture named hint. I'll add something to the docs for that.

I need to double check, but as I understand it, skip means something different in Q2/Q3 (just a face that gets removed completely) and "caulk" is what we have been using as skip.

Should I make "caulk" to replace skip, make "skip" like the Q2/Q3 skip and add a command line option "-oldskip" so it can be backwards compatible? Hrm... 

That I finish this map... I have no idea how to optimise for Quake 1. I've just been throwing brushes all over with now consideration for how to make it run quick. (it's starting to slow down DirectQ, not fitzquake though).. 

I need to double check, but as I understand it, skip means something different in Q2/Q3 (just a face that gets removed completely) and "caulk" is what we have been using as skip.

So, currently "skip" in your tools is a face that gets removed once the bsp has been compiled. Skip in the Q2/Q3 sense would remove the face at an earlier stage - at what stage can this be done in quake bsp without breaking the compilation process and what would the uses of it be? 

That's me question too. Ideally, it would be best not to change the names of the commands this late. 

hmm... that is weird yeah, because q1 skip is 'solid nodraw' like caulk and skip in the q2/q3 sense was 'nonsolid nodraw' to be used with hint brushes.

a fine mess this has caused! 

Unless I'm mistaken then wasn't the only use of q2/q3 skip to flag all the non-hint faces of hint brushes?

If that is true, then it strikes me as redundant because I would have thought the better thing to do in that case would be to just detect if the brush has any hint face on it, flagging it as a "hint brush", and then just ignoring that brush for the purposes of building the bsp (except when using the hint face to create the splitting planes). In that case, the non-hint faces aren't used anyway, and therefore don't need explicitly flagging as skip.

Is there another usage of q2/q3 skip that i'm missing? 

Tyrann, you have earned 1000 of my finest golden manbabies for that recent update.

Still can't believe after all these years we've suddenly got a new suite of awesome, actively developing compile tools. 

what I think makes q2/q3 skip mostly redundant is that I believe 'trigger' does basically the same thing: nodraw, nonsolid, doesn't cut bsp faces. if hint and trigger play nicely in q1 (I haven't tested) I suggest we just do that. 

trigger don't do shit in q1. 

Ok, I don't think I'll mess with the skip convention now (all my fault!)

I might just make caulk also work the same and then add hintskip to be used as the non-hint faces of hint brushes. 

In my WIP map, it's pretty good for my moving platforms/doors... are you still working on phong shading?
Also, is the switch for func_group just -group? Is it supposed to work for brushes? 

No special switches needed for func_group - the brushes are automatically compiled into the worldspawn model.

I don't suppose there's any call for a "-nogroup" option? I couldn't think of a good reason. 

IIRC, a couple years back I found a weird tool-related phenomenon. I studied maps in engines that support locking the PVS to see how effective the culling was (some of my RMQ maps were pretty heavy and I was looking to optimize the vis blocking).

I remember comparing maps compiled from several different tools, and a few of them definitely had more effective culling than others.

Can't remember the exact differences (tools tested were at least hmap2, Tryutils and AguirRe's tools), but it's worth doing a test like that. You might be surprised.

Not sure how much use hint is in Q1bsp tbh - don't q1 tools generate more portals/better culling than eg q3map2 anyway? It seemed that way when I recently tested q1bsp vs q3bsp of my converted maps in an engine that supports both. The performance of the q1bsp versions was a lot better, while I had to manually insert hint portals into the q3bsp versions to make them run equally fast. 

I thought I was doing something wrong again (and I was, but it was a whole different kind of wrong!), not much of my hair left to pull out now! 

Is there any other way of setting light attenuation/fade than using wait and delay? I'd much rather use these two things for wait/delay than to set the radius etc for the lights.

For example, I have a button on my map that when activated moves a lift downwards (that has lights on it), by timing it correctly I could simulate the light source moving downwards and then going back upwards. However because the settings are tied to wait/delay it doesn't work properly... Does this make sense? 

I made a video showing what I mean... If you changed the name of the delay/wait to something else I could actually use delay/wait to make the light reappear when the platform returns, thus simulating a kind of real-time light effect. -

http://www.youtube.com/watch?v=MdvsJmjJw74 

Do those keys even work that way on lights?

Another way to do it is to trigger via a trigger_relay and set the delay on that instead. 

trigger_multiple to trigger both the platform AND the lights.

I'm pretty much a newb when it comes to the more advanced triggers so I don't know if the delay/wait was used for attenuation for some technical reason, I thought it was kind of strange.

I'll try and figure out how to make the trigger_relay do what I need it to do. 

The use of the wait key started with Argh!lite many moons ago. At the time I don't think the community realised that any key starting with an underscore would be ignored by the engine, so we tried to grab existing keys that were unused for lights to avoid engine warnings. 

only works if I could allow the trigger_multiple to trigger multiple targets (ironically).
So it could trigger the platform & the trigger_relay, then the trigger relay resets the light (but NOT the platform as it has a different name)...

I just tested it and the trigger relay ends up infinitely resetting the platform/lights. 

Ok after a bit of web research it looks like I'm right in thinking that it wont work without multiple targets. Although RMQ seems to support this feature...
http://kneedeepinthedoomed.wordpress.com/rmq-mapping-guide/

".target2, .target3� : Multiple targets

As in Quoth and Custents, you can trigger more than one target now with a single trigger. You can have up to six targets and two killtargets."

Bah, I was going to make a quoth version anyway at some point... I suppose I could make a "plain" version for standard quake for the time being. ;) 

RMQ (and Quoth and Custents) are mods which is why you get additional functionality.

Since this is your first Q1 map (?) I would caution you to stick to normal quake until you get comfortable with how entities and the engine interact.

Or jump right in... my first release was a mod. It sucked though, so not a great example. 

I'm a serial offender for not finishing maps... though I usually run out of steam/patience about now but TrenchBroom is continuing to be enjoyable.
My first actual level for Quake 1 was a trench-warfare style map I made in the 90's with an editor called Thred. It really sucked hard.

I'll make two versions, one for quake and one for the quoth mod. I thought of some really cool scripted ideas last night that I could set up with the relays.