[LE] CK will not stop looking for invalid texture

[Darklocq]

This is driving me nuts.

 

I apparently had a typo in a texture path at some point, and had "textures\actors\character\Mango\Chinese UNNP\phototex.dds" when it should have been "textures\actors\character\Mango\Chinese UUNP\phototex.dds".

 

Every time I try to render this NPC in the CK, I get:

TEXTURES: Texture Set missing texture textures\actors\character\Mango\Chinese UNNP\phototex.dds"

and an "abort - retry - ignore" from the renderer, then the two follow-on errors about the missing map and the bodypart missing a map (this seems to be a consistent series of events any time the CK's decided a texture is missing).

 

 

However, the associated NIF file has no such invalid path in it any longer. And this invalid path does not appear in the ESP. I have dectuple-checked this. I've been trying to fix this for TWO DAYS. It just will not stop looking for "UNNP" no matter what I do. Where on earth is it getting this from?

 

The only things I can think of are a) that this path really is in there somewhere (but where??), or b) that the CK caches stuff long-term and is highly resistant to letting go of what it's cached, or c) the fact that an instance of this NPC has been placed in the game world "locks in" every bit of data like a texture path so that it can't be changed without nuking the in-world instance and adding another (something I don't want to do just yet, because it's been placed in a very complicated way I have not figured out how to reproduce yet).

 

I get the impression this invalid path is coming from the NIF side because of the leading "textures\"; in ESP language, that part gets dropped in a texture record and you just give "actors\character\Mango\Chinese UUNP\phototex.dds". (Then again, maybe the CK translates this into "textures\..." on the fly when reporting such an error. I really don't know.)

 

This has been so frustrating I've almost given up on the mod, especially since the CK just crashes pretty frequently after putting out these errors (and it takes a really long time start back up and reload the ESMs and ESP).

[JonathanOstrus]

Perhaps I'm missing something. But isn't it telling you that there's a "Texture Set" record that is messed up? Not the path in the nif, but a texture set in the esp. Either that or the error is misleading. In CK they're found in Miscellaneous | TextureSet. I have no idea what you might have named it but you would know better on that. If that doesn't help, using xEdit to check it might make things easier.

[Darklocq]

Except texture set record in the ESP is NOT messed up. Like I said, I've checked it in the ESP and in the NIFs over ten times.

What I've figured out so far, through trying everything over and over and over, and screaming a lot and breaking things, is that it seems to be a NIFskope bug. I'm using NIFskope 2.0 (2018-02-22) x64 in Windows 10.

When I open the NIF and go to the record that the CK says has "UNNP" in it, it does not (visually, in the NIFskope interface). It says "UUNP", as it should. If I make it say something else (anything else, via a manual edit to that path, not a copy paste), the click away from that editing field, then re-edit that path to make it say "UUNP" again, the issue in the CK disappears next time I try the ESP and these NIFs in the CK. No other change is required (and nothing else works).

It turns out that if you copy-paste a path\filename into a texture record line in NIFskope, it may not actually be recorded properly. This is how I got those paths in there, since they're long and tedious and I was applying them to something like 30 NIFs for BodySlide.

You have to actually edit the line in some way by manual keystrokes, and exit that line cleanly (e.g. by clicking on something else in NIFskope, like the next texture record down or up), and you have to make an actual change. Otherwise, NIFskope just ignores what you were doing in that record. I tested this. If you change it to to "ZZZZ" or whatever then back to "UUNP" without first exiting the edited texture path, and do this to every texture path in the NIF, then NIFskope will just close the file without prompting you to save, because it thinks nothing was changed.

In my case, I just went through them all and changed things like "textures\actors\character\Mango\Chinese UUNP\phototex.dds" (or whatever – maybe "...\phototex_n.dds", depending on the line) to "textures\actors\character\Mango\Chinese UUNP\XXXphototex.dds" (or whatever), one after another, then went back and changed them all back to "textures\actors\character\Mango\Chinese UUNP\phototex.dds" (or whatever) then saved the NIF, and it finally worked properly.

So:

* You can't reliably paste a path\filename or part of one. NIFskope will DISPLAY this change to you, but does not properly save it.

* If you edit the line that looks right but which is showing up in CK wrong, and set it back to what it should be then exit that line, it WON'T fix it. You MUST edit the corrupted line twice. Once to introduce a dummy change, and once to actually set it to what it's supposed to be (and regardless whether it looked correct to begin with, if the CK is reading something different).

* It SEEMS to be safe to use copy-paste as long as you re-edit the field again afterward. My technique for this is to paste in something like "textures\actors\character\Mango\Chinese UUNP\phototex.dds" but delete the last char, so it's "...\phototex.dd", exit the field, then re-edit the field to correct the filename. Very tedious, but way less tedious than the CK barfing on the NIF file for unclear reasons.

I only figured this out through random trial and error; it literally could have taken months to discover the fix, but I got lucky, and it "only" took four days.

I really don't know how it's even possible for NIFskope to be recording one thing in the NIF data ("UNNP" from a previous typo the first time I edited the NIF file), yet displaying "UUNP" in its GUI (which it got from a later correction, probably via copy-paste, which wasn't saved just right). NIFskope seems to be caching in some way.

PS: This was not a one-off error, but affected a body, a foot, and an eye, in two different NPCs. And it had nothing to do with data in the ESP file, only the in the NIFs as edited by NIFskope.

Edited October 5, 2018 by Darklocq

[JonathanOstrus]

Very strange indeed. Any chance you could post a copy of the broken nif for review testing?

[Darklocq]

Very strange indeed. Any chance you could post a copy of the broken nif for review testing?

 

Long since overwritten. If I run into it the issue again (i.e. if I'm not careful about how I enter data into a NIF in NIFskope, and invisibly break another NIF), I'll save a copy.

 

As I said:

 

 

This was not a one-off error, but affected a body, a foot, and an eye, in two different NPCs. And it had nothing to do with data in the ESP file, only the in the NIFs as edited by NIFskope.

.

It should be simple to reproduce. Get NIFskope 2.0, open a NIF, and paste in paths to some distinctive textures from a mod in place of vanilla ones, save it, then load it in CK and observe that it still loads the vanilla textures. Or manually, line-by-line, change them to something invalid, then paste back in the legit, correct vanilla paths without many any keyboard edits to these paths, save, load in CK, and watch the errors pop up mentioning the bogus paths. I've not tried NIFscope 1.x; I figure it's better to deal with one regression with a now-known workaround than downgrade to a version with multiple bugs that have been fixed in the current version. I would rather have a migraine than a stroke. >;-)

 

Anyway, I filed a detailed bug report about this (based on this thread) at the NIFskope GitHub.