q3map_surfacelight keyword is ignored

[frederickbrown]

q3map_surfacelight keyword is ignored in newly written shaders, resulting in a surface that just appears as a regular surface without emitting any light. So far I know this only happens in the 32 bit version of q3map2. How would I get VS 2015 to compile the 64 bit version to test?

[Mateos81]

Have you run a Flush & Reload shaders? If you've restarted Radiant meanwhile, it has reloaded the files, so in order to test this, have the shader with the line commented out, start Radiant with your map, then edit the shader and perform the command through the Textures menu IIRC (I don't have Radiant at work :P).

If you select x64, it should build the x64 version of Q3Map2.

[TTimo]

32 bit radiant can run the 64 bit q3map2 - that's probably configured in preferences

[frederickbrown]

Just to be sure I tried flushing & reloading the textures. the surface light keyword is still being ignored. Note this only happens with custom written shaders. The surface light shaders that are in the pk3 files still work properly.

The q3map2 64 bit executable for the x64 folder is failing to get built in the latest master branch. Radiant defaults to using the 64 bit version, and when one attempt to compile a map with a newly built radiant, there is an error message about radiant failing to find the q2map2 in the x64 folder. Then if that preference is unchecked, the 32 bit q2map2 executable runs just fine.

I tried to do a transplant of q2map2 from a version of radiant that did compiled my custom surface light shaders properly into a version of radiant that failed to do so, and the problem remained. So, it might be somewhere other than in q3map2. I should probably do that again just to make sure.

Ingar's NetRadiant latest build handles my custom surface light shaders properly, as does the last GtkRadiant-1.5 version.

[ensiform]

Does your shader exist in shaderlist.txt, if not it may not be detected as a shader.

[frederickbrown]

Yes, my custom shader file is listed in shaderlist.txt, and GtkRadiant 1.5 and Ingar's NetRadiant both compile it as expected using the same files and directories.

[ensiform]

Well, NetRadiant is also based on 1.5 so that's a good reason why it works on NetR+1.5. If other shaders that work besides yours that uses surfacelight, it sounds more likely that it isn't detecting the shader either in radiant or q3map2.

Is the path to the shader within the file the same as the filename? Like:

blah.shader =>

textures/blah/something
{
...
}

[frederickbrown]

Yes, that's my conclusion as well.

[0bsidian]

Do not include the .shader extension in the shaderlist.txt file. It should be just listed like:

base gothic liquids skies blah

[frederickbrown]

What part of both GtkRadiant 1.5 and Ingar's NetRadiant compile my custom surface light shaders as expected using the same game files and same game directories are you guys missing?

Obsidian, I was talking with you earlier about this on one of the forums. I drove myself nuts for about a week trying to figure out my error in writing the shader before I finally figured out it was a problem in Radiant.

shaderlist.txt textures-custom.zip scripts-custom.shader.zip

Here are two maps. The first map 013-custom-shader is with a surface light shader I wrote. When I compile the map and view in with the ioquake engine the room is pitch black.

The second map is the same map with only one surface of the light change to a surface light shader from pk0.pk3. When compiled it has room illuminating light radiating from the surface of the light.

013-custom-shader.zip 013-pk3-shader.zip

The two other programs I mentioned compile the first map just fine with radiating light using the same files in the same directories viewed by the same engine.

[ensiform]

Seems you updated with more stuff.  Might have been helpful to have these to diagnose in the first place.

I'm assuming you've tried with something named other than "custom" ? There's a possible chance something else is also "custom" and could be a difference in ordering in the filesystems. Just throwing out ideas.  As I'm quite certain q3map_surfaceLight didn't just stop working especially since it still works for base shaders.

Hopefully someone can reproduce with your files above.

[frederickbrown]

The custom shaders I wrote are in the "custom.shader" file, which is listed as "custom" in the "shaderlist.txt" file.

Maybe, I should have done it this way in the first place. Here is custom.pk3 in a zip file because the web site will reject pk3 files. So, you unzip custom.pk3 and drop it in your baseq3 directory, and then you should be able to open two maps, custom-shader and pk3-shader. The only issue is if you have a another pk3 file that might over write the shaderlist.txt I included.

In that case you will have to add "custom" on a line in your shaderlist.txt.

custom.zip

Is that better?

I should have named the pk3-shader.map pak0-shader.map, anyway I think you should have the idea by now. If you compile custom-shader.map with the latest from the master branch you should end up with a pitch black room. If you compile the pk3-shader.map with the same you should have an illuminated room. Now if you compile custom-shader.map with GtkRadiant 1.5 you should end up with an illuminate room.

It's almost as if the build from the current master branch program is only reading script files from the pk3 files in baseq3 and ignoring the baseq3/scripts folder and files. Also when I noticed this I had all my custom files in baseq3/{maps, scripts, textures} and nothing custom in any pk3 files.

[Garux]

What i see is, that your most likely to be meant custom shader textures/custom/custom_white_light is completely commented out

[frederickbrown]

Yes, thank you for that. I just uncommented it and tried again and it worked.

I was having a lot of trouble with this and trying it on several different gtkradiant and netradiant versions in a variety of ways. I guess lost track of what state I had the shader in with with this last version of gtkradiant which I was prevented from working with earlier because of the camera port problem.

So, the shader problem is actually non-existent with this version. That's a relief.

I'll get back to mapping now... :)