is it possible to create an invalid shape just by using the clipping tool on a block? i've made this simple torch holder shape just by clipping (no vertex manip or rotation or anything). it looks fine in the editor, but is curiously warped ingame.

also, hammer doesn't report it as invalid either, which is odd, considering quake clearly deforms it as if it were. 

try moving it out of the wall to 1 unit (it shouldn't touch wall i mean) 

thanks, i just tried that. unfortunately it's still warped.

basically, i just took a block, clipped two corners off in the x/y plane and then clipped it in the y/z plane so it had a sloped top.

actually, it's not really a problem as far as my map is concerned; i'm quite happy to leave it as it is - the only thing that bothers me is that i don't understand why quake sees it as an invalid brush. maybe i should split it into triangles to be safe? 

well, when using the clipper tool, if you make the vertices not be on the grid, this will cause problems for the compiler. a good trick to see if the brush is going to be ok or not is to simply move it back and forth a bit. gtkr seems to check if the brush being moved is good or not and corrects faults if it finds them, so after you clipped and or vertex manip, just give the brush a nudge.

there's also a plugin that comes with gtkr, i think that fixes brushes...
in plugins->bobtoolz->brush cleanup it will fix all brushes, and select them, so you can see what changes were made... be careful, because it really will fix everything, even brushes you thought were fine. ;)
i now do this often, it gets rid of a lot of funny qbsp warnings like duplicate planes and others like that. 

damn, i can't believe that didn't occur to me.

hammer doesn't seem to have the same sort of vertex correction that you mention gtkr having. i copied/pasted a few of my torch holders around and they all had the same bad shape.

anyway, thanks for your help guys. i have now solved the problem :) 

I've sent you three emails regarding your ne_lend_q1 map without any reply. If you don't reply I can't proceed troubleshooting it since I need more data/info. 

i've replied both times now...
isn't your email: bengt -dot- jardrup -at- ebox -dot- tninet -dot- se?
that's what i've been replying too...

i'll try again right now... 

I'll check if the progs.dat helps reproducing the crash and then I'll get back to you. 

With this progs.dat I also get the error if I use Fitz/TyrQuake, with my new engine it doesn't happen.

The cause seems to be an excessively large message between client and host at startup and I've already increased that limit in my version because of trouble in other maps.

I can see that something called prespawn is about to execute or to be sent and this overflows the message size (8000).

My guess is that there's too much going on at startup time, e.g. too many spawning entities. Is it possible to delay some of the entities so all don't spawn simultaneously?

I've also tracked backwards to the QC code for the monster_egypt and if I put in a return statement just before the setmodel call, the map loads fine. If I move the return to after the setmodel call, I get the same error message again.

Does this make any sense to you or offer any hint what to do? 

i'm not quite sure...
it sounds like all you are doing by placing the return; before the setmodel is stopping the monster_egypt from starting up... so that would certainly cut down on the amount of stuff getting started.

i do know that there is a delay of random amount that gets set for each monster before it gets setup is already present in the code... i'll see if maybe spawning the monsters in manually (ie: going through the startup sequence of model setting and such) will help that.

thanks for the info. i really wish i knew how to do engine coding. :P 

that there's a difference in that I still get the error message even if I return right after the setmodel and before the walkmonster_start call.

The actual call to setmodel is what triggers the error. Could something be wrong with the ne_egypt.mdl or is it just that including it becomes too much for the engine? 

i think it's just that there are a lot of monsters, so with the added setmodeling of the other monsters is what pushes the engine over the edge, so to speak...

have you tried doing return; on other monsters?

i don't see what could be wrong with the model though, it was straight from the DoE expansion with only a reskinning, and it worked fine for that pack (and was used again in SoE, i think? or was that OuM?) and plus i've had him working before in test maps, earlier versions of the map, etc...

i think it's just quake choking on so many setmodel calls. 

a return at the same spot for any of the Ogre, DeathKnight or Shambler will also do the trick. It certainly looks like it's the total sum of them all that pushes the message size and thereby engine over the edge. 

used a modified version of the zer spawn code, so that way it sets model only when needed (ie when spawned) theoretically, this should allow ridiculous amounts of monsters... hmmmmm ;) 

Both your latest maps seem to have excessive # marksurfaces (> 32k), check the compiler log summary for details.

Some engines might behave unpredictably (e.g. crash) while playing as a result. PuLSaR has already noticed this behaviour in a previous version of his map. Unfortunately, even with the bad brush rebuilt, marksurfaces are still too high.

I haven't been able to actually produce a crash in neither of the latest versions of your maps but some engines clearly have this limitation (and don't enforce it).

I've added warnings in my upcoming compiler version for this and other limits. 

and what does it mean? you mean, just plain surfaces? like wpoly? 

Mark Surfas was the founder of PlanetQuake, and therefore the owner of GameSpy Industries. He's also $20 million richer than he was ten years ago thanks IGN buying him out. 

On what we previously discussed. If you were to resample the pixel resolution of the Quake textures in use in your map to twice their normal density you wouldn't significantly change the visual quality of the texture (without touch up work, like adding gradients), but it could noticeably increase the qualitiy of the light map resolution? Do I have that right? Would you think it worth the evening of experimenting I plan on doing tonight? 

Any one know where I can find an Elvish font type set? (I am so emberassed) I need it for some textures I wittling. 

spelling/gramatical error compounding my red cheeks 

http://www.1001fonts.com/font_details.html?font_id=2554 

yeah, becuase lightmap resolution is tied to texture resolution. 

Look in the compiler log summary for the marksurfaces value.

Unfortunately I don't know what they are or exactly how to reduce the value. I assume they are related to brush faces somehow and by reducing complex geometry, they will also be reduced.

What I do know is that if they exceed 32k, some (or maybe even most) engines might behave unpredictably or crash at some point while playing the map.

It's a bug in the original engine code, the bsp limit is actually 64k. 

These are pointers to actual surfaces. Each leafnode has one marksurface for each actual surface that touches the leaf. Since QBSP merges surfaces, a surface may be shared by more than one leafnode, so there are often more than one marksurface for each actual surface. 

An "actual surface" = a wpoly.