Jump to content
  • 0

Updated xEdit DynDOLOD_SSE_Update-CRC32.pas Script?


Question

Posted

This is a request to update DynDOLOD_SSE_Update-CRC32.pas to also rename *_trunk_lod.nif in addition to *_*passthru_lod.nif

At this time, it works great for updating the LOD models, but without manually renaming the trunks, TexGen can't find the models to render the trunk billboards.

I looked into doing it myself, but it would take me a loooong time and lots of trial & error if I could even do it at all.

3 answers to this question

Recommended Posts

  • 0
Posted
7 hours ago, sheson said:

Test this. Put trunks into the same "LOD" folder as the passthrus.

DynDOLOD_SSE_Update-CRC32.pas 14.5 kB · 0 downloads

That works great. The only thing I notice is the old LOD also seem to be copied over from ./LOD to ./new. This may have also been the case with the original script as well, but I neglected to mention it.

image.png


That^ is probably untrue. I think it's because I included the LOD assets in ./TES5 and ./SSE

I will make the changes and report back.


Confirmed. This works great, thank you!

  • 0
Posted

I did find one limit of the script that almost certainly has nothing to do with your update (it probably existed prior to that).

It would be most convenient to run this script on an entire mod without having to first clean out redundant assets like textures, scripts or even LOD. So...

  1. Extract the tree mod into ./TES5 folder
  2. Alter the meshes, saving output (only changed meshes) into ./SSE folder
  3. Parse the tree LOD from ./TES5 folder into ./LOD folder
  4. Execute the script to generate renamed LOD into ./new folder

This seems to be how it works now, but with an important limitation: When processing on a mod with BAIN/FOMOD folders containing different mesh options, where a minority of the mesh options are redundant copies of the same full tree replicated under a different option to simplify the installation and the FOMOD script, the script seems to find/rename the first instance of the copied tree but fails to do so for the subsequent instances of that tree.

In other words, the script assumes that we are working with the installed mod rather than the pre-installed FOMOD or BAIN, which typically have some degree of file redundancy across some of the different folder options.

 

The workaround is to execute the script on each BAIN folder independently, which is obviously a manual process with lots of potential for human error when one has tens or hundreds of BAIN folders with model redundancy.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.