[Gtkradiant] [Bug 397] New: shaderlist.txt (and default RTCW) behavior problems: solution?

[gtkradiant@zerowing.idsoftware.com]

http://zerowing.idsoftware.com/bugzilla/show_bug.cgi?id=397

           Summary: shaderlist.txt (and default RTCW) behavior problems:
                    solution?
           Product: GtkRadiant
           Version: 1.2.1
        OS/Version: Windows 2000
            Status: NEW
          Severity: normal
          Priority: P2
         Component: editor
        AssignedTo: ttimo@idsoftware.com
        ReportedBy: js@mindgrid.net
                CC: js@mindgrid.net


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

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

.jer



------- You are receiving this mail because: -------
Whoops!  I have no idea!