those bmodels just stretch over 16 leafs, and therefore get drawn all the time. 

I just looked at ad_necrokeep, I see what you mean in Quakespasm - that's a side effect of the flickering prevention fix.

If you load the map in fitz085 with r_showtris, those entities won't show up when you're not in their PVS, but they are probably in > 16 leafs so there is a chance they will flicker in fitz.

So - the map itself is probably fine. 

oh. ok yay :D 

txqbsp_xt.exe 1.13.

I detail-brushed ad_necrokeep pretty aggressively (all the slanted brushes in every archway, lots of stairs ... the entire central spiral stairway and tower is one giant func_detail) without knowing about this limitation. I didn't do any of the cave walls, solely because I'd already gotten vis times low enough to make me happy. Good thing I stopped there, I guess. 

Yeah, i confused OR with XOR. 

Cocerello, I don't understand what your table is showing. Is it some kind of input-output state for the gate? Can you explain it to me? Thx! 

OK

The ''-'' are the doors, the ''�'' are the spikes flying downwards to the triggers, which are the ''t''. Ignore the rest of symbols, are just fillers to make the columns align.
There is two columns because there is two spike-shooters and two triggers. 

I've finally set up a test with spikes shooting a button. When the spikes keep shooting the button the door triggered by the button (let's call it the main door) keeps opening and closing like if the button was toggling it. In its parameters the toggle flag is off. 

then the toggle flag and triggering how often you want it is the way to go i'd say.
If not set wait to -1 on the door and remove flag 4. 

Needs to close but only when triggers stop triggering. 

You need wait -1 and the toggle flag together.

The -1 stops it closing automatically, and the toggle makes it change state each time it is triggered.

You may need to add another button to your logic setup to retrigger the door. 

But that sounds like the door might stay open forever if the triggers stop triggering at the wrong moment, won't it? 

They all keep getting hung up on the edge of each brush. I tried solving the problem with a clip brush and then tried setting that clip brush to a func_wall. Neither method worked. What gives?

Rough image of problem.

http://i.imgur.com/KP8UDU6.jpg 

Use skip func wall. 

Is there some trick to lighting door edges that are initially closed? I have some bars that block an area. When the bars open the edges are black as they are flush against a solid brush when light.exe does it's thing. I've tried all kinds of light positions in and out of the brushes. Any pointers appreciated. 

per entity minlight 

 

If possible, change the solid brush that's blocking the light to something that won't. I use func_wall for that a lot. 

Thanks guys. Totally forgot about per entity minlight as I've never used it up to this point. 

How safely can I ignore 'Warning: Too many light styles on a face...' in this day and age?

I know exactly where it occurs in the map I am fooling with atm, but it doesn't seem to have a problem in FitzV... have engines in general upped how many lightstyles can be on a single face? Or should I really not tempt fate here? 

I think it's safe to ignore, it's not a usual "limit exceeded" message where the compiler is writing something that vanilla engines won't handle. The limit has always been 4 lightstyles per face, and that warning just means that your lighting setup generated more than that, but the compiler discarded some of them.

The only reason to be cautious is there may be lighting artifacts, because the lightstyle picked to discard is random (at least in tyrutils). It would probably be better if the light tool sorted the lightstyles by average brightness and discarded the one that contributed the least, so it would be less noticable. 

AFAIK it doesn't cause any b0rkage. Just those particular faces respect the earliest animated source in the hierarchy.

In engine terms it basically means how many light maps is in your level - each change in light level is a new one.

I suspect the reason that this hasn't been 'fixed' is because what would the fix be... apart from dynamic lightmaps. 

it's not obvious, but regular non-dynamic lighting counts as one of those 4 lightstyles.
So, for each face you have the ability to have 1 static + 3 dynamic lights casting onto that face. (I think if the static lighting is pure black, you can use all 4 styles for dynamic lights - heh) 

So its not in sequence? I kind of assumed there would be some deciding (ie. predictable) element to it. 

Yes, Mh did a lot of stuff with RMQe to try and solve this. We, the mappers, were basically a baby throwing its rattle out of the pram.