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) 

. 

http://kinn.spawnpoint.org/SA/what3.gif 

I managed ten. There's no way you can do it in less than nine without noclipping. 

I have a .qc file called ogre.qc where he fires only grenades. I have another one called ogre.qc where he fires only nails. (Where I use a single gender term, I of course relate to both genders.)

If I rename one ogre1.qc and compile them both into progs.dat, is that enough to identify and use two different ogres in the game without changing anything else in the .qc file. I do not want them to have different skins - I want the player to see two ogres one of whom fires nails and the other grenades. I do not want the player to see this until it happens. I assume I will need to name them monster_ogre and monster_ogre1 in the map file.

I do not know anything about QuakeC except how to decompile and complile.

Your assistance will be appreciated muchly. 

Also, can someone explain in easy to understand bullet points, what the pros and cons are for using models instead of brushwork.

I have a statue of Anubis made up of 450 brushes. If this was a model instead of brushwork, how would playability be affected.

My start point for this question is the tree in Marcher Fortress: why a model, why not brushwork?

Don't forget now, not too technical: play with me here, not against me:-) 

I'll start with your second question first...

In Quake, complex brushwork is very expensive in compiling terms, for various reasons. Quake has no support for detail brushes, so every bit of world geometry is is chopped up and merged with the rest of the world, and put through the same vis calculations (which can grow exponentially when you have lots of fine detail in large outdoor-type areas).

There are situations where turning brushwork into a func_wall can be useful. Basically, because the brushmodel is now an entity, it will not split up adjoining world geometry, nor will it affect vis. However, if a brushmodel gets too large, it can become a problem, especially if it straddles visportals. Also, brushmodels are rendered less efficiently than world geometry, so you will see an increase in polycount. I generally steer clear of this method, although I use it in a few instance in Marcher, such as for the torches in the upper cavern, where they butt straight into the terrain brushes.

.mdl models, like my tree in Marcher are most definately your best bet when it comes to those kinds of mapmodels - mainly for the fact that it would be very difficult to create that structure using brushwork, compared to how relatively easy it is to model it in a 3d app. 

Regarding your QC question:

Well, if that really is the only distinction between the two ogre qc files, then the compiler will abort if it finds any redefinition of the same function (i.e. two functions sharing the same name). If you want a quick and dirty method to rectify this, just change all the function names in your second ogre qc file so that they are unique.

A better solution would be to let your second ogre call most of the same functions as the original ogre, but with a few changes to implement the nail-firing attack, although you may find this tricky if you're completely new to QC.

Note that the entity classname you place in the editor is the name of the function called in the QC that spawns the monster into the level. Scroll down to where it says: void() monster_ogre = to get a feel for this. 

Your method won't quite work, if you attempt it, you'll get lots of errors about functions being redeclared. This is because although the functions are in different files, they will still have the same names, and this is a problem.

The solution is to rename all the functions in one of the files, replacings ogre by ogre1(if that's the naming convention you want). Probably the best bet is to just do a find and replace on the string, and then just correct a few things like the setmodel command - as I expect you want the two ogres to both use ogre.mdl. No doubt somebody will point out the gameplay problem with that in due course...

Then compile and with luck yo should be fine. One thing to note is that the name of the QC file doesn't determine what entity name you need to put in your map. You could call the second file banana.QC if you liked. The thing that determines the name of what you add to the map is the name of the function right at the very bottom of the file. If you've done all the renaming I told you, this will now be called void() monster_ogre1
This is the spawn function. Whenever quake loads an entity in a map, it looks for a function with the corresponding name in the QC. This function sets up the entity, gives it the correct model and behavior.
If you renamed this function to monster_ogre_nail, you'd have to add a monster_ogre_nail to your map.

(A kinda unnecessary aside here, read only if you're quite confident with QC and understood all the ideas above. Creating all these new ogre1 functions is actually quite inefficient! Most of the time, for walking and pain and so on, both ogres will use exactly the same code, just renamed. If you were careful, you could make it so that for all the functions which they do the same, like walking, pain, death, they in fact called the same function(ogre_pain for example), and only had different sets of functions for the firing sequences. You'd then just make two copies of the monster_ogre function, rename one to monster_ogre1, and set the appropriate line:
(for example)

self.th_missile = ogre1_nail1;

You could, of course, go in totally the opposite direction and decide that, given all these extra functions, you'll make use of them and completely rewrite the AI for the nail ogre, make it more agressive or something. But it's probably not worth it unless the nail attack lends itself to it rather well.

If none of that made sense or sounds rather daunting, then just rename the functions like I said and all is good)

Well, the aside is longer than the real post, but the idea of making lots of types of monsters simply by changing a few functions in the spawn function has grown on me while I wrote it. For example, to make a beserker monster variant that never goes into pain, simply set

self.th_pain = SUB_Null;

The mind boggles(or shrinks in horror!)