ok, my new map is way over max. clipnodes (about 46K). Covering detailed areas in clip brushes should reduce this, right? Also, say a clip brush covers a "broken" floor (like the floor at the very start of Bastion) I've noticed that the floor is still sort of sticky: i.e. it's flat, but the friction seems very stiff. Is the clip brush still reducing clipnodes if it's 'flush' with the unbroken parts of the floor, or does it have to be raised slightly off the entire floor surface? 

I guess you've already checked my ToolTips for this issue. Clipnodes only add up in hulls 1/2 (the clipping hulls), so covering with clipbrushes help.

AFAIK clipbrushes melt together with other brushes normally, so you shouldn't need to raise the level (at least I've never seen such a requirement).

I'd absolutely recommend that you check out the map in hulls 1/2 using the -hull # option, to see if there are any major enclosed volumes in those hulls that need filling (or open to the void).

Noclip outside to see if such orphaned volumes exist, they can add quite a few clipnodes to the total. It's not enough to seal hull 0.

If you wish, you can send me the zipped map+wad and I'll see if I can spot something. 

Sorry for any delays in my responses--I've been gone a few days.

As Kinn said, the "ladder" effect is created by making a very steep staircase using the clip texture. I used 16 units high, 112 units wide, and 1 unit deep. And as aguiRe said, the .map source is released, so you should be able to get a good look at it in your editor. Unfortunately, as aguiRe mentioned to me in an e-mail, there seem to be some floating point errors, but that isn't always a problem, especially if you don't compile it. 

JPLambert uses QuArK so he should be fine with float maps. QuArK can even read the original Q3 format as well, so there are several options.

The ones most likely to have problems are those that use the BSP editor (WC seems actually to be fine with floats too).

My compilers are OK too since they handle floats, even the technical notation in your converted Q1 map (otherwise you wouldn't be able to build it). 

With your latest compile tools, my map builds ok (with no leaks), and it can be loaded in custom engines that can tolerate it. I'll give it a good going over with clip brushes first; but if it's still giving me problems I'll hand it over to you. :) 

How many marksurfaces does your map contain? As far as I can see there are usually more marksurfaces than clipnodes.

I found that map crashes in almost 100% cases when it has >35000 marksurfaces. That goes to vanilla glquake or winquake.
But I may be wrong. 

46688 clipnodes
28732 marksurfaces

unusual? btw, what are marksurfaces exactly? 

exactly what they are, but AFAIK they are bad ;)

My map has 29k clipnodes and 34k marksurfaces.
Marksurfaces grow faster than clipnodes for me, but that's the experience only from one my map. 

in how the exceeded limits affect the engines. The excessive marksurfaces (>32k) cause strange behaviour in most engines due to a coding bug, the limit should actually be 64k.

Clipnodes appear to be related to nodes which by specification cannot be >32k, since they'll otherwise be interpreted as leafs. If they are, the engine won't be able to tell how the bsp tree looks like and anything could happen.

However, I've never seen any engine actually crash due to excessive clipnodes. 

uses a staggering amount of triangle brushes; i guess that's what is causing the clipnodes to skyrocket 

earlier with PuLSaR's map, I found out that marksurfaces are affected by both world and entity brushes but they're only affected by the visible hull (0). Adding clipbrushes won't reduce them.

AFAIK marksurfaces are somehow related to surfaces (i.e. visible planes) in the map. 

Kinn, your prevous post has a cool #2222 

show that the map with ecsessive amount of marksurfaces becomes very sensitive to adding thin detail brushes and curve constructions. 

that spikey map i was working on before was crashing most quakes with about 37000 clipnodes. 

large maps cause large problems... 

...this http://www.planetquake.com/fatty/default.asp?opinion=generaldesign might be of assistance 

After understanding "clip textures", and doing so, I found myself stranded with the same thing for animated ones. Sometimes they appear good in Quark, but after compiling not. 

Some BSP compilers don't automatically include all of the frames for animated textures in the BSP (wQBSP is one of the culprits, if I remember correctly). To get around this, you can use another compiler, or you can manually apply all of the texture frames in the animation into the bsp (by applying those textures to hidden faces somewhere in the level, eg on the back of walls which you will never see).

Of course, that may not be your problem, MadFox, can you give us more information? 

After finishing the Quatrotski map with texture clipping, I noticed the lava brushes didn't compare.
So I tried to match them in Quark6.3
After doing so, and compiling, they still went separate. 

why are you using quark? 

do I play Quake? 

...errr.. there is aonly a pub banner here... or there is a hidden "subliminal" message ??? 

I want to make it so that when you kill some particular monster, two more appear via teleport. I know that it involves the trigger_multible, but i forget how. 

Are you making an uber-terrain map if I recall? If you get a minute, what sort of clipnodes/marksurfaces are you getting on that? 

Start your teleported monsters off in a hidden box outside your main level. Make them stand inside trigger_teleports, but give the triggers targetnames, that way they won't teleport until triggered. Set up your info_teleport destinations where you want your monsters to appear. Have another monster target the trigger_teleports - when you kill him, the others should teleport in. You might also want to add a delay to that.