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. 

Hmm.. good point, it could be the order the lights are listed in the map file, and latest 4 types win. 

What's a standard in one bit of Quake isn't necessarily the same in another - I'm just guessing. 

Alright, I was just thinking I could push a bit harder on lightstyles. I seem to remember long ago as a noob, that warning simply created unlit faces... so since I didn't see those, I thought maybe engines made more lightstyles a thing!... It's not a big deal, I've already moved things around slightly and don't get the warning anymore anyway! :D

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.

That seems like a good and reasonably simple idea to implement, but in my case likely wasn't even needed... I was only slightly overlapping in the far ends of some delay 2 lights, so I didn't even notice which it randomly selected to discard. Likely could've even raised my -gate setting from 2 to 3 and fixed it. 

I put on my map thin brushes of vine textures with transparent background. Before compiling though I heard that a transparent texture has to have { as a prefix for it to work, so with texmex I renamed "swvine" as "{swvine".
I compile it with the "-fence" command in light, run it in Darkplaces, but the transparent effect doesn't occur: just big thin brushes with vines with a purple background. I thought this was a Darkplaces thing, because it couldn't handle Rubicon's transparent textures as well. So I run it in Quakespasm to see if it works here, turns out it doesn't work here as well.
What am I missing here? 

Those vine brushes are func_illusionary ones. 

 

 

 

You have the TGA with the alpha channel in the correct folder inside of Quake? It sounds like maybe it's reading from the BSP instead of externally...