That's a creative solution to the yellow VWD problem. It has one drawback though. Any light sources in the distance will never show up once you've done that. I'm not even sure they'd show up even if you're fairly close by.

The underlying problem with yellow VWD like that are _far.nif files that have specular data left in the mesh nodes. PyFFI has an optimization function that will go through and strip all the crud on VWD nifs that can cause things like that to happen.

It's pretty likely as soon as I finish putting up a forum for the MERP folks here I'll
be doing another small revision update to TES4Files, which will include a fix
for the \windows locating thing (as someone had a problem with it not
finding notepad and explorer) and sorting out the DistantLOD stuff, which
I will have to experiment to see what is appropriate behavior in that area.

What does "Cannot read file" in the error log mean? Is it something serious that I should inform the mod author about, or should I just ignore it?

Nope.

The "light sources" of the imperial city fires on the west bridge (for example) show up quite clearly in the distance
(most noteable at night, but also present in the day).
This effect is really poor in the fog by the way, the fire shape and flicker looks clearly defined even behind a mile of fog.
You would probably be right, but in my opinion what you say, referring to "light sources"... in this instance the fires are
a different animal than LOD viewing (as they are defined in the CS as "light"). I may be wrong on this point but I'm pretty
sure the "LOD" used as a term in this case is referring to DistantLOD handling only, not all "level of detail" handling.


Here's an example of what I'm talking about, how in fog you
can see that a "light" type in the CS is not treated as distant LOD,
as it is simply scaled down (to be smaller in the distance)....
http://straygenius.com/files/_fire_in_the_distant_fog.jpg
In no fog this looks fine...
http://straygenius.com/files/_fire_in_the_distant_clear.jpg

BTW, everyone knows that TES4Files works with Fallout3 as well? If not you can.

cept it cannot read, so it doesn't pack, anyt textures that are entered and set up in texture set entries via the GECK. 90& of mods containing new assets won't use the geck texture sets anyaway.

even so it still will create and dump all the assets of that mod besides those textures set up in the texture set.

Cheers MentalElf

Since it's not your mod (I assume) there's really nothing you can do about it but inform the author.
However, the author may know about it, a number of references can go undefined and be perfectly OK,
as in the case (for example) of inventory icon images of things that cannot be picked up.

To find out if it's a real issue, be sure "[X] LOG EXTRA" is enabled when you use TES4Files,
and look at the line above the "cannot find" the file error line, it has the CS ID of the owning
object. Find the object in the CS and right click, select USE INFO, and double click the
listed (if any) usage cases of the object, to bring them up in the view. Check the view
for the obvious (a missing image, texture, or model) and if at first glance there's not something
really wrong, it's probably nothing.

Hey that's great, I never really checked the work I did on supporting F3 with TES4Files.
I did make a fix in one of the last few revs that was sparked by someone pointing out that what Ob
uses for it's menu icons (menu/icons) were located and namely differently in F3 (interface/icons).

Originally I intended to support F3 fully, but then I ran into the snag of some kind of
protection (encryption) that I could not circumvent. It occurred to me later Beth
may simply be protecting it's valuable models and textures (which is new, but
I can understand why Beth wants to do that).

Whoo.. that's a lot of work. I reinstalled everything using TES4Files to pull the files out of the Data folder, then deleted everything that was left and replaced all my files (I had to re-add a bunch of texture replacers too, but that's okay). It's amazing how many missing files some mods had.

This might be a dumb question, but if TES4Files pulls all the files associated with a mod and there are still some left behind, those are extraneous and can be deleted, right?

Also, I encountered something odd... a couple times I found that all the files had been removed from a folder, but the empty folder was still there. ??? (I'd put a "confused" smiley here, but I can't find one.)

TES4Files simply won't work doing that if the mod is a "replacer type" which makes what is normally buried
in one of the stock game BSA files an external reference (a file in the /Data area). The principle of TES4Files
is that it is working with respect to a "mod" ESP or ESM file which references what it uses.

Therefore I recommend if you want to clean your Ob area using TES4Files, I suggest you package all the mods
that are not replacers (like better bodies, hair, or terrain textures) then take a hard look at what's left to try to
identify what replacer mods you have had installed, and make a list.

Uninstall Ob, rename the Oblivion directory (containing the remnants left behind, like replacer stuff) to "Oblivion.save"
or somthing, reinstall Ob (and SI if you have it), download the replacers (better bodies, hair, terrain, or whatever
was on your list) and install them. BEFORE you put any mods in, select all the subdirectories in your /Data
area and make an archive of them (name it "starting-setup.zip" or something). This means whatever happens,
you can restore your subdirectories to a fresh start (with all your non-esp/esm based stuff like replacers and
Darnified UI and whatnot).

Then put your mods back in and give it a shot.


As far as the left behind subdirectory, you may have a hidden system file there such
as a "thumbs.db" that Windows makes automatically when you visit the directory.
I think the next rev. of TES4Files will probably check for this as the only remaining
file and get rid of it, since the "thumbs.db" files should not stop TES4Files from
cleaning up and removing a (basically) empty subdirectory.

Oh, I know. I didn't mean to imply that I thought otherwise.


I've got a list of all the mods I use. I just deleted everything that was left so that I could get rid of any stray files left over from mods that I tried out and later deleted. I've gotten better at catching things like that, but I figured what the hey.


Not a bad idea. I wish you'd told me that yesterday. I'm currently working my way through an incremental activation of all my mods (a la the "50 steps to a crash-free FCOM install" thread).

I was referring to the actual glow cast off by those light sources. Turning the fLightLOD to 0 will effectively make them stop glowing. You'll still see the flame billboards off in the distance, but they aren't actually producing light.

Find the newest version using the link in my signature below please...

?V3.43 9/12/2010
?I verified LOD does not work within a BSA archive, so LOD gathering was removed (if you have a new worldspace type LOD you can still include it in the gathering by using the "add-on" feature).
?The registry is now used to locate the user's notepad and explorer (for the NOTEPAD and BROWSER buttons, respectively).
?The system file "thumbs.db" will no longer stop the removal of a (basically) empty subdirectory (while using Un-Install mode).

Arthmoor ::
Ahhh ok I think I understand now.
I was unable to get the yellow to stop without disabling all LOD shadow, light, and envmap.
However I was able to allow specular and eyeenvmap to remain unchanged (the site page was updated to reflect this).

Arthmoor ::
I'm confused again, lol, are you saying all light sources stop giving light?
That has not happened.
Or only at a distance??

One of the two fLightLOD values controls how far away the glow radius of lights will display. The larger the value, the further away, and the more likely you are to see visual anomalies.

So if you set those to zero, you should be stopping it entirely unless there's a hardcoded minimum distance in play.

In any case, removing the NiSpecularProperty from all _far.nif files will eliminate the problem.

As a modder who is currently using stuff from 9 different mod resource packages (and growing)....I say thank you

Arthmoor ::
Your saying "one of the two values" gave me an idea, which was to experiment
with only one of the two types set to zero (to further limit what gets set to zero,
since setting things to zero turns off LOD features).

I got it to work with just zeroing...

fShadowLOD1, fLightLOD2, fSpecularLOD1, and fEnvMapLOD1

The web page on my site was updated to reflect this.
Thanks for helping with this.

By the way, I've pretty much promised that I will bring TESRespec to Oblivion as well.
I will use the part of TES4Files that works with the esp/esm to save rewriting that.

Not sure if it was missed before, but I'll mention it again:

Everything I run through TES4Files has this one error in the output:


None of the mods I have are specifying that, so it shouldn't be attempting to copy this, correct?

Hi

I have the latest version 3.43 but my beta tester tells me the he gets missing meshes from the BSA and he has to extract it for the meshes to turn up. But on my end i have 3 installs of oblivion, all now with there own ini file, i can test with any install of oblivion, mainly the ones where none of the meshes exist and i dont get this problem. The BSA works fine on my end, but i do have x64 operating system(win 7 x64) and wondered if this is the issue. He also said on the older versions of TES4files the bsa had the same issue

Used TES4files 3.42
http://hotfile.com/dl/69909580/3dde38d/MajesticUnderground.rar.html <<-- The file in question
http://hotfile.com/dl/69905307/d2f2656/ATPAyleidTileset.rar.html <<-- old version

Used TES4Files 3.43
http://hotfile.com/dl/70563772/42ab4fb/MajesticUnderground.rar.html
http://hotfile.com/dl/70563370/de03606/ATPAyleidTileset.rar.html

Until i solve where this problem is, i cant really release either mod. The 300 mesh tile set is on hold too atm, as i think it will have the same issue with the bsa. Hopefully some one with a x32 bit system might be able to confirm the problem, that a x64 bit machine packing the bsa will have problems on a x32bit(x86) machine playing the bsa

OK sorry I have been busy and not visited here in a bit.
I will look at this now.

I have not been able to figure out how to work the "ruined portal" other than make
the thing over the bed glow, lol, but everything I've seen so far is fine.

What seems to be missing, exactly?

Hi

The mods on my end work fine, but on the beta testers end, it ends up with missing meshes and textures etc from the bsa file. But as soon as he extracts them they work. So i presume you have x32 bit system and had every thing turn up, which i guess every thing is working fine. I just dont understand how he gets that error(missing meshes and textures) is what is puzzling.

NP with the late reply. And thank you for a wonderful bit of software to simplify things.

Hmmm OK.
Well I used it as a BSA (I re-ran TES4Files too, everything came out identically).
Everything I saw was fine, I'm on 32bit Win7 btw.


You might ask him what settings he is using.
Yes I have everything maxed out.
Texture size Large is required by a number of mods, if he is using
another texture size in his settings that might be an issue?


My first reaction was that there were nifs with bad texture paths (forward
slash paths inside a NIF work OK on disk, but not in a BSA file). However
when I got the mod and re-ran TES4Files I found this was not the case.


Since it's an issue with the CS display, It may be something specific to
his set up, his software or computer. The only time I see CS render
views that look like the bad screen-shots you shared, is when I have
the "lighting" turned off.

Could I make a request, please? Could you provide an option to make it shut-up when it's done the export? I'm afraid I find the sound effects really annoying!

Hmmm. I wonder if that is a stock dds that needs to be recognized.
I was unaware of this issue, I've not seen this error.
Also Arthmoor, I have learned working with the MERP group how to properly
enable distant LOD using TES4qLOD in addition to TESLODGEN, and I will
be rewriting my page to reflect what I have learned. Yes I will be removing
the "hack" that turns off some aspects of LOD. doh.

andalaybay:
Hah ha ha I assume you mean the "Glory" at the end of an export whey you say "sound effects".
Yeah sure, on the next rev. I'll add a checkbox for disabling the "glory" sfx.