[Riddle solved] Problem with torchlight NOT influencing mtr-textures

While fiddeling with mtr to replces some vanilla textures (see according other post - Problem with replacing (some vanilla) tile textures via MTR (comes into being with version 80.8193.9)), I stumbled upon a (for me) new phenomene: I have this road texture set by a mtr (including a normal and spec map) and it won’t get influenced by - in this case - a torch light:

The other textures are still the default Bioware-Forest (ttf01) textures with no mtr additions and they are influenced.
What is causing this - or better - how do I fix this? (I hope, this was not asked to often before…)

Just in case someone stumbles upon this issue: This is related to the following topic:

So all answers regarding this torch issue (patch 8193.9-related) are to be found there.

I had this with a few textures I was experimenting with that I created with ShaderMap 4. It seemed to be that the issue was caused by ShaderMap using 32-Bit compression to save the textures. Converting them to JPG then back to TGA and making sure they were 24-Bit Uncompressed TGA seemed to fix the issue for me.

Also, was the tile compiled AFTER applying the alternate texture? If not, IIRC, models not compiled with the normal/spec mapping applied have this issue.

Thanks for your input! OK, I’m going to check, if the TGA were 24/uncompressed. I did not touch the models (as written in the linked post to this issue): My plan was to only add a HAK with MTRs, which replace vanilla textures (eg. the dirt road) and add N+S-maps and no models. It seemed to have been working for versions before 81.93.9 but “broke” (?) with this version.

Not sure what the answer is, but the bit size refers to the channels. In your picture above, the road should have an alpha channel, thus 32 bit. If you save it as 24, you lose the alpha.
A far a the black issue,
Check the exact spelling in the mtr, a typo in the maps can cause the model to look blackish.
If no typo, longer than 16 characters maybe ?

Thanks for the tidbit - I was unaware that alpha channel meant 32-bit. However, as the normal/spec maps don’t need alpha channels, wouldn’t they be 24-bit? Maybe its uncompressed vs. compressed?

OK, I tested again with ttf01_road01 - with the same result:
I exported the texture, which comes with NWN1:EE. The texture location is
NWN Texture Packs used NWN Explorer EE 1.83 to extract it. Export is as TGA - but I also tested with the unchanged DDS.

So this is/should NOT be caused by the texture!

This happens, as soon as I use an additional mtr-file, which contains “renderhint NormalAndSpecMapped”!

If I exclude “renderhint NormalAndSpecMapped” and just use “customshaderFS fslit_sm_nm // normal/spec mapped, sphere mapped”, the road shows up correctly.

So it’s “renderhint NormalAndSpecMapped”, which makes at least some vanilla tileset textures show up in this messed up way! I get the same effect, when doing this with the rual road (tno01_road01)!

As written at the beginning, it is related to this topic:

… and seems to be an issue, which starts with version 80.8193.9

I often use the tool DXTbmp and that exports TGA as Targa 32 Image - 8 bit Alpha
I never had NWN1-troubles, when using this tool. But for this 2nd test I didn’t use any custom textures.

EDIT: Soren posted a fitting answer to the “Problem with replacing”-post!