Send me the zipped map+wad and I'll take a look at it. 

I will do it this evening... I'm at my job office now, and till to 17:00 ...

Thanks again for your help... 

This is probably one for you:-

I have a sealed i.e. no leaks, map of 2600 brushes. I do get several Cut_Node_Portal erros but the map runs fine in its own right.

I have a second sealed map of 600 brushes, which again runs fine in its own right.

So I import smaller map into larger map and get a leak through a solid brush when building Hull 1.

I have changed the brush concerned, overlapped surrounding brushes etc. The brush is one of many (terrain type triangles) on the 'floor' of the level but I have also added a large 'sealing' brush beneath the terrain to try to avoid the misaligned brush problems (this is not one of my large terrains!), which has been in place long before the import.

The only slightly unusual thing is that at present the imported map is entirely unconnected in any way to the larger map: I have imported it just to see how I can fit it in. I have not exceeded the world boundary - close to the edge but 32 units to spare.

If I delete the imported map (select Group and CTR X) without saving or reloading, I can immediately compile without leaks.

Bit long winded... any pointers? Anyone?

And I still have one more section to import! 

but maybe some kind of attempt to explain why it's happening. The compiler quickly translates all brush faces in the map file into infinite planes with a normal (perpendicular to the plane) that specifies direction and a distance from origin (0 0 0).

This pair identifies the plane and they're represented by float values (in my compilers 64 bit double precision). One can rather easily suspect that the more of these infinite planes there are in a map, the more risk of planes getting too close (i.e. coplanar) for comfort due to numerical inaccuracies.

I believe that this might be one reason why bigger maps sooner or later start to exhibit weird leaks or clipping errors. I know maps where it appears nigh impossible to get rid of these problems.

In your case, you have two maps that you merge together and both are terrain generated, which means many triangular faces and as I've mentioned before, this appears to be extra provoking for the compiler.

This is all only a theory, though; I can't substantiate it. Still I recommend to inspect the areas of the warnings and try to get rid of them, in my experience the warnings seem valid and should be corrected.

If you can't proceed, send me the map and I'll see what I can do. 

Thanks.

The build process for the enlarged map was:-

1. small terrain (honestly!)
2. then one self contained non-terrain map
3. then the linking brushes created on-the-fly in the new map
4. then the attempt to bring in the later map

Each map compiled ok on its own.

I think perhaps I will just release the terrain + one section as a stand alone 'quickie'. At least I can cram it with monsters and end up with a Serious Sam style arena fight at the end.

It seems that I am fighting a losing battle here with the limits of the tools ... I know "a bad workman blames his tools".

Trouble is, time is tight and I go in three weeks.

You're welcome to have first look as you have helped a lot over the last few weeks.

Thanks again. 

is moving the imported section nearer in than 32 units from the edge. I seem to recall having problems myself with brushes that close. 

... but no good. I am working with very little room left in the 4096 world-space as this has become a very 'flat' map. Ho hum, start map and three small additional maps then.

Two general questions:

How many units from the player can a generated sound be heard? I do not want the player to hear monsters being teleported in so am wondering how far away from the spawn site I need to set the trigger.

Can I switch off the monster-spawn sound from within the monster's .qc file? I cannot find a reference to the spawn .wav (r_tele5.wav?) in the .qc but has anyone tried this? Maybe it's hard coded in the engine? 

The function that plays ALL the teleport sounds is play_teleport() on line 282 in triggers.qc, so if you wanted to make ALL teleports (monsters, player) silent, you could just remove the contents of that function. (Or at the very least, comment away line 299, you might want to keep line 300 though...) 

Tusen takk!

(sum total of my trip to Hemsedal last Christmas) 

heh 

Isn't there a "silent" spawnflag on the teleporter? 

yes, but that only gets rid of the 'humming' ambient sound that trigger_teleports emit. 

Zerst�rer has a spawnflag for truly silent teleports. 

My last map suddenly run out of light.
What can I do?

light.exe
142entity - 130lights
+++ERROR+++
GetFileSpace : overrun 

if you're not, i highly suggest using aguire's light util, because it seems you have hit a limit which aguire's stuff probably removed. 

I deleted 16 torches, and the problem was solved. Could be something in the animated light count.

Never had the message before. 

tool, it must be a very old version < 1.14 (Aug 2002). Later versions have another more informative error message. 

at http://user.tninet.se/~xir870k . Main features are new attenuation formula (delay 5) and improved additive minlight in Light, engine matched validation in compilers and a new GLQuake engine especially made for mappers. Please also see readmes for more details.

Any comments are welcome. 

I'd like to start using GTKRadiant 1.5 but turning off 'Freelook in camera view' doesn't seem to work in the Preferences. Is it just me having that problem? 

What are the mapper specific features in your version of glquake? 

thanks man, this is awesome stuff.

first of all, the engine is a great idea. there are times when every engine i try to use packs up and leaves. i doubt i'll use it for much playing, because it doesn't look like you've made it any more efficient than the regular quake, and i doubt i'll make a map specifically for it either because of that, but this should help immensly with testing and such. at least now, when i hit a limit, i can keep building and testing while i try to figure out what's wrong as opposed to just stopping and searching and waiting and such. :)

also, i'm a big fan of delay 5. i didn't use many delay 2 lights in my maps after i started using fitzquake, because the overbright feature would make the lights way too bright, and i realised that this must be what it looks like in software... being able to specifiy a max light limit is great, and Kinn rocks hard for coming up with something like that. (but thanks for implementing it in your tools, aguire)

i haven't really experimented much with the new minlight setting though... i try to stay away from minlight as much as possible. :P

cheers on excellent work! 

like he said in the readme, there aren't really any features for mapper, the only feature is that almost all limits that would normally crash quake before even letting you see the map are bumped way up (ie: edicts from 600 to 2048)

it's not really meant for normal play or for mapping specifically for. 

one thing i forgot to mention, Aguire:
don't name your engine glquake.exe, because it's not meant to be a glquake replacement. glquakebjp is perfectly acceptable ;) besides, it makes unzipping it a pain, because now i have to unzip to another directory, rename then copy it into the quake directory. same me some steps, eh? ^_^ 

I have experienced the same problems. I've also reverted back to using the beta 1.3.11 because I find the changes in the interfaces of the newer versions iratating and counterproductive to what I try to accomplish. 

The "GLQuake Mapper version" just means that its focus is on loadability and viewing of large troublesome maps.

Since mappers at one time or another create maps that indirectly (e.g. via leaks) or directly exceed normal engine limits, I hope this version is of special use for them.

It's not meant as a replacement for FitzQuake or other engines, just a complement.