[Gtkradiant] [Bug ???] Textures menu a bit too long

[jeremiah sypult]

> This is completely off-topic with bug #435
>
> The shaderlist system in Q3 works on the assumption that foo.shader files
> match foo/ directories, and that a foo.shader file won't try to provide
> code for shaders that are not in the foo/ directory.

You are correct with everything above, EXCEPT that you explained how it
works between q3map and Radiant, and NOT the Q3 renderer. Q3map and Radiant
are more stringent in the consistency between foo.shader as a filename,
shaders contained in foo, and textures associated with textures/foo/bar.tga.

Q3 as an engine doesn't care about the file names. Every shader could be in
one shader file and it would render everything just fine. It's the shader
names that matter.

> The naming as town_wall / military_wall / xlab_wall is a shortsighting on
> GM's side as it doesn't follow Q3's implicit conventions. And it breaks
> sub menu cascading, whereas wall_town wall_military wall_xlab would have
> worked just fine.

It is only a shortsighting on GM's side when you use GTKRadiant to edit the
game.

> If there is something that needs to be changed, I don't consider that
> there should be a design shift on Radiant side, but a cleanup of the Wolf
> shaders. 'walls' for instance has to be taken into seperate
> town_wall.shader town_military.shader and xlab_wall.shader pieces. You are
> absolutely welcome to do those changes and provide some patches.
>
> As Astro made the current version of the scripts we use, I'd be curious to
> see what he thinks about this (on CC here)

I'm not trying to start a flamewar about how the editor works with shaders
or anything... Maybe I just see things as being simpler in the long run if
the editor handles it EXACTLY THE SAME as the engine.

THAT is exactly what I explained in bug #435, how the engine loads shaders
compared to the editor. The only thing I raised a flag about is why the two
were handling shaders differently. Back when the first version of Q3Radiant
they were the same. There wasn't the need for shaderlist.txt in the original
version of the editor.

Why maintain a new shaderlist.txt file when you can just read the scripts
directory and get all the .shader filenames?

Why clean up the developers shaders for file consistency when they obviously
compiled AND work fine in the engine?

Why complicate the BASE development environment by having shaders in both
the game pk3 files and an entirely different set of shader filenames. By
changing the shipping version of the shaders, you put the entire games
rendering content at risk of error. Activisions quality control has already
done their job in making sure every shader renders.

If the code loaded shaders the way the engine does, you save work in the
long run in ALL QUAKE3 ENGINE titles. /THAT/ is my only point. No need to
overhaul a shipping products scripts when they work fine in the first place.
As it stands, Radiant as an editor requires the BASE content to be modified
to edit it approriately, and I feel that is a bad decision for many reasons.

If you look only to Astrocreep for answers in how mappers work with shaders
and how the editor should handle shaders, then I'd love to discuss this with
Astrocreep.

Again, this is just my perspective of how it could simplify editing,
managing, configuring, supporting new games and help keep original game
shaders from getting changed. Is that such a bad suggestion?

Regardless of my point of view, the editor is still great and I sincerely
appreciate that it is still being maintained. This is the only thing I can
think of that would make it 'better'.

Take this all as you will...

.jer