Brush content priority patch, a solution to the 'content lottery'
version .1 April 29 2005

DISCLAIMER: All the provisions of the ydnars q3map2 disclaimer,
found at http://www.shaderlab.com/q3map2/2.5/readme.txt apply.
In addition, you shouldn't blame ydnar for any bugs I have added,
or expect him to support them.

Author: reyalp (reyalp@gmail.com) 
You can also find me in #wwgn on gamesurge or #splashdamage on quakenet

Problem:
Some shader keyword (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>

where N is a signed integer, specifying the priority of sides using this
shader. If not specified, the default priority is 0. q3map2 will use side
whose shader has the highest priority side to set the contents (and other
shader specified brush attributes) of the brush. If the highest priority
exists on more than one side, the first one encountered will be used (mimicking
the old behavior). If no side specifies a priority, then everything will
work as it did in previous versions.

Examples:
Suppose you want to make a fence, where one face uses fence texture, and the
remaining 5 sides are 'clipped' with missileclip. If you create a missileclip
shader with
q3map_contentPriority 1
then you do not have to worry about the content parameters of the fence
shader. This prevents your fence from randomly changing contents, and saves
you making shaders for all your alpha textures with different clipping
options. Instead, you only need one set of high priority clips.

Another common situation is to want to have some faces of a water brush
non-drawing. If you create a nodraw shader with a content priority of -1, then
you can safely use this on your water, without affecting its liquid state.
(This example is somewhat contrived, since it wouldn't be any more work to
make nodrawwater, but it shows what you can do with a lower-than-default
priority.)

Since it is a compiletime only option, you can safely modify your existing
common shaders, although it might be a better idea to create a set that show
the priority clearly in the name or editor image. Anyone compiling the map,
will of course have to use a version of q3map2 that understands this option.

A couple of examples are included in prio.shader

You can use priority values other than +/-1, but in general, this isn't
likely to be useful.

Installation:
Use the included q3map2.exe in place of your previous version. If your q3map2
was old, you may need some .dlls, which can be found in the latest official
q3map2 distribution, at http://www.shaderlab.com/q3map2/2.5/

If you are on a non-windows platform, you will have to patch and compile
yourself.

The patch:
The patch was created using subversion, and should work with most patch
utilities. You may have to convert line endings. You will also have to figure
out how to build q3map2. Source is available from
http://zerowing.idsoftware.com/ via subversion https://zerowing.idsoftware.com/svn/radiant


Big thanks to ydnar, id, and the gtkradiant team.

