I posted this over on the q3map2 forum, but it might be of interest to some people here as well.
http://www.splashdamage.com/index.php?n ... ic&t=11906
Problem:
Some shader keywords (such as nonsolid, *clip, liquid, and so on) affect the contents of a brush rather rather than just a given side. Since shaders are only specified on brush sides, this raises the question of which side specifies the brush contents. In past version of q3map (and q3map2) the 'first' side of the brush was used. Unfortunately, which side is 'first' is not under user control and tends to change every time the map is saved.
Solution:
This patch adds a new compiletime shader keyword
q3map_contentpriority <N>
See the post on SD for full details and download. Be warned that I have only tested this briefly (works for me (tm)) and, although this change is pretty simple, I'm not intimately familiar with the guts of q3map. You have been warned!
Bug reports or general feedback on the idea would be appreciated. If the idea is well received, I'll try to get it into the official distribution.
And BTW, good to see some life around LEM again. My old account (SCDS_reyalP) seems to have gone away, but I was an occasional poster here in the past.
experimental q3map feature: brush content control
If you mean having the contents change because you have, say nodraw on a side of your fog or water brush, yes. If that isn't the problem you are referring to, maybe you could describe it in more detail.Kat wrote:interesting.. so I guess this solves (at least in part) the old fog and water brush problems?
My change only affects which side of the brush is used to determine the contents. It is exactly the same as it would be if the side with highest priority shader happened to be the first one in the brush. It doesn't let brushes do anything they couldn't do before, it just makes it possible to mix shaders with different content predictably.
In theory, it should be possible to make q3map specify a content shader that has nothing to do with any of the brush sides, which might also be interesting. The main obstacle I see to this, is where exactly would you specify it ? Neither the shader file nor an entity key would be completely satisfactory.