You do know that you can use func_wall instead of func_illusionary if you want to have collision detection for it but not block vis, right? I dunno why you were only able to make some stuff into func_illusionary, but if it's due to lack of collision detection then that might help.

Err but I think you knew that. 

I don't think I've experienced that error before, but I've seen it mentioned at QuakeLab http://www.planetquake.com/QuakeLab/bsp.htm . The original error message was CheckFace: BUGUS_RANGE ....

It appears to be a face that the compiler thinks is too big. I can't find any limit that indicates that there are too many of anything.

If you wish, you can send me the zipped map+wad and I'll take a look at it. 

RPG: yeah, I know the difference. I just prefered illusionaries in this case because of the collision thing as well. I can then build simpler, rectangular solids inside them ( out of clip or black ) to approximate collision.
By 'only some ' I meant, there is some pseudo-curved stuff that needs to be solid to cast shadows, or interiors will look floodlit :/

aguirRe: thanks, I may send it to you. I hope it is something to do with size of a face rather than total number; the map's almost finished and culling superfluous detail always makes me anxious.
I'll have a look around the map when I get home and send it to you tomorrow.

Thanks for the info guys. 

that's done the trick :) 

you can run the map through the brush checker and it usually gets rid of busted brushes. 

Last map I brush checked like that started leaking like a sieve. 

mmmm, yes. that tends to happen... but i don't think the map would have started leaking after the check because it basically does what qbsp does. when qbsp gets wierd brushes with duplicate planes and such, it tends to mutate them much in the same way the check does, so it's likely that qbsp would "make" the map leak as well. course, there could be some exceptions... (aguire, any input?)

the nice thing is that after the check is done, it selects all the modified brushes, so you can check to make sure the modifications didn't leak the map or somesuch. 

for including my 'itty, bitty' brushes in the hull. Oh well. Live. Learn. Get Luvs for those messy spills. 

when qbsp finds duplicate planes, planes with no normal etc, it just drops the plane, it doesn't change it.

What might happen though is that when this particular plane is dropped, the brush isn't closed anymore (i.e. doesn't form a closed volume) and this isn't good.

In the latest version of my compilers, I've added a check for simple axial brushes (i.e. cubes) being closed. I haven't figured out how to check non-axial brushes.

PuLSaR actually had this issue in his upcoming map and when fixing it, the # clipnodes went down pretty much and in a big map this might be crucial.

I've also added some info regarding this in my latest ToolTips. 

Well, I had a very recent back up copy of the map and compiled that successfully - error gone.
The last brushwork that I was adding before the error, involved some cloning of existing brushes ( to get the same variations of texturing on the faces and lock the brushes at the same height; they were wide steps ) and I started to use Radiant's edge manipulation. As is sometimes the case, the brush disappeared instantly, indicating an invalid of some sort.
I ran bobtoolz brush cleanup and it removed the offending step straight away.
Thing is, when I continued to work on the same feature in the same area, I created and deleted some brushes myself, then CTRL+Z'd. When the brushes returned, some of their faces were white, like a point entity. No texture. I couldn't change the texture afterwards either.
So a combination of Radiant and my sickly HDD probably cause some mutant brush error that I couldn't see properly in Radiant to fix. Even brush cleanup didn't recognise it.
So anyway, not entirely sure what the problem was, but it's gone.

The map's coming along nicely btw, due in no small measure to aguire's bsp coping easily with my huge terrain mesh. Thanks for that :) 

I've added coordinates to that error message, should it appear again. 

I remember having trouble with brushes that were edited in Radiant and then disappeared. That was back in the olden days, and David Hyde used one of my maps as a reference for getting MapSpy to detect those brushes. Even though it's targeted at Q2, Mapspy can be very useful in tracking down rogue brushes of that sort. It outputs the brush number, which makes it pretty easy to track it down even if the editor isn't displaying that brush. 

Hey guys, I'm new here - glad to see there's still people who mod for Q1 ;). Anyhow here's my question; do Hexen 2 maps require special compilers designed specifically for them or can I use ones for Quake1 as well? I tried to use aguirRe's bsp and light compilers but light gives me this error for one map (I used it for another map and it seemd to light fine):

************ ERROR ************
LoadBSPFile: odd Model lump size

while bsp gives me this error for any map I try to compile:

************ ERROR ************
Invalid brush plane format on line 14

This is line 14 in the .map file:

( 3630 525 -105 ) ( 3630 524 -105 ) ( 3960 524 -105 ) rtex066 0 0 0.0 1.000 1.000 -1

Meh, I wouldn't be trying this if the people in the H2 mod scene didn't amount to my hand's digits :(. 

i'm afraid you have to use h2 compilers only... 

Thanks, Well I'll just be off to bug the dude making NewHexen, he's done some pretty good stuff with both the compilers and engine so far.

I may be back! ;-) 

has more hulls than Q1 (5 or 6 I think), so my utils won't do I'm afraid. It appears to use the same bsp version number (29), though. I've never tested anything with H2 maps (I don't have the game either). 

I looked into Hexen 2 stuff a while back... yes, you do have to use the Hexen 2 specific compilers, and unfortunately (when I looked, at least) they're pretty basic and didn't include all the fancy things we've come to expect in the updated Quake tools.

However, I last checked something like 2 years ago, so perhaps someone has released some modified tools since then. 

Well they are still rather basic, although we do have colered lighting and a few other options like minlight, fade and range that's really all.

Maybe I can get Korax to look and see if he can add more options to them. Which compilers that are out are the best right now? I can only think of Tryan's and aguiRe's tools. 

want to beta test a q1sp? an engine that supports external texture replacement is recommended (fitzquake, tomazquake, ...?) not necessary though. 

Several people seem to have problems setting the gamma (brightness) in my new GLQuake engine. Just add the -gamma x command line option, where x can be e.g. 1.1 or any float value that gives a good result.

GLQuake only sets the gamma at startup, so it doesn't help changing it in-game.

This information has also been added to the readme. 

helped me load a map that was over the limit on marksurface, clipnode and lightmaps. :D 

necros, thanks! 

Did you get my e-mails from last week. One of which was quite legnthy though I don't know how useful it may have been. 

i hope you backed it up...

the last email i have from you is dated apr30. :\

did you get the reply i sent on the 30th? 

I've just re-sent it.

I believe it to be the lengthy version. Last dated e-mail I have from you is dated April 28.