Look at sock's rock wall tutorials:

http://www.simonoc.com/pages/articles.htm

It's much more brush/face efficient than trisoup.

As a rule of thumb if I can use sock-style "rock wall" geometry for terrain/cave stuff, I will use that. I only do tri-soup for places where the above doesn't cut the mustard, and for joining disjointed bits together smoothly. 

Can you please get into more details with this?
Simply linking button or trigger to box does not work for me for some reason. 

Thanks for the link, Kinn, gonna check it out tomorrow. 

Small button with "health" "1" next to the box, so the exposion damage triggers it. See bbin1 for reference, at the end of the second level part. 

I'm possibly missing something obvious, but is there a way to do the following two related things?

(1) make a button that activates when the player touches it but that cannot be activated until after a particular trigger is fired.

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

Could it be as simple as an invisible func_wall in front of the button that you killtarget later? 

Yes, that works. Actually, I had thought of something like this but for some reason convinced myself that func_wall wasn't implemented in Quake.

Thanks for putting me right. 

This should be something really simple but it is driving me insane :/

Ok, so I have a prop properties page open in UE3 editor and in this prop I can assign other props to die when this prop dies, all I have to do is input the name of the props I want.

One of the buttons says "use current selection item in the content browser" but if I select the thing I want in the content browser it brings up the properties for that item and I can no longer enter it into the ui.

I can see no way to copy the name of the item either.

So, it seems the only option is to type out an insanely long reference name which I will inevitably fuck up somewhere and create bugs.

What gives?! 

Your 2nd question needs something like this i think:

https://tomeofpreach.wordpress.com/2013/05/13/new-logic-gate-design/ 

Did my tweet not help? Locking the property window will stop it from changing the window when you click another actor.

And typing in the name won't fuck anything up because it won't take a bad name ... the name will have to exist or it won't accept it. 

wait a second.. 

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