Strange map compiling behaviour

[XaverXN]

OK, I'm slowly going insane with mapping... first the linux gtkradiant is so instable on my system that I had to switch to windows for mapping, and now I can't get rid of these errors:

Take a look at http://www.sr-welt.de/ufoai/ascr.map, this is a small piece of ground (7 brushes) of my actual map.
-When compiling it (in windows) without the 3 grey textured brushes, everything runs fine, done in 23 secs.
-When adding the one grey brush on the left, it compiles, but takes ~10 mins (!).
-When adding the left and right grey brushes, it gives me a MAX_MAP_PATCHES exceed.
-When adding all three brushes, it gives me a MAX_MAP_VERTS exceed (meant: vertices), while I think this is simply impossible on a 7 brushes map.

It is the MAX_MAP_VERTS error that got me testing in the first place because I got it at some point while mapping and couldn't get it fixed. Doesn't seem to be just one 'bad brush' this time...

And where the windows compiler takes 10 mins the linux compiler takes 4 secs  :shock: !

Anyone any idea?

[Mattn]

i can compile it with ufo2map and run it (both linux)

[Wanderer]

OK, I'm slowly going insane with mapping... first the linux gtkradiant is so instable on my system that I had to switch to windows for mapping, and now I can't get rid of these errors:

You broke your system, would be my guess.

If the map you posted has all of the brushes you describe above, I have ~15 second compile time and no errors.  On Windows.

Check Build ->Customize.  Make sure final build is set to [ufo2map] -bounce 0 -extra "[MapFile]"

[XaverXN]

Na, I am almost sure my systems allright.

Mattn, I can compile and run it too (without the -chop 32 in win of course), thats not the point. The point is that these three brushes shouldn't take it 5x as long to compile and give a 1,4 MB bsp instead of a 38 kb.
Thats why I think theres some point to the errors that I get with -chop 32 ...

[Wanderer]

Na, I am almost sure my systems allright.

Mattn, I can compile and run it too (without the -chop 32 in win of course), thats not the point. The point is that these three brushes shouldn't take it 5x as long to compile and give a 1,4 MB bsp instead of a 38 kb.
Thats why I think theres some point to the errors that I get with -chop 32 ...

Chop 32, from what I was able to tell from the documentation, cuts the map into 32x32x32 areas, and then compiles each piece independently.  Try -chop 256 for a different result.  Either way, Mattn's listed on the compile wiki page that -chop is busted for our usage.

[XaverXN]

-chop is busted for our usage

Ah, OK, didn't read that. But I just found out that it works without that option anyway ;-) Why I could't start my map anymore was a 'normal' bad brush thing that I had to find and eliminate...

That jump in size and compile time I described is strange still, but I think I'll just ignore that for now...

Thanks for helping!

[Wanderer]

Why I could't start my map anymore was a 'normal' bad brush thing that I had to find and eliminate...

God I hate those.  I've just started reverting to older copies of the map out of self defense.

[XaverXN]

Self defense ;-)

Thank god, for me its mostly just one brush now and then. But I had one 'voodoo brush' once, that was fun... had copied it so often that they were about everywhere... in every form, content and texture :twisted: