tes4ll/MPGUI Do not write tesqlod texture cache properly

[code8buster]

GAME: TES4 Oblivion UTILITY: TES4LL https://www.nexusmods.com/oblivion/mods/40549

The problem:

tes4ll is a utility for regenerating the landscape LOD/landscape LOD textures based on ones mod list and textures. It comes with batch files for generating the LOD at different resolutions.

I have tried using the batch and calling tes4ll.exe directly, feeding it the arguments the batch file gives. That is what I will detail below in reproduction:

To Reproduce:

Steps to reproduce the behavior:

1. Install tes4ll in your data folder like normal (or as MO2 mod)

2. Add tes4ll .exe to your ini/through interface. Heres mine: 15\title=TES4LL Texture Cache 15\custom=true 15\toolbar=false 15\ownicon=true 15\binary=C:/Games/Oblivion/Data/tes4ll.exe 15\arguments="tes4qlod_cache logfile=tes4qlod_cache.log ini\\tes4ll\\tes4ll_all.mpb" 15\workingDirectory=C:\\Games\\Oblivion\\Data 15\closeOnStart=false 15\steamAppID=

3. Run

Environment:

• Mod Organizer Version that exhibits the issue: 2.2.2.1 rev 6c6734fc usvfs dll 0.4.4.6
• Last Mod Organizer Verison that did not exhibit the issue (if applicable): none
• Desktop OS/version used to run Mod Organizer: W10/ Version 10.0.18362 Build 18362

Details:

If necessary, describe the problem you have been experiencing with more details and pictures. When tes4ll generates LOD textures, the cache needs to have the correct textures or it defaults to the ones shown in the photo below. You can see the demarcation between the true texture of this Desert region and the LOD. https://staticdelivery.nexusmods.com/mods/101/images/40549/40549-1563753197-956691566.jpeg

The program ends up generating 102 byte .bmp files for every texture.

MPGUI is a tool made by the same author for making tes4ll options (otherwise a cmdline only program) more accessible, and it makes no difference whether tes4ll.exe is called directly, by batch, or by MPGUI.

Link to Mod Organizer logs:

To access the log files you can press the Open folder icon over the modlist and select "Open MO2 Logs folder". You should close MO2 before sending or examining the logs as they are finished writing only after the program is closed.

USVFS:

https://gist.github.com/code8buster/670e3ceb07118176c8f7d8dd3924d9bd

TES4qLOD:

https://gist.github.com/code8buster/a99ed7f0407933f52223064476a8e629

[Holt59]

Could you clarify: 1) what is the expected behavior and 2) what is the behavior you observe? It's not clear from your post for someone not familiar with the tool.

[code8buster]

Sorry for not being clearer.

The expected behavior is:

• tes4ll reads the data directory to figure out which loose files and BSA's to use for landscape texture generation
• It generates bitmap images that are written to a cache folder, using textures in Data as the source
• Depending on the options, it will then create the landscape LOD mesh + texture (.dds) based on the load order and any mod textures.
• Writes new files into directory of choice or overwrite existing LOD

The resultant behavior: Texture cache contains invalid .bmps. They are all blue, not even close to the source .dds colors The meshes won't generate either.

If it helps, I also have a log of how usvfs interacts with tes4ll.exe when it is called to create the landscape LOD mesh. Fails with "Cannot open Oblivion.esm for reading: No such file or directory" https://gist.github.com/code8buster/3339da2e82c89f35f1b84640513e7538 https://gist.github.com/code8buster/aa83d1942a28f8522698e5ec4a4b6393

[code8buster]

Is there anything more I can add to clarify things, or can we remove "waiting for user" tag?

[code8buster]

I modified the multi-purpose GUI batch script (tes4ll_all.mbp) to highlight the behavior in question. The program seems to be only extracting the normals of the .dds textures, but not the dds themselves. To discover this, I reduced the amount of downscaling tes4ll performs on textures from 4 to 256 https://gist.github.com/code8buster/f82fc1666c684eff6c0059c96277caae

[Al12rs]

Hi could you test if you can reproduce using the latest Mo2 2.4.0 dev-build from discord (#dev-builds channel)? https://discord.gg/cYwdcxj There were some fixes to usvfs that happened on the meantime.