[Gtkradiant] [Bug 397] New: shaderlist.txt (and default RTCW) behavior problems: solution?
Sun, 17 Feb 2002 02:29:25 -0600
Summary: shaderlist.txt (and default RTCW) behavior problems:
OS/Version: Windows 2000
Using the default shaderlist.txt file while mapping for RTCW MP (though there
aren't different shaderlist.txt files as far as I know?) I have come across the
need to edit it to bring in more textures. By using the default shaderlist.txt
file in GTKr, I was missing a lot of normal non-shader textures. After some
shaderlist.txt editing -- and finally disabling -- I saw a plethora of texture
options, and also some 'faults' in the editor for texture selection.
The purpose of the shaders are obviously to define your shaders. The shipping
versions of both QUAKE3 and RTCW proved that the shader FILENAMES are rather
different than the contents of the shaders they define. For example, the very
large walls.shader in RTCW doesn't contain shaders for textures/walls/* (as
shaderlist.txt seems to operate), but MANY MANY different shader 'directories'
such as textures/props/* and textures/assault/*.
In a perfect world I'm sure developers would put their respective shader
directory references in to the proper shader -- but this doesn't seem to be the
case. Currently shaderlist.txt forces mappers and modders to follow this
convention, but it limits their selection of base game content. As a result of
forcing this, when specifying select portions of the shaderlist.txt we lose
directories which contain images which are never defined in any shader. These
images become hidden for use.
How does disabling shaderlist.txt in the editor effect compiling if q3map scans
the shaderlist.txt for exact shaders to load? What if it is missing files --
Especially shaders for mapobjects?
By DISABLING the shaderlist.txt in the editor you are revealed two things. The
first are all the directory names for the textures, and the second are all the
names of the shader files. While a fraction of the shader files contain shaders
for their respective directory in RTCW, this isn't the case for the majority
and should be reevaluated (my opinion).
I would imagine the shader parsing to happen like this:
1. The directory structure of %base%/textures/ is recursively scanned, with
standalone images loaded as normal textures.
2. All .shader files in %base%/scripts directory are parsed.
3. Of the texture directories and shaders parsed, the texture menu is populated
with the directory structures defined by the textures and shaders which start
with textures/* (to avoid models and UI shaders, etc).
4. Duplicate filename/shader entries obviously default to their shader
As for this process working with mod's, we would simply parse the base
directory first, then apply the same technique a second time to the mod's %
base% folder, overriding any conflicting base-asset filenames / shadernames
with those in the mod.
The bottom line is that shader names should have nothing to do with the texture
directories. Defining the directories in the shaderlist.txt does nothing if you
aren't scripting shaders for custom textures. Defining the actual
shader 'paths' in shaderlist.txt does nothing if the name of the shader doesn't
match the path which is inside of it. Do we put directory names, shader names,
and shader paths all in the shaderlist.txt? A very limiting and complex system
for something that doesn't have to be...
My thoughts and opinions on the situation... This would greatly help the
maintenance and even simple mapping of RTCW, since out-of-the-box-GTKRadiant
doesn't give a mapper all their options...
------- You are receiving this mail because: -------
Whoops! I have no idea!