now make a worm that's missing chunks from the threads, and wheels that are missing teeth to go with it! 

ah ok. i only posted that because i originally tried to make the worm gear out of textures too. but i swapped to a model because the spur gears looked funny meshing with a texture.

you could make a screw model though, that was just 6 sided (plus top and bottom, so ~20 tris?). it would make texturing the thread easier on a model skin maybe?

anyway, yeah, that worm gear is part of a new map/mod i'm working on. it's taking forever though, so no promises on release dates.

also, can i lobby for more lightmaps in quakespasm? maybe around 512 lightmaps or 1024? :D i built this whole terrain mountain as a sort of 'brush skybox' but had to remove it because i ran out of lightmaps, lol.

i think fitzquake's (and by extension, it's variants) current bumped limits could use some normalization.
for example, static entities has been increased, but ambient sounds has not, so you can add more torches than ambient sound slots which effectively acts as an artificial static entity limit.
or in this map i mentioned, it's possible to be under the faces/marksurface/vertex/clipnode limit, but run out of lightmaps.

now make a worm that's missing chunks from the threads, and wheels that are missing teeth to go with it!

maybe cause it's a lazy sunday afternooon, but i don't get it. what's good about gears with missing teeth? wouldn't they just stop working when they get to the broken part?
unless you mean like some sort of puzzle? 

subject: overlapping brushes

I know you shouldn't have those, but what about water? If I want to flood a building with water, it looks bad when I cut the water around pillars etc, cause you'll see those cuts in the moving water texture...

And architecture partly covered in snow? What is the best approach when you want one brush (snow or water) to partly cover up other brushes? 

What's wrong with overlapping brushes? 

I know you shouldn't have those

Wrong. 

water will be cut pretty badly no matter what method you use, so i tend to just cover up areas with a single water brush.

if you are using fitzquake, make sure you use r_oldwater 0. this makes the engine use a much better looking water. 

I thought you increase the chance of having Z-fighting (flickering) if one brush is contained in another brush (overlap).

Another reason I've read about is longer rendering times when you overlap brushes...

On top of this, I've seen multiple good mappers stressing NEVER to overlap brushes, including Pingu who stated in an interview to work neatly and that there's not a single overlapping brush in A2: Return To Atlantis.

I'm not pretending to know anything, but I do know what I've read. Kind of strange how people here say it's not bad to overlap brushes... Now I'm confused.

And Necros: thanks for the tip. Although that doesn't help people who play my map and use another engine ofcourse :)

BTW: are detail brushes used in Q1 (vs structural)? I'm using BSP Quake Editor right now, and there is an option to 'add detail' or 'remove detail' but after I selected and added the detail, it's not reported in the 'map info' (detail brushes: 0). I'll check in another editor as well.

I've read that if you got a lot of stuff in a room (like a bunch of candleholders, charis, tombstones, etc), it's best to turn those into detail brushes and let the main brushes that are suppoed to block Line Of Sight be structural... 

i don't know why, but overlapping brushes will cause zfighting in newer engines like q3 and d3. in quake, qbsp will manage to remove overlapping WORLD brushes without any issues. (overlapping func_ or other visible bmodels WILL cause zfighting with other bmodels or the world).
afaik, it doesn't cause any problems once the bsp is in the engine.

i'm not sure where we are atm concerning the compiling aspect of overlapping brushes. i don't overlap because i like to work clean, but it's just personal preference. 

OK thanks necros. You have an alarm going off when there's a new post? You seem to be on top of things :)

Is there anyone who can comment on the Detail/Structural question pls? 

Change brush groups into func_walls or func_illusionaries to avoid breaking up surfaces, or float them 1 pixel off the floor/wall. 

Overlapping brushes are ok, especially for weird off-angle arches and such. 

Anyone got any tips/tutorials/techniques for creating the best rocky/uneven terrain in Quake 1 bsp? :E 

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 :) 

Create a Trigger_Counter (with a name of course :) )that activates at 4, and make it's target the door. Make each button target the counter, and make each button's reset time -1 so a single button can only be used once. 

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?