sheson
-
Posts
13,180 -
Joined
-
Last visited
-
Days Won
431
Everything posted by sheson
-
I think I figured it out. Cell water that uses the worldspace height (default or same value) reflects objects and water that has a different height does not. I will update LOD generation to properly use the correct type in the terrain NIF depending on its height compared to the worldspace height. So LOD water should always work the same as the cell water in every worldspace without additional settings.
-
Since you are using MO and most likely never used the in-game MOD menu or other mod managers that do not have virtualization there is nothing odd about not having a plugins.txt in that folder. See what happens when you execute the x86 version DynDOLOD.exe See what happens when you set IgnoreLargeReferences=1 in the INI. Test if xEdit can add a new plugin by opening the entire load order in xEddit and then creating an overwrite for any record in any plugin. For example type form id 7 into the field top left to bring up the Player, right click the entry in the left tree view, select Copy as override into..., check , enter a filename and click OK etc. No need to save if it worked.
-
Restore ..DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini to the default version and try again. If problem persists, post/upload the ENTIRE log from last execution as said in the message. c:\Users\[...]\AppData\Local\Skyrim Special Edition\ is a folder that is created by the game/launcher and contains plugins.txt. xEdit and DynDOLOD which is a modified xEdit uses the same folder to store settings. I suggest to not randomly delete game folders.
-
Of course.
-
Can you upload the two plugins somewhere for me to check, please?
-
Are you just going by messages in the log or did the esp actually really end up as a master in the DynDOLOLOD.esm?
-
DynDOLOD support Skyrim VR since version 2.37. Instead of symlinks start it with -tes5vr command line parameter. There is no conceivable way the DynDOLOD plugins change unrelated INI settings or interfere with them as described, though you did not mention at all which INI settings are supposedly ignored. Consequently it makes no difference if you create two or one plugins. Did you maybe export all INI settings with the saveini command from console? It will create an INI in the data folder with the name of the last plugin loaded. Which may have been DynDOLOD.esp, so there might be a DynDOLOD.ini. Simply delete it. In any case you should use DynDOLOD 2.40 to create LOD and plugins with -tes5vr and no symlink tricks.
-
There is no problem with water height. If cell water is defined it is used. Otherwise the worldspace LOD water height is used with fallback to water height. I find that in FNV some worlds only have sky reflections and some reflect terrain and objects. There is a difference in the terrain LOD nifs that changes the LOD water reflections to match the reflection of the loaded cell water. The two types of worldspaces need their correct types of terrain LOD nifs. Using the wrong type results in visual problems like the one you posted. Based on the terrain NIFs, these worldspace only have sky reflections: dlc01steelmillexterior dlc02anchoragebattle dlc02glacier dlc02overlook nvdlc02zioncanyon nvdlc04divideworld nvdlc04nukelegion washmontop wastelandnv These worldspaces have decent reflections. I find they are more consistent and without the glaring bugs/omissions like Skyrim, Skryim SE or Fallout4: dcworld09 dlc01pittworld dlc4pointlookout thestripworldnew wasteland Any other worldspaces not listed does not seem to have LOD water. I would have assumed this is controlled by a worldspace setting or a the default image space reference, but I haven't figured yet how he game decides. In any case, for now I can automatically control xLODGen terrain LOD output with the LOD options files.
-
I found 2 more worldspaces with that flag, DLC01PittWorld and DLC4Pointlookout. However, the water LOD in the terrain NIFs is the same as all other worldspaces. So far I found only WastelandNV is different. When using the alternative water for WastelandNV, the surface becomes semi transparent, still showing the sky reflection, but you can also see the "skirts" (the sites of a LOD quad) of the terrain LOD. I am going to use a LOD options file for WastelandNV to change settings for LODGen.exe so things work correctly automatically. Will be briefly explained in readme in case other worldspace also need that setting.
-
The 3D object LOD for the STAT trees that are also large refs should unload if nothing overwrites a large ref in that cell. It seems there is a bug in LODGen that prevents it from setting the flag correctly in the static object LOD meshes. Will be fixed next version.
-
I found out what the problem is. The LOD water is missing object LOD reflections and maybe some other stuff. I know how to fix this in the terrain NIFs. The odd thing is, for WastelandNV this type of water LOD is correct, but any other worldspace I checked should have the additional setting for the object reflections. Do you know of any value, setting or flag for a worldspace that controls what water in FNV reflects? The "Needs Water Adjustment" flag seemed like a good candidate, but it did not seem to change anything for me in a really quick test. If there isn't anything that can be used to determine the type of water LOD, I will just do this via a LOD options file that users can adjust if needed.
-
This is newer or rather the terrain LOD code has not yet been committed to the xEdit github, since I am still working out bugs.
-
See if restoring ..DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini to its original state (copy the one from the archive) helps
-
See if clearing the folder ..DynDOLOD\Edit Scripts\DynDOLOD\cache\ helps. Once you tried again and it still didn't work, let me know if the file DynDOLOD_SSE_lodgen.txt exists or not. This could be UAC or antivirus preventing writing/overwriting files.
-
wasteland.level4.x12.y-16.nif is all I need to know which coords to look at and compare.
-
Can give coordinates for the screenshot? Check if CELL data sets water height, or if it is overwritten by plugins. BTR would be terrain LOD meshes in Skyim/Fallout4. So for FNV it would be the terrain NIFs. Like compare "vanilla" ones to the ones generated by xLODGen. I will try to replicate and see what I can find.
-
Thanks for letting us know, seems it was the same bug as with RW2 and not something else I have to investigate.
-
FNV? Mod? Worldspace? What cells? Have you check the CELL data or looked at BTRs in question?
-
If you could generate with 2.40 and the mod in the load order to verify if the problem went away that would be great.
-
I have no issues with Elysium Estate 5.01 and LOD generated with DynDOLOD 2.40 in Skyrim SE.
-
If there still is an error [xxBE6B40] in a plugin, you need to fix the broken link reference in the record xxBE6B40. DyNDOLOD is simply reporting the error. The form ID tells you in which plugin and record the error is happening. If you can not fix the error in the plugin, ask the author to fix it.
-
I was able to reproduce the problems with RW2 and trace this back to a regression introduced some time after 2.36. This should be all fixed now in latest 2.40. Get it from first post.
-
If you have problems or questions about third party guides you need to ask the author of that guide. I can not support 3rd party guides. Purple textures are a file not found problem. If the missing textures are related to object LOD (purple textures in the distance), then DynDOLOD log may print a file/texture not found message at LOD generation time. In this case it sounds like texture are missing from full models, which has nothing to do with DynDOLOD or LOD generation at all. Missing textures are easy to troubleshoot with console, form id and looking up the model in xEdit and using the Asset Browser of xEdit to look up the NIF model. The Asset Browser lists the textures a NIF uses without having to open the NIF in xEdit.
-
Great job. I will test with the new version myself and see what I can find. Thanks. Updated.
-
DynDOLOD and the LOD and plugins it creates do not generally cause crashes (any such case is discovered quickly by everyone and usually fixed very quickly). In old Skyrim memory limitations used to cause crashes until there was a memory patch. Third party meshes or data from plugins that is copied or overwritten and changed by the DYnDOLOD can cause crashes if unforeseen things happen. Once you are able to narrow it down to a single or handful records we will be able to identify (like the "invalid" NIF problem - the meshes work fine in normal use and only cause problem when used for dynamic LOD) and fix or workaround the problem. If the problem around Riften is new, I would assume a more or less recent new/updated mod in that region could be related.
