(shouldn't that be leaves?)

So there I am, happily polishing my effort for the SM40 contest, when all of a sudden I get 'Vis leafs 8684 exceed normal engine max 8192'. Bugger!

During this latest bout of polishing I have added about 12 brushes. I haven't seen this message before on this map so am somewhat surprised.

Am I right in thinking that vis_leafs are 'the sides of brushes that face into the map that a player can see'? For simplicity, I am assuming that we have a hollow cube and that it is made of six brushes, resulting in 6 vis_leafs. Each brush is six sided in the .map file but the player can only see those sides that are 'inside' the map when it is played i.e. the six inside surfaces of the wall, ceiling and floor.

I know about func_walls (from earlier posts) but my most numerous brushes that fit my simple scenario are all cave walls and ceilings. If I turn these into func_walls and place brushes outside of these to seal the map, am I likely to get some success in reducing vis_leafs?

I don't seem to get a vis_leaf count unless it's a problem and I have 5500 brushes in this map so I don't want major changes unless I need to.

Any suggestions? 

well, i don't know tons about this subject, but vis_leafs isn't the visible surfaces, that would be surfaces and marksurfaces i think.

anyway, i think the simplest way to reduce vis_leafs is to reduce the complexity of the vis data, so, for example, convert sticky outey bits into func_walls. 

The most common cause for that warning is a leak. Assuming you've already checked that, the "vis leafs" is the first of the two values that vis prints out at startup (can also be read from the prt file), the other being the portals.

AFAIK, a vis leaf is an empty volume inside the map that the player can theoretically be in, regardless of size. Each leaf borders either to solid faces or other leafs via portals ("doors" between leafs).

The more complex a map, the more leafs/portals there'll be and the longer vis will take processing it.

Due to a bug in most engines, the max # vis leafs is limited to 8k, otherwise the stack will be trashed and the engine will crash. This is one of the most common causes for an engine crash and it usually happens when trying to load a big leaky map.

In my engines, I've upped the limit to 32k and added a protection for amounts beyond that. Like necros said, try to reduce complexity to get down vis leafs. 

I want to ask a question that I wanted to ask a long long time ago.

How to make trigger_shooter work as trigger_spikeshooter? I mean it should start to shoot when player enters the trigger zone and stop to shoot when player leaves the zone of the trigger that is targeted at shooter.
So far even if I give it a targetname it always shoot, no matter where the player is. 

have you tried calling it a trap_spikeshooter? 

pulsar - although i've never used shooters before, i'm just looking at the QC, and they seem simple enough. Just hook a trap_spikeshooter up to a trigger_multiple (with "wait" set to the time between spike firings) and bob's your uncle! 

OK, something going on here that doesn't make sense to me.

I spent the morning clearing leaks: the map had all of its major brushwork in place and up to this point I had been using -nofill in Qbsp. I then ran Qbsp normally (about ten times), using each generated .pts file to clear all leaks and eventually running a quick vis all without problems.

Only then did I add my dozen or so brushes, all inside the sealed map. Does this mean/suggest that these few brushes pushed vis_leaves over the top?

I have since changed 200ish brushes to func_walls to see if this would make a difference, and it didn't.

Right now, I intend to retrace my steps from the pre-leakcheck map to see if I can recreate the problem: of course, I can't get the vis-leaf count as I go as I have leaks. Is this Catch22?

Anyway, thanks for your input. 

I understand what I say, I know that.
It seems I need to explain it more: trap_spikeshooter works exactly in the way you described, but it shoots too fast. It hard for player pass thru it without getting damage. Trap_shooter shoots slow (as I want), but it shoots always and triggering it just makes it to shoot faster (like trap_spikeshooter does).

So I want to know if it is possible to make it start to shoot only after triggering it and not from the time the has been loaded. 

the has been loaded.
the map has been loaded. 

I take it you are using a trigger_multiple to trigger the trap_spikeshooter, yes?

Just set the trigger_multiple's "wait" field to the time you want to elapse between spike firings. The trigger_multiple's default wait is 0.2 secs, so if you don't set it, the spikes will be launched at a rate of 5 per second. 

I haven't thought about it in a such way. I'm going to check it right now. 

AFAIK, you'll get the vis leaf warning also when the map leaks (which is the normal reason why the amount is so high). Having a sealed map with >8k leafs usually means >24k portals and then you'll have a fullvis nightmare ...

If you can't sort it out, send me the zipped map and I'll take a look at it. 

I have this 'system' that I use when working on a map: I compile regularly (like every 15 minutes) using Qbsp -nofill, and Light, which also saves the work done so far. Every so often I will save the WIP with a new name, in this case SM40_mw1.map, SM40_mw2.map etc. Occaisionally, I will try some major change that I am not sure about and will use the file test.map so if it doesn't work I can just dump it and continue where I left off.

So, I am moving a piece of terrain that is on a grid of 1536 x 1536 x 768 - this is big so I use test.map to try it out first. It's a success and I am so pleased that I continue leak testing (post 2969 above) and resolve every leak. Then I go and have some lunch.

When I come back I load the last map (SM4_mw9.map) and continue polishing. I add my 12 extra brushes, compile and... get the vis_leaf problem. WTF, it worked before lunch? But of course as we all know now, the last map I saved was called test.map and had all of my leak fixing in it - I had forgotten to save it with the usual series name.

Oh well, at least with the system I use, when I retraced my steps back to the last good map and then worked forward, as soon as I got to the need to move the piece of terrain I realised what had happened. Only wasted a couple of hours and now back on track, no leaks, full vised, so polishing continues.

There's a moral there somewhere... 

The moral of the story is: mapping editors need a built-in database system for tracking changes. Something like CVS or Subversion (which are used for tracking changes in big software projects). 

There's a moral there somewhere...

Always Backup Your Maps*










*even if you are easy to confuse 

I am getting to the phase where I should be adding gameplay to apinaraivo.bsp and I am in need of QuakeC help. I need to port the Mega-Enforcer for Zerst�rer and something from Scourge of Armagon over to the ID sources. If anyone would be so kind as to do this for me (should be pretty trivial for a person fluent in QuakeC, which I am not), please get in touch. My eternal gratitude is assured. 

What the heck, I'll sort you out ;) What is it you need from SoA exactly? 

I sent a email to the address mentioned in your profile. 

sorry - could you resend to:

bdwooding - at - gmail - dot - com

thanks :)

/me needs to update his profile 

[nt] 

Have you received my last three emails? 

don't worry, I'm getting round to it (blame christmas ;) 

Just for kicks, try compiling the hipnotic sources with FrikQCC, put a monster_scourge into a map (the mechanical scorpion from SoA), compile and run the map. Notice how after dying, no centripede doesn't have any death animation whatsoever and just "stops" with his body becoming non-solid (as in, you can walk through him). The original hipnotic progs,dat file however, works just fine.

After pulling my hair out for an hour, I realise that what we have here is a bug in THE BLOODY QUAKEC COMPILER! I downloaded some bizarre ProQCC release from 1997, it compiled the code and everything worked as advertised. Ugh. 

I'm currently making a quake sp map and Im quite confident I will finish this as alot of the structure is in place.

Having never really got this far when creating a map, it leaves me not too hot with entities so here goes..

I want two doors to open reveiling a monster behind each (already in place), but I want the doors to only open once the four monsters that your fighting have been killed.

Secondly I want a button to trigger a door open only once two of the buttons have been pressed, I've seen this in some maps and it has an on screen message "1 more left".

Also one other thing, is it possible to make a monster or a set of monsters "spawn" as you pass over a trigger or a button?

If anyone could shed any light over these I would be most greatful. 

I want two doors to open reveiling a monster behind each (already in place), but I want the doors to only open once the four monsters that your fighting have been killed.

Secondly I want a button to trigger a door open only once two of the buttons have been pressed, I've seen this in some maps and it has an on screen message "1 more left".

You need to you use trigger_counter. Create a trigger_counter, give it a targetname (counter1 for example), fill the 'count' field with the number of monsters/buttons you need to activate it (4 (monsters) or 2 (buttons) for you), and then fill the 'target' fill as for usual trigger. Then target buttons or monsters to that trigger (for example 4 monsters should have 'target' field with 'counter1' value.

Also one other thing, is it possible to make a monster or a set of monsters "spawn" as you pass over a trigger or a button?

You need to create a room somewhere, place monster there, cover him with trigger_teleport and give this trigger_teleport any targetname. Then target your trigger or button to that teleport.

I hope it's clear.