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. 

DeeDoubleU, someone else is bound to have a far better answer than me, but the mean time I'll risk embarrassing myself:

AFAIK both of these behaviours are known bugs but nobody knows exactly why they happen. I recall having read a few discussions where experienced mappers were stumped, especially by the Scrag thing. According to this post you might be able to avoid the issue by not cramming too many of the offending monster into the same enclosed space...

Or wait for someone who knows what they're talking about to answer. :) 

It's a weird bug caused by the navigating I believe since both fish and the scrag use point collision (not bbox) to manage their movement, but a bbox to receive collisions.

So they find a bit of geometry that they don't like for some reason and it pops them into an invalid volume outside the world, and then they can't get back in.

Scrags usually can because the flymonster behaviour gives them a bit more movement.

I suspect its something to do with the discrepancy of the center point and the bbox corners.

I know that brush misalignments can cause this (like with the player), but so can perfectly clean brushwork that the offending monster manages to get stuck on and then clip through.

Mapside, the solutions are basically either delete your fish or change the areas where they are used until it stops happening.

Scrags are best used outdoors so that they don't push themselves up through a ceiling trying to match heights with the player - which seems to be the main cause of this for them.

This was the main reason I experimented with small fish, but ran out of time / gave up before I could get a decent handle on it. 

I've seen scrags move through solid geometry many times, but I don't remember ever seeing flying fish. Maybe that's just because fish aren't used nearly as much. 

I use trigger_multiple but I don�t know how to use the specifics.