Im having trouble with brushes dissapearing during compilation. they are in the editior (Gtk 1.4) but when i run BSP (treeQBSP v2.00 -- Modified by Bengt Jardrup) i spring a leak! i run BSP after mapconv. perhaps mapconv is screwing up? i donno. 

updating to 2.01 and adding option -q2map, this will eliminate the need of a conversion tool. I doubt that the conversion is at fault though.

From the compiler log, in what hull is the leak? 

i have the opposite problem. brushes that don't appear in the editor appear in the map!
:P 

Turn off editor hiding of func_wall brushes! 

they're normal brushes. :P 

it's some kind of bug in gtkr that makes the editor not load up a brush if it's 'broke' but the bsp compiler must fix the broken brush as it compiles the map. 

You've probably tried all sorts of things to fix it, so pardon me if this is redundant, but have you tried checking it with MapSpy? It's a really great tool that's useful in tracking down bad brushes in any Q-engine based game. 

the problem isn't a large one and only shows up once in a long while, but the next time it does, i'll try it out. it's certainly more efficient than going through the .map file and removing the offending brush. 

if radiant doesn't load it, why don't you copy and paste all your brushes into a fresh .map? 

The leak occurs in hull 0 (i think) That is to say "processing hull 1" comes after the leak warning.

Ill try 2.01. 

guess it was the conversions fault. 

how would that fix anything at all? O_o 

The latest compiler versions have the new Tyrann logic that probably is the main reason for the better result, good to hear it worked for you. 

I think he meant copying and pasting the brushes inside Radiant, and not a text editor. If you can't load/select the brush in Radiant using typical means (i.e. making a huge brush and using Select Partial Tall), then you probably won't be copying it over into a new map and the problem would be solved. However, this would royally mess up all of the trigger/target combos since Radiant likes to rename those when you copy/paste them.

Going back to MapSpy: the way I get rid of offending brushes is to run the map in MapSpy, get the brush/ent number, and then use the Find Brush feature in Radiant to select the brush. Frequently you can't actually see the brush, but it's selected, so all you have to do is hit Backspace and it's gone. 

this would royally mess up all of the trigger/target combos which is why i don't do it. :) i takes ages to fix all of those again, and even after you'll find you missed something.

also, even if gtkr couldn't select the brush for deletion, once i know the brush number, it is simply matter to load the .map file in a text editor, search for that number, and delete it manually. gtkr seems to rebuild brush numbers once it loads or saves the map again. 

knowing how large your maps can get perhaps you have reached a limitation in the format structure of the file as it is read by the editor so it is doing weird things to your map.

Maybe it would be worthwhile to send the map as part of a bug report to the GTKRad team.

If this happens to be the case and GTKR reads Q1 and Q3 map files at different file struct sizes (like Dark Places recognizes no size limits on Q3 .bsp's but there is an absolute 32K one on Q1 .bsp's) then something as simple as converting from Q1 to Q3 .map and reading it into GTKR in that format may help. 

no, it has to do with when you vertex edit brushes.

sometimes, if you create a broken brush by vertex manip, gtkr doesn't seem to 'notice' until you move the brush around. under some circumstances (which i haven't been able to figure out yet) the brush goes from broken but not noticed to full on broken, maybe if you save and then reload the map before getting rid of the unnoticed but broken brush.
*shrug*

anyway, i don't really bother submitting bug reports or anything. nothing seems to come of it anyway. 

I submitted a few bug reports on Bugzilla, and nine months later I got a few notices via e-mail saying the bugs had been fixed. 

has excellent brush vertex manipulation abilities. It isn't difficult to get a feel of its interface either. Perhaps loading the map in Ogier and correcting or even fininshing up the editing with it could solve the problem. Wrath is right about it though, it is about as good as a brush based editor gets. 

Any chance of you adding a -noambientsky switch to VIS that stops the level from playing the ambient sky sound? 

...RPG makes a fine request. Sky_void shouldn't necessarily make a noise.

In space, no one can hear you fart. 

I'll look into it, it doesn't sound so difficult. There are also several other variants (no ambients, no water/slime/lava), are they interesting as well? 

Although I have no immediate use for them, they might be handy in future maps; particularly -noambientslime. So if you're willing to add them, that would be cool. 

I've fixed all variants now, along with hopefully better handling of the actual sound distribution. Before, you could hear some sounds almost everywhere in a level even if the source was pretty far off. Old style is still available if desired.

Also, the state file (.vis) will still be used to full extent, i.e. you can experiment with the sounds without making a new slow run as long as the state file exists. 

I need help figuring out how fast this level can be completed at 100%.

www.chimpans.se/completed.jpg @ www.chimpans.se/promap.bsp <- CAN YOU BEAT THE TIME?

If you beat my time you get a kiss, no cheats allowed, I'm trusting you here. (Btw, no demos, too easy if everyone can see the 'super hard to find' secrets)