since the 35 is wrong, i suspect some of the other numbers too... 

Max fall height is 256. And why should it be 42.5? 

While trying to optimize a map to bring it under the marksurfaces limit, I encountered (and bit my teeth out on) a perculiar area where some seemingly random face splitting occurs. Shot - the grid-like stuff next to the kights.

There's no indication where it could originate from, no intersecting brushes or anything, and the tris even reach into an adjacent room through the wall (there's a doorway at the end of the corridor). I can't seem to get rid of it. Tried upscaling the texture, splitting the brush into smaller chunks, even trisouping it, moving it to the end of the brush cue, but all to no avail. It does go away if I block out parts of the map with a giant brush (to speed up QBSP), though.

I don't expect anyone to know a magic cure; this is mainly supposed to be a wtf bsp post. The whole deal with marksurfaces (and their optimization) is quite obscure. Seems to be more about experimentation than logical conclusions... 

i posted something similar a while back: http://necros.slipgateconstruct.com/temp/split.jpg

those were all pre-split tris (ie: planar by definition) yet bsp split the thing in such a strange way.

if that was a non-planar area, i'd say try messing with -epsilon (check out aguirre's readme for what values) but i doubt it will help you because that floor is completely flat.
you could try that offset texture by 1 unit trick, but that's not really solving your problem, just forcing bsp to do something else. 

I just replicated the messures from the Virtus DeathMatchMaker, so first I thought the grids had different scale.
Quark let me jump poly's 42.5 height.
Even 43 units will do, but 44 blocks.

Maybe the vert meshes appear because of the reach to integers? :P 

I recommend r_drawflat to see actual surfaces instead of tris 

is there a program out there that will let you feed in map files which contain only small pieces of a map with maybe 'attachment' points of some kind and then let you just snap them together oblivion construction set style and then just compile it all up into a single .map file you could load in any editor?
that'd be cool... 

dzerdwfvgftucxwfgyhgd 

As soon as he sees player he goes activation anim\sound and then just vanishes, technically dying, adding to the killcount. What could be wrong? 

Does it spawn on a moving func by any chance? Sometimes this screws up and monsters block it for no apparent reason. 

They spawn on a solid. Probably incompatible with q3bsp. I guess I'll have to live w/o them, oh well no one likes polyps anyway. 

I like tarbabies, too. 

there will be many other means to decimate your hp. 

I like tarbabies, too.
We can control that with medication. 

tarbabies don't like, you
They controll that with indication. 

incoherent fire dissipates all contingency. 

Do you have spawndelay set to -1 on the polyp? I think there's a potential bug with that setting which could reproduce the teleporting ogre bug. 

They cant survive too far from the center of coordinates. 

In the spirit of scientific enquiry, could you try moving them even further from the origin of the map and seeing if they still misbehave?

I've been trying to run through possible issues, haven't seen anything obvious in the QC. The 4096 coordinate limit in stock engines is imposed by the network messages; the server stores coordinates internally as floats. It seems impossible even in a Q3 format map that you would have a map which could overflow a floating point vector. So if you can reliably reproduce it I might have to borrow a copy of the map to find out why... 

Never mind, there's literally just code that removes a polyp whenever they leave the range 8192 to -8192 in any coordinate. The function is called polyp_skyabove so I assume it went in there to catch polyps that flew away into the sky and out of the map.

I suppose we have to say it's by design now... 

Any other quoth monsters have that code? 

Can this please make any sense??? After long woes and trial and erroring with countless 5-min long compiling breaks, I managed to bring the marksurfaces count just under the limit - again; for the x-th time. Even simplifying rooms and shit. Then I fix a simple portal error on a small step (invisible face), and suddenly the whole count is down 300 points. Is QBSP making fun of me or something?! 

I have noticed that sometimes adding stuff to the map can actually lower figures instead of increasing them. 

There is nothing I can contribute to your knowledge, but its comforting to know you get as perplexed over that shit as anyone else...
Also, nice to know you're working on something (apparently something large). 

one thing czg figured out was that you can exceed the marksurfaces limit and not crash, as long as the extra marksurfaces come from bmodels and not the worldmodel.

Unfortunately there is currently no tool or engine that reports worldmodel marksurfaces specifically (that I know of.)