thanks, that is great. Which tools did you use? I think tyrutils-ericw, original tyrutils, and rebb's txqbsp all have the same behaviour for detail.

For big cave walls and such I'd prefer to have a vis table that properly treats giant func_walls as spanning multiple leaves, so there's no danger of them flickering or vanishing from the wrong vantage points.

Yeah, that's purely up to the engine, since the table of leafs an entity is spanning is calculated and updated at runtime, in the server.
The original (problematic) behaviour was, if an entity spans more than 16 leafs, only the first 16 of those are used to compute visibility. I think most engines nowadays extend that table size and/or handle exceeding the table size by making the entity always visible (QS does this), but it is something to keep in mind. 

I recommend some folks check out jam6_scampie or ad_necrokeep with "r_showtris 1" and "notarget"... the way vis seems broken in this map is that certain brush entities (func_wall and func_illusionary and some func_doors) are visible at all times throughout the map. I suspect it's detail brushes which are the culprit, but I'm not exactly sure how! 

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)