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. 

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.