You need two spike traps firing at the trigger, and two doors. Just offset them at different angles so it works.

A NOT gate would be trickier but doable as well. Have a door block the path of the nails when triggered by the undesirable trigger. 

Your idea is almost there, Shamblernaut: For that to work completely you have to do it so each door blocks the other door's path of the spikes, so it doesn't work as AND too and only as OR.

So you end up with:

Rest: 1 trigg 2nd trigg. both trigg.
� � � � � � � �
� - � - - � - �
- � - - � -
� �
T T T T T T T T 

I repeat it:

Rest pos.....first trigg...2nd trigg...both trigg.
������������������������������'�������
��-����''�������-���'���-������'''���-��
-������'�������-���'���-������''�����-
t�t����''�����t�t���''���t�t����''���t�t

I am hating the fact that kerning is only applied to the posted post and not when writing. Took me a while to make the columns to stay aligned. 

http://lunaran.com/files/visdetailtest.zip

(see celephais.net/board/view_thread.php?id=61207&start=184 ) 

R.I.P. vis in natural cave type maps I guess. 

Here's the pair of articles on how to do "instant activation" logic gates:

https://tomeofpreach.wordpress.com/2013/05/13/new-logic-gate-design/

https://tomeofpreach.wordpress.com/2013/05/15/new-logic-gates-part-two/

There's some bonus content added today in the latter post: I've added the template .map files for the gates, only 32 months late! 

This is only if the detail brush seals the world face away. If the detail brushes are simply floating inside a world cube, this should still block vis?

Vis would see past the detail but stop once it reaches the box behind it? 

If it's not cutting into the structural brushes, it shouldn't be any problem at all. It's only when a detail brush completely covers and eliminates a structural poly that you run into trouble. 

Yeah. And that fudgy sliver space can be skip textured so you don't waste triangles and lightmap space (if that's a concern to you).

Still seems like a counterintuitive workflow, though, having to leave a gap where a gap would be totally the wrong thing to do in all other cases.

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. 

From your description, what you're proposing is an xor gate (either, or, but not both). I think the original question mentioned that the trigger should also be activated when both conditions are satisfied. 

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