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... 

I need to know more... 

Basically, the "{" tells the game engine to go read an external texture rather than using what's in the WAD file. The texture in the WAD has none of the alpha channel information in it.

I don't know the specifics, someone else will I'm sure, but you need to have the proper TGA file complete with alpha channel somewhere that the game engine can see it for loading. 

you don't need to use -fence, that is a light compile only thing for it to try and cast shadows based on your cutout textures.

alpha cutout textures simply need a few things to work: { prefix on the name of the texture; it needs to be applied to an entity (func_wall, func_illusionary, etc); and the parts which are going to be invisible need to be palette color 255. You don't need to compile specially, the engine is what does the work.

did you grab {swvine texture from the arcane dimension start map (or any AD map that used it)? if so, you should be all set, it would've been named correctly... open the compiled .bsp in texmex and be sure the texture is renamed, I suspect you've likely messed something up there either in the .map or in your .wad. Did you remember to change the brush in your map to the renamed texture?