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. 

Please make the utils output a trailing newline! Borking the terminal is annoying. 

Might be the marksurfaces maybe?

$ wine bjp\ May\ 2006/Bspinfo.exe -prt cda.bsp
---- BspInfo 1.27 ---- Modified by Bengt Jardrup

cda.bsp
10439 planes 208780
33815 vertexes 405780
13782 nodes 330768
12871 texinfo 514840
26848 faces 536960
27641 clipnodes 221128
7878 leafs 220584
35183 marksurfaces 70366
119544 surfedges 478176
63331 edges 253324
137 models 8768
138 textures 1667656
lightdata 835596
visdata 1380694
entdata 71148

WARNING: Marksurfaces 35183 exceed normal engine max 32767
5238 vis leafs
18510 vis portals

$ vis cda.bsp
---- vis / TyrUtils v0.6-5-gd6ef234 ----
running with 4 threads
BSP is version 29
5238 leafs
18510 portals
Calculating Base Vis:
0....1....2....3....4....5....6....7....8....9....
Calculating Full Vis:
0..************ ERROR ************
\
CheckStack: leaf recursion 

base vis finished without problems of course, stupid func 

Could you support the -noambient, -noambientwater, -noambientslime, -noambientlava switches?

These remove the markers that get applied to visibility areas that cause quake to play the sky and water looping sounds. 

I had done a small map using textures from Sock's website. Totally too much detail for vis.exe. Now with func_detail it works. vis in 135 seconds! Looks good, texture alignment stayed correct.

Gone are the days of poorly lit func_wall for details.

http://www.quaketastic.com/upload/files/screen_shots/lod.jpg

Tyrann Thank you

I'm sure your tools will cause more work for everyone with a WIP map. 

I haven't had to chance to really see func_detail in action yet, but your shot shows it off well (or rather doesn't show) since I can't tell what's detail and what's world. :) 

Spirit: Thanks, I'll try to reproduce the error tomorrow and fix.

necros: sure, will look into that.

mechtech: looks nice! 

Textured normal
http://www.quaketastic.com/upload/files/screen_shots/detail1.jpg

Shows what I used as func_detail
http://www.quaketastic.com/upload/files/screen_shots/detail2.jpg

Vis on this room would be useless. func_detail lets the mapper choose to not vis areas that are not occluded. 

"It's very pretty, Bishop, but what are we looking for?" 

Hi Tyrann! Thanks for putting the new version together with map 220 format support. I've tested the scheme I outlined for creating a solid, invisible window and it does work!

Unfortunately I have generated another feature request in the process...the Hammer editor works with a different wad format at the same time as map 220 - basically so it can have full colour wad files. So when I go to compile my map, it can't use any of the wads. My cunning plan to use a batch file to swap the wads for Q1 format ones didn't work - Hammer locks those files while running. So I am reduced to begging for more features, sorry to say. 

@Preach: didn't seem too difficult; care to try out this snapshot and let me know if it's okay? (I don't have any such files handy)

http://disenchant.net/utils/snapshot/tyrutils-0.6-23-g3676261-win32.zip 

@Spirit: BJP tools have the same problem with this generated .PRT file, except the BJP defaults to "-level 4", where I default to "-level 1". I suspect it's just a bad bsp->prt conversion job.

I wonder if you were specifying "-level 4" earlier when benchmarking, because that could explain those differences too.

I should probably default to -level 4 too. Any objections? 

Aren't level 1 to 3 mostly broken? 

i could swear it said level 4 when I ran it without arguments. will check later. 

I think the -level thing may be numbered wrong.
-level 4 takes 95 seconds. -level 1 was nearing an hour before I quit. I checked the .prt file and found the prt2 header.

my original test was done on -level 4 so maybe func_detail isn't the fix I thought it was.

Maybe I did something wrong checking.... 

On some occassions, level 1 can take longer than level 4 indeed. 

 

I'm having the same issue with Hammer 3.3. When I compile using your qbsp the editor spits out an error message saying that the wad is not a wad file and the level compiles with no textures at all. However when I use another BSP tool (TXqbsp) the problem goes away and all is right in the world again (only with none of the extra features like detail brushes (which is why I switched over to your's in the first place.

The link to the snapshot above is borked so I can't try it.