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.) 

Bspinfo.exe 

Any other quoth monsters have that code?

Nope, it's part of a larger function that only applies to the polyp. 

as long as the extra marksurfaces come from bmodels and not the worldmodel

that's interesting and good to know. :) 

Use external mapmodels.