sheson

See this

Yeah that is as good as it gets. The neverfade flag on bulbs just means the light does not fade inside the 5x5 cells grid. If I remember correctly, it makes it ignore the [Display] fLightLODMin/Max... Skyrim.ini settings. You should be able to achieve the same effect by just increasing the ini settings for the light fade. But, they wont work outside the loaded cells. Of course that would apply to all lights equally, but it would also be a good test if there actually is any performance impact on newer hardware.

It is what you want. If you unlock MO and do any changes to the load order while LODGen.exe is still running it might accidentally remove access to required source files mid process causing LODGen.exe to terminate early with a file not found message or make it crash.

You need to insert the 2 if/endIf twice, after self.Enable(false) and self.Disable(false) inside the states/functions this should work (untested)

You wont find that patch I did for Lantern of Skyrim explained in text. However it is quickly explained. The script that runs when turning things on/off needs to trigger a SHESON_DynDOLOD_Master function to have all dynamic LOD around the player update its current state. To do that add this top or bottom of script where the other variables are defined ObjectReference MyMaster = None Then add this after your script changed the enable parent of the lights if (MyMaster == None) && (SKSE.GetScriptVersionRelease() >= 48) && (PapyrusUtil.GetVersion() >= 30) MyMaster = Game.GetFormFromFile(JsonUtil.IntListGet("DynDOLOD_" + JsonUtil.GetStringValue("DynDOLOD_Worlds", StringUtil.Substring(Game.GetPlayer().GetWorldspace() as string, 13, StringUtil.Find(Game.GetPlayer().GetWorldspace() as string, "(") - 14), "None") as string, "master", 0), "DynDOLOD.esp") As ObjectReference endIf if (MyMaster != None) && (StorageUtil.GetIntValue(None, "DynDOLOD_Active", 0) == 1) Utility.Wait(1) (MyMaster as SHESON_DynDOLOD_Master).IBowToTheev2(StorageUtil.GetFormValue(MyMaster, "DynDOLOD_MyActiveFirstborn", None) As ObjectReference, (MyMaster as SHESON_DynDOLOD_Master).MyCurrentFirstbornList, (MyMaster as SHESON_DynDOLOD_Master).MyCurrentMinionList, TRUE, TRUE) endIf First condition makes sure requirements are fulfilled and then sets the MyMaster Reference for the current worldspace. Second condition calls the update function which will "activate" all dynamic LOD objects in the current Near/Far Grids. Great. I had a hunch it was the same problem :)

Looks like Farmhouse Chimneys meshes are not installed properly. We had similar cases in this thread before. Search my discussion with user "SkulldozeR"

Great. You could still check those 2 record in xEdit now and report back if you like.

ICW 4.1 from 21:42, 6 January 2016 is compatible. See this post I have no idea how you make the vanilla static LOD for the main towers vanish all of sudden. Are you using a new/additional patch for ICW for something else? Check in xEdit if a mod modifies base record 00105569 or the reference 000CA6EA

Great news :)

There are no scripts from DynDOLOD running unless you cross a cell border, leave/enter a world space or open its MCM. Noting should be running more than a couple seconds. It might be the extra amount of (different types of) memory all the LOD needs in conjunction with whatever. Maybe check Papyrus log for stack dumps. Once you have a normal texture, use the different flat_normals.txt to see how the different lighting affects the flat static LOD trees.

That's a first and seems very odd. What mod is that? Add its name to IgnoreModFileName= in ..\xEdit\Edit Scripts\DynDOLOD\DynDOLOD_TES5.ini, but it maybe one of its assets that might need to be blocked too. A mod can only be fully ignored if it is not part of the load order. The first screenshots almost look like the the further away level 8/16 bto files expect a different sorted texture atlas. This could happen if LODGen.exe stoppped and didn't create all bto files, and old ones are still there mixed with new ones. Check file time of all btos are from the same generation process. It could be the those single LOD textures used for the texture atlas have been altered. Those far away mountains are pre-rendered mountain LOD textures and DynDOLOD just uses the ones it finds in your load order. Check ..\Data\textures\lod\mrkcliff01lod.dds etc Usually they are in Skyrim Textures.bsa You are confusing the normal map texture with mesh normals, those are two different but related things. You need to create the normal texture yourself. Only if a normal texture exists can the mesh normals be of use. They decide how the lighting is effects the normal texture. The pre-made texture atlas for the hybrid is just an interim solution while I am working on the process to basically create it on the fly from the current load order. So a hi-res version will happen automatically.

1) You need to manually move the pre-patch DynDOLOD.esp to be last, though typically the normal batch patch does not matter if it doesn't contain any world space data. Once the DynDOLOD.esp contains data, its position defined by LOOT if usually fine. 2) Doesn't matter if it is checked or not, because the DynDOLOD Worlds.pas you need to select is in the main script folder and thus always shows in the list. If you overwrite part of the static LOD *bto files generated by DynDOLD/LODGen with other static LOD *.bto files it is not surprising that you are seeing the other LOD for that area. ICW contains static LOD for the area regardless of the SDO installation setting. I still have no idea if the LOD for the college is only missing from a specific location/view angle (revert z-fighting settings in ini to test) or if LOD for it is missing completely (then something seems wrong with access to vanilla LOD source files)

You would know if Immersive College of Winterhold is compatible if you RTFM or read the Nexus description page section "Compatibility - Works Out Of the Box" I can not replicate the problem. Does the College only disappears when looking from this specific location/view angle but LOD is fine from other locations? Then this maybe just another case of the games overly broad occlusion culling when using anti z-fighting settings. If LOD is always missing: make sure to not install the SDO patch of ICW. Make sure all vanilla LOD meshes (usually in Skyrim Meshes.bsa) are accessible. Make sure the generated BTO files from outputpath\Meshes\Terrain\Tamriel\Objects\*.* are not overwritten by any other mods. The missing building outside of Whiterun are in loaded cells, so not a LOD problem. There should be full models which Besthesda intentionally didn't place for performance reasons. Did you never notice the buildings missing before? Anyhow, I made an independent patch for this a year ago. See DynDOLOD download archive ..\Options\whiterunexterior\

xEdit doesn't save it AFAIK, the preset ini I mentioned earlier is the only location that consistently has the last output folder used by DynDOLOD.

Update/overwrite the xEdit Edit Scripts with these and let me know if it worked or post TES5Edit_log.txt again if it doesn't

The texture atlas combines all used single LOD textures into one large supertexture. Read Docs/DynDOLOD_TexGen.html how to update the texture atlas with the newly created single LOD textures only without having to redo the entire LOD. You should check the manual/guide/forum of the mod manager you are using for how to set command line parameters if you intend to start xEdit with a function from within the mod manager. If the mod manager does not support setting command line parameters, start xEdit through a windows shortcut and set the command line parameter on this shortcut as explained in DynDOLOD_TexGen.html. AFAIK this always works with any other mod manager but Mod Organizer.

These things are infinity easier to run without MO. Make sure the link to start xEdit sets the -o paramater. Start xEdit and execute the script. Afterwards copy the LOD texture created to the output folder to the game folder. Then either generate LOD anew of you added mods in the meantime that add new objects that should have LOD. If you just want to update the existing texture atlas follow the instructions in the TexGen manual. You only need to change a value(s) if it is lower than -128 or higher than +128. Or remove the mod from the load order while generating LOD. If you do not see a value outside -128, 128, post the list of mods you see listed for the Tamriel record.

Post ..\xEdit\TES5Edit_log.txt to pastebin or upload it somewhere Start xEdit with all plugins as always open the Tamriel worldspace record by entering the FormID 3C of the worldspace into the FormID field top left. Hit the Enter key. Scroll down to the rows for Objects Bounds / NAM0 - Min/ NAM9 - Max. Scroll right to the column of the mod that adds values that are smaller than -128 or larger than +128. It can be any mod in the list. Right click the value and select edit and enter a number Save changed esp.

If you are super lazy and no output path was given by the user to your exe you could read it from x\Edit Scripts\DynDOLOD\DynDOLOD_TES5_LODGen preset default.ini - which is updated every time when clicking "OK" to run the patcher. Not sure how to find current path to xEdit installtion though.

Look 2 posts up on this page, my answer to Snakestone.

Changing that ini settins does not affect xEdit. I just noticed I have a typo in the line that records Dimensions... so it shows a wrong number for the second value which is probably the one larger than +- 128. Anyhow, see if this helps you. If DynDOLOD in the game prints a message that the files do not belong to each other it usually means the DynDOLOD.esp the game loaded does not match the data in the json files in the SKSE folder copied from the output path. Use the DynDOLOD MCM Information page to verify the files reported bunch of numbers match. Check there are no loose files in MOs overwrite folder.

In addition to what Zilav said, they also need a persistent cell. what xEdit file name do you use? It should be "TES5Edit.exe"

From the update post Are you still seeing this error with the new version? Then you need to make sure to replace all files in xEdit/Edit Scripts/DynDOLOD/*.* with the new version

Not RWT, but a mod want to use a nif added by a mod with number with load order number 27 hex or 39 decimal and that nif doesn't exist or is not accisable at generation time. Probably the same mod that adds the nif also wants to use it, but doesn't have to be.

I tested the other stuff... It seems to be a different problem compared to the one in November, and both examples you posted have the same cause. Please replace ..\Data\Scripts\SHESON_DynDOLOD_LODObject.pex and see if it fixes your problem without creating any new side effects. To update it should be enough to just deactivate DynDOLOD in MCM, go into an interior, save, replace script, start game, load save, test.