yikes... i never thought people actually used the auto target/targetname system. :S
it can be very helpful to give meaningful names to your entities to help keep track of, not only what they are, but what areas they belong to and such.
anyway, that aside, what are your triggers triggering? without more info, can't really say much.
i'll hazard a guess and say it's probably auto linked doors. try putting the DOORS_DONT_LINK flag on doors that are triggered but near to other doors. 

Compiled with -onlyents, am I right? run a full bsp process. 

Found it! I had an old ent-file in another directory that screwed things up! As I had named the edited file the same as the original (e1m1), DarkPlaces found it! But as I haven't changed any of the triggers or entities in the map I'm still confused why it screwed things up as the ent file works with the original e1m1 map? 

The cause is likely that you added a model to the map! The ent file records an index for which of the brush models to use for each trigger*. If you altered the list of models by adding or removing one, then the model entry for trigger t32 in the ent file might end up pointing to the model for t31 in your recompiled map.


*NB for those with technical know-how: this is not the modelindex field in this case. Brush entities in a map have the model field set to e.g. "*20" if their model is the 20th one baked into the map. 

the maximum distance that a player can jump and not fall into water,lava or other traps:
225

the maximum distance that a player can jump straight up and get up to another object:
42.5

the maximum distance that a player can fall and not be injured:
275

The minimun gap in floor spacing, slatted bridge, or floating squares of lava:
35

The maximum height that a step can be before the player must jump:
17 

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