OK thanks that explains why setting detail doesn't work in BSP or Radiant. I guess the option is in the editors for Quake2 and higher.

So when I got a cemetery full of fancy gravestones, I make the gravestones funk_walls or func_illusionaries. The downside of this seems that the func_walls/illusionaries don't cast shadows... I've read you can built a simple solid brush in them to cast shadows.. but I wonder if I can just copy the complex/detailed architecture, duplicate it and turn it into invisible brushes that will speed things up and DO cast shadows... For instance, here's a tutorial once from a guy who used a sky brush to cast a Quake logo shadow on the ground...but I can't duplicate it:
http://bspquakeeditor.com/q1tutor/q_lights.html 

IMO the best way to do terrain in Quake1 bsp is to use triangular prisms. I use ones with a depth of 64 units. You just lay the triangles out as a mesh, then move the corners up or down to make a nice uneven surface.

Also - ALWAYS overlap brushes in Quake1 maps. I used to think it was bad, but it turns out that its actually one way of making sure an area is sealed, for starters.

And you dont get in-game z-fighting. But if you get z-fighting in your editor, the newest brush will win. After you have compiled the map, any parts of a newer brush which were visible in your editor will be visible in the bsp. But they wont flicker. 

Does z-fighting actually happen (in advanced engines) into brushes that intersect each-other, without any coplanar face? Such as overlapping perpendicular walls as generated by some hollowing commands in some editors... 

Man I shouldn't post at 3 in the morning, didn't see you were referring to quake 3, so ignore me :E 

hmm, okay. Off to give it a go :)

As I understand it then the main limitation with quake 1 BSP is that if a square face is twisted across where the polygon seam would be it just breaks? Like 3D modelling if you couldn't flip edges...? 

I quote a recent post :

Can anyone tell me what kind of triggers connections i have to do in order to make 4 buttons to trigger a door ? like if all are ON then the door should open .. if 1 is OFF the door shouldnt open (logical "AND" condition) i use the Quake 3 engine (GTK Radiant). Thanks in advance :)

I want to do the same thing in Quake 1, but a little different. The door should open at a combination of opened and closed buttons - some sort of cippher :)

Can that be done ?

Let's say you have 4 buttons - all closed. You push one - it remains open until you push it again - same for all. The door should open only if button 1 is opened, button 2 is closed, 3 closed, 4 opened (an example). 

But without new code it's a bit fiddly to set up.

Basically, you have a hidden tunnel somewhere outside the map which has four doors in it, a shootable button and a nail shooter.

The player never goes into the tunnel - you're just using it to set up a logic gate.

The four doors are controlled by your four buttons, and they're all 'toggle' so that the buttons can turn them to on or off states.

The button inside the tunnel is shootable (health 1) and is behind all the doors.

The spike shooter is at the opposite end, and just shoots forever.

The idea is that if the doors are in the right places then they'll allow a nail to go from the spike shooter into the shootable button, which triggers your event.

Problem is, there's no real way to show when a button is on/off - which is a must for the game play not to be confusing and frustrating. 

Also - ALWAYS overlap brushes in Quake1 maps.

ignore this 

Problem is, there's no real way to show when a button is on/off - which is a must for the game play not to be confusing and frustrating.

How about creating a little "indicator light" above the button; a func_door with a fullbright texture, that appears/disappears from inside another brush to indicate state. You can build a nice frame/socket around it so it looks like some kind of light fixture or computer terminal. 

Ok seems silly but i just found the solution for my problem :D seems silly but it works :

for only 2 buttons to trigger the Door i did this:
2 func_button each of them triggers a shooter_plasma which shots to a door(1). that door(1) opens and behind it there is another door(2) that opens my Door(3) .. that way i can have my Door(2) opened when both doors (1 AND 2) are opened
(some images for better understanding http://img411.imageshack.us/img411/7038/multipletriggersand1.jpg http://img688.imageshack.us/img688/9168/multipletriggersand2.jpg )
is there an easier way ? 

Could you not just make the buttons only trigger once (wait value of -1 iirc) and a trigger_counter with a count value of 2? 

That'll do nicely. 

in gtk radiant 1.5 for quake 3 engine i tried trigger_counter but it doesn't work aand if i put wait the value -1 it will do exactly what the manaul sais : "wait : number of seconds button stays pressed (default 1, -1 = return immediately)." 

So I'm dabbling with the dark arts and trying to make some rotating stuff, and I've got a nice door opening and closing but it's insanely jittery, as though the axis of rotation is bouncing up and down... Any idea what I've done wrong? :E 

sounds like one of two things:

you did not target an info_rotate with your rotate_object

or

your compiler does not support rotating entities (very unlikely at it would have to be a compiler made before the hipnotic mission pack came out).

so make sure you add in an info_rotate that should be placed somewhere in the center of your rotating brushes.
next, add a 'targetname' to it.
now, for all the rotate_objects applicable, add a 'target' that points to that info_rotate. 

hrrmph. At the moment I have a func_rotate_door targeting a rotate_object. The object is rotating around the rotate_door. I can't find an info_rotate in my entities list :/ 

Duh, I think I've worked it out. The rotate_object has to target back at the rotate door. Duuuh... 

you will need to create an entry for info_rotate if you don't have it.

rotate_objects don't rotate around info_rotates.
info_rotates are used explicitly in the bsp process to define the origin of the rotater, otherwise the rotater's origin is simply '0 0 0'.

try this: make a rotating door right on the '0 0 0' origin of the world and it will work perfectly without an info_rotate.

it has to do with quake's angle accuracy (or lack, thereof). as you know, the farther from the center of a rotation you are, the bigger the gap between one degree to the next.
quake has a pretty low resolution when it comes to angles, so once a bmodel is far away from the origin, rotating it makes it 'snap' to the next angle.
targetting object_rotate to an info_rotate tells qbsp to move the bmodel onto the origin with the info_rotate as the center. 

doh, cross-posted.

i guess that can work too. you're just replacing info_rotate with the func_rotate_door. the only hard coded thing in qbsp is object_rotate -> target. i don't think it cares what entity you target. 

Well...it seems to work okay anyhow :E

Another question however, train rotates. I've got it set up so an object moves between two points like a normal train, but -1 stops don't seem to work and it never rotates, it just moves. Any ideas...?

If you want an idea for what I'm trying to do, I want to make a draw bridge that drops down in stages (ie has multiple triggers, each one moving it x degrees down), rather than just going from 90 degrees to flat in one motion. ta for help btw this stuff is pretty confusing :p 

have you ticked the 'ANGLES' spawnflag on the path_rotates?

there is a 'bug' where a rotating train will not rotate if the next position is at the exact same spot.

if you have multiple path_rotates on the exact same spot, you will need to move the next one at least 1 unit away.
it's ok if it zig zags back and forth between only two spots, as long as two consecutive paths are not overlapping.

this is because if the origin doesn't change, the QC code just skips over the movement and considers it 'at the next spot' without bothering to check if it should rotate or not. 

first paragraph is a separate issue from the last 3 paragraphs. sorry for confusion. 

I was just about to post that it seemed to be that they were on top of each other... irritating limitation :( If I have them a single unit apart it fires the move but then instantly flicks back to the previous node. Seems to require a minimum of eight units between each.

Guess I'll have to just try and model it so it doesn't looks weird... 

Seems to require a minimum of eight units between each.
no, something else is causing that.
a single unit is enough to fix the bug i mentioned. you might have some settings wrong on the path_rotates. 

#10219 Quad Shadow

I have no tutorial for the Squad Shadow, but here is amap that shows the effect.

http://members.home.nl/gimli/Qshadow.jpg
http://members.home.nl/gimli/Qshadow.zip