try looking in the error report. You might find a bug 'texture axis perpendicular to face'. Just click the fix button.

Its sometimes caused by clipping brushes.

I dont think its possible to create microbrushes in wc. 

which are very small brushes, and a typical problem in quark and similar editors. 

thanks ijed, the error report fixed it...

sometimes the obvious answer is staring us straight in the face... another week-ish of polishing here and there and the map should be ready for consumption. 

Which bsp.exe is the one for me?

My current one: TXQBSP.EXE 1.12

What I need:
Support for small brushes. Small 16 sided cylinders get all messed up and end up more like 8 sided cylinders.

Support for liquid brushes that are one of the following: wedge shaped (4 or 5 faces), tied to an entity, completely or partially angled compared to the 3 planes (x,y,z), and/or micro-positioned (fractional units for a point like "263.4, 47, 18.9")

Specifically, doesn't think that there is a "Brush with duplicate plane on line: ####" when there clearly isn't!
Sorry Tyrann. TyrUtils v0.10 has these errors. It then proceeds to butcher my beautiful brushwork just like txqbsp.exe 

All compilers have some level of "tolerance" when it comes to whether a plane is duplicate or not, and the finer you make the detail the more likely it is that two planes you think of as distinct get merged for being "the same".

What rarely gets explained is why this is a good thing - why the compiler does it. Imagine that on the outside of your map - facing the void - you have two brushes which meet on angled faces. Because the map uses floating point to represent these planes, it's possible that the inherent imprecision of computer arithmetic makes one plane ever so slightly different to the other. If you don't have some way of treating approximately equal planes as being the same, then you get a leak between these two planes.

It's one of those things in engineering where there's a trade-off going on, and the compilers are configured to do the least bad thing. Like you could rebuild the compilers with the delta for equal faces being much smaller. But then you might have to rebuild your map so all the outer walls meet on axis-aligned joins...

PS: Check your map file in a text editor for line #### and see if there's another plane in that brush which is almost the same. If you can track it down, you might be able to slightly tweak the brush so that the planes are different enough to compile. 

Bottom line is: Quake is not the game (engine) for small, delicate geometry. 

If you really want those types of detail then map objects are the way to go. 

While working on a terrain map I found a strange outcome in my compiling.
Lots of polygons started scrambling their position.
First map in Radiant1.5 showed like
thus

Then after some days compiling I end up with
this

In Radiant the map shows no gaps, but in game it is mesh. 

You can have liquids as entities, actually.

As for small multi sided cylinders etc, I suggest using Darkplaces or FTE and q3bsp - the grid size goes down smaller than Q1 and you can compile mapobjects into the BSP.

Liquids not cuboid - this is down to trigger fields. You can make a liquid brush wedge shaped, but you'll get waterwarp/tint outside of water then. Instead, stagger your liquid brushes to create the shape you want.

Your qbsp exe is q3map2, pretty much.

http://spawnhost.wordpress.com/tutorials/q3bsp-for-quake-tutorial/

You can't use Worldcraft if you go that route though. 

The path to the file is:
C:\ Users\ *yourusername*\ AppData\ Roaming\ NetRadiantSettings\ 1.5.0\ *yourgame*

I'm using NetRadiant 1.5.0 here, change that if you use another version.
I also set the file to read only, just incase Radiant would like to overwrite it. 

Does:
mapobject = point entity
mapobject = brush entity
mapobject = point entity with a .mdl
mapobject = point entity with a brush model (as in the case of worldspawn)
all of the above??

Do you just mean any entity with a model? 

But usually with little to no functionality - decorative makestatics usually. 

Point entity with a model, decorative and usually does nothing, not even collide. 

I'm setting up a future article for the blog here (like so future that I'm still finishing off the article which precedes it...), but it is a bit of a slow day on func_ so I think that's ok.

If you create a zero-wait trigger_multiple whose targetname is the same as its target then you'll get an infinite loop, which will quickly crash the map with a stack overflow. Similarly if you create a chain of trigger_relays which loop back on themsevles, the same thing will happen.

Can you devise a set-up where the same entity gets triggered more than once in the same "action", and the game continues running? (In the same action means before the function which was called to trigger things initially returns). 

If this is what you mean, but I often trigger two relays at the same time, which both point at the same target but with different waits.

To open a door for a fixed period of time for example. 

I'll clarify with an example. If you have a trigger_multiple with

"target" "tweedledum"
"targetname "tweedledee"

and his partner

"target" "tweedledee"
"targetname "tweedledum"

If you ever walk into one of these triggers, they'll instantly crash because they just keep using each other with no delay, and the stack overflows. tweedledee targets tweedledum who targets tweedledee...

So in effect tweedledee is targetting himself. This would however be fine if either trigger had a delay - in fact a trigger which targets itself and has a delay is a very useful pattern - it's basically a clock which keeps firing the same event at a fixed time interval.

What I want to know is "can an entity indirectly target itself - cause itself to be used again, with no delay, legitimately?" That is, without crashing the engine... 

What are the max faces / verticies in a map? Do models count towards these limits? Do brushmodels and external brushmodels?

I've got a Bad Surface extents error and nothing I've done recently seems to have caused it since I've been backing up, deleting stuff and recompiling to try and find the issue but no go.

I've got 50906 faces against the standard 32767 normal limit.

The map doesn't load even in RMQe and I've been testing in fitz up until now.

If it is just too much stuff then the map may well just end up as a load of empty boxes since It's barely halfway complete and I haven't even added the end arena. 

A delay of 0.1 would equate to next frame - it'd be heavy as fuck on the engine but it shouldn't crash outright? 

Frames can be shorter than 0.1 seconds, and it wouldn't be a great strain on the engine to do that. The problem is that the sequence of Tweedledum and Tweedledee never ends. This is fine if there's a delay, because you've got an infinite sequence to get through, but an infinite amount of time to do it in*. If there's no delay, you have an infinite number of triggers to get through this frame, which is too much.

*Disclaimer: the Quake engine cannot in fact run indefinitely due to floating point issues. 

Use a different entity than a trigger to relay the firing? A non-moving door perhaps? 

Probably you need to have some sort of flag or variable that cleared when the entity gets "used", and once cleared prevents the loop from repeating. Sort of like breaking out of a while(true) loop. 

I'm imagining if you add a trigger_counter to the loop you might be able to terminate it after a certain amount of iterations? I'm not sure if I'm understanding the question right.

trigger_relay: tweedledee targets tweedledum
trigger_relay: tweedledum targets tweedledee
trigger_counter: tweedledum killtargets tweedledee, count 10

That should be activated 10 times in a single frame, at least in theory? Can't remember how killtarget works atm, maybe it doesn't remove the entity until the next frame.
I don't really see any practical purpose to the whole deal though...
Oh and this setup can't be reused of course. 

That depends on which order tweedledee activates the tweedledum entities. If it goes for the relay first it never reaches the counter obviously, and it most definitely won't work. 

building on CZG's idea...

trigger_multiple:
"targetname" "a"
"target" "b"

trigger_counter:
"targetname" "b"
"target" "a"
"count" "1"

now the trigger_multiple's use function can trigger its own use function on the same frame, but for a total of only twice, instead of infinite times. 

the hard limit of faces and verts (regardless of engine extensions outside of new a format (bsp2)) is 65535.

External bsps do not count, but regular bmodels do.

Have you tried the old standby of removing large portions of the map to try to pinpoint the problem area?