|
|
Really? I'd have to check the code, but I think a shadername-only replacement is actually what the code is doing as well. Maybe there are problems with differently scaled textures? This might be worth investigating, which shaders have been replaced by what? |
|
|
|
When I ran into this at home, I was using the same exact texture (now on SVN as door/wood/arched_heavy01), but with a different name. Basically I worked it up with a local/nonsense name, then, when I was ready to commit it, I gave it the official name and created an official material entry. I then "break" the nonsense name intentionally, and do a swap, as one final test of "is this package ready to submit to SVN?" (i.e., if the new material def works in the editor and Doom, then I haven't forgotten anything). When I tried DR's Find & Replace, swapping the nonsense name for the real name, it gave me bad orientation (it was flipped back to normal, and scaled way up). From notepad when I tried the same, it was a perfect 1:1 exchange, so something must be weird somewhere.
|
|
|
|
So, when the map was loaded, the nonsensical shader was already gone and the blue/black "shader not found" was displayed, before you ran the Find&Replace routine? |
|
|
|
Yep it was, but the scaling was still applied. The "Shader Not Found" image was fit nicely on the brushes in question. In fact, the orientation must have been saved, because the notepad S&R worked perfectly. |
|
|
|
Issue should be gone in fd1a004071eb1413b2336e2f36c3cd3ecb687b6f |
|
