Thanks Warren you are a life saver. That was driving me mental!

btw : I accidentally a xcom 2 map pack http://steamcommunity.com/sharedfiles/filedetails/?id=625430712

Will probably work on it some more tomorrow. 

Thanks. Building a logic gate in that way is definitely something I hadn't thought of, but makes a lot of sense now. 

my jam2 map used one of those, exactly for the stuff you described(open a door when an event has fired/happened). Glad to help! 

(2) make a door that opens when the player approaches it but not until a particular trigger is fired.

While it's cool that my logic gate got another outing so soon after the last one, there's an easier way to do what you need here. Create the door with a targetname, then add a trigger_multiple around the door to define the area you enter to open in. Once you're happy with that trigger, use the trick from...

https://tomeofpreach.wordpress.com/2012/11/18/mid-map-entity-spawning/

...to make it a spawnable trigger_multiple. Before you've spawned it there's no way to trigger the door to open, afterwards it opens as soon as you go near.

Of course, if you need the ability to rescind and reactivate the proximity trigger repeatedly, then the logic gate is the way to go. In the case you described, I think you only need the transition from off to on to happen once, so I'd recommend this way as being easier to build. 

A button that doesn't work is counter intuitive to me. I would at first be inclined to think that the mapper messed something up.

It seems better to me that access to the button simply be physically blocked.

I suppose it might work if there was an extremely obvious reason for the button to do nothing. 

Use a trigger_multiple to give you a message saying "button inoperable, power disabled" and then killtarget it later. 

Yep, that's the kind of obvious I was talking about. 

So I've been cutting up a large flat horizontal brush and than cutting away at the constituent pieces at all sorts of angles to create a floor that looks naturally uneven. When I tested it in-engine just to see how it looked, I fell right through one part of the floor, as if the brush were a func_illusionary. Then I remember having seen this in a few other maps too (I think one was a speedmap by FifthElephant and one was one of Tronyn's Unforgiven maps).

Does anyone know why this happens and/or how to avoid it? 

Welcome to Quake mapping. :) 

Cover it with clip brush. 

Quake and slopes sometimes get into little arguments with each other. Clip brushes try to keep the peace and let everyone live in harmony. 

This can happen for two reasons;

1. Depending on the method of construction and editor used you'll get tiny misalignments. This is the reason for most if not all corrupt brushes.

2. The engine just doesn't like a specific brush configuration.

Solutions:

1. Make sure everything is on grid - don't use carve, be clever with vertex manipulations (no concaves, make everything either wedges or pyramids if you want terrain). If you're clipping then clip across the entire brush, from grid point to grid point.

You may need to delete and rebuild bad brushes.

You can also get sticky brushes, where a tiny (invisible) overhang is in the floor - you run into it and get stuck.

2. Move stuff around. This isn't a common problem unless your geometry is very simple and pretty big. 

These will solve hull problems, but they're a kind of 'ah fuck it' solution that can cause other headaches.

The floor / wall can still leaks for example, or end up requiring a lot more lightmap that you won't even see. Or produce isolated pockets of space outside your level which won't break anything but is better avoided.

Sock's tuts on terrain: http://www.simonoc.com/pages/articles/terrain1_1.htm 

And another problem - many people assume that terrain requires much longer vis times, the truth is both yes and no.

Typically there are these misalignment issues in places where the player won't notice, like in the walls or ceiling.

The other thing these cause is unnecessary vis calculating.

Not a big deal with multicore compilers, but it can be the difference between it taking 5 or 10 minutes, and if you're compiling frequently (as you should be to avoid it exploding in your face after adding new stuff) then this can slow you down a lot. 

That was the kind of explanation I was hoping for.

I had a look at Sock's tut but am finding it a little hard to understand in terms of TB and Quake, as it seems to be more about later brush-based games and things I can't do when mapping for Quake ... unless I've misunderstood something. Maybe it just assumes more prior knowledge than I have.

DeeDoubleU, Bloughsburgh -- I had also actually thought of just plonking a clip brush down in the offending spot, but I wanted a better understanding of what was actually happening. Thanks for responding, though! 

Avoid triangular faces (tri-souping) when building your structures, especially floors/walls.

Socks tut uses quadfaces as well if you look closely. The quake engine uses a rectangular "brush" to clip the player against the several hulls.

This CAN be a problem, with more complex structures it is more likely to encounter those problems.

Stay on grid, and what Ijed said. 

I use quads for the structure and tris over it for details.

You could also grab the RRP devkit from its thread and open up the telefragged map to see my method, which was done in Trenchbroom. Mfx' and Hrimfaxi's also have terrain of course, just not sure on the editors used. 

What is wrong with trisoup so long as it has been converted to a func_wall?

Incidentally, if I have multiple details, outdoor trisoup areas, trim, etc. and I make all of it one single big func_wall entity, is there an issue? E.g., will it flicker in some places? Does the world origin need to be visible from every leaf for this to work?

Curious about the theory behind it. 

Thanks so much for both your replies.

I was just about to ask whether anyone knows of any other Quake terrain tutorials (something along the lines of czg's curve tutorial, for instance), because at the moment I can't seem to wrap my head around it. I'll definitely have a look at the Telefragged source to see what I can learn & if I can extrapolate your method from your brushes.

Thanks again! 

Compile often, check for errors often.
Seal your map for those tests, a big brush will usually do this on areas you haven't worked out yet.

There is a super-simple way of creating terrain, any complex terrain, sadly i can only produce this with the Quark editor for now. I have tried to describe my experience with that often and most honest, but there is no way currently to describe it as just use quad-faces.

Study the sources, look at how i use overlapping brushes very often to achieve terrain.

And when i find a spot where the clipping fails, and no change to the brushes does affect this, i use clip brushes to conceal those errors. As a last resort so to say..

Again, don't get stuck on details while building, block out generously, any finetuning you can always do later.

Important is the pacing, the general "flow", and and exit.

Some even might say those details are just a special kind of expressing an OCD. (no offense..) 

For the less OCD:

Jackhammer has a "rock" primitive. It lets you create a (somewhat) randomized mesh with a certain number of vertices. It's quick, dirty, somewhat painless way of making a rough wall or just a plain boulder. Pretty neat I'd say, if just a bit...well, ok a lot...messy. 

inspect this carefully, you'll notice all brush sides are orthogonal(i.e. 90�). Imagine an egg-slicer, i use this description for my approach quite a lot.

http://cdna.the-lust-list.co.uk/wp-content/uploads/2014/02/kitchen-craft-egg-slicer_231461400.jpg

It creates a "hump" out of rectangular brushes, so to say. From there on, it is not hard to build a terrain mesh.

Just rotate the sliced egg 90� degrees to have an approx. mesh. All sides are pointing in the same direction, any transformation has to keep this.

This sounds weird, i know. Once you get the knack of it, it becomes easier, but never really easy.

HTH 

Hmm, it seems I have a lot of homework to do to figure out terrain brushes. Not sure I'm ready for a second or third editor just yet, but perhaps?

As for blocking out vs getting bogged down in detail work, yeah, I'm doing things exactly wrong at the moment, as I've been basically working on one room of a map since forever (and I've rebuilt that room countless times). At this rate I'll need about 100 years to finish my first map. But it's all part of the learning process, right? 

Guys... why is this happening?
https://www.youtube.com/watch?v=tI-v9N9ladY

Earlier I noticed wizards will occasionally fly through a door for unknown reason. Door has no slopes, not even a 45 degree angles, 1 plain box brush.

Now this.
Fishes escape from their tank and chasing me throughout the level, but they can move in solid worldspawn geometry only O_o

I think it mostly happens when I'm noclipping, though not sure.