sheson
-
Posts
13,179 -
Joined
-
Last visited
-
Days Won
431
Everything posted by sheson
-
This is DynDOLOD 2.36 SE BETA and I am not pro-actively testing compatibility with mods while Skyrim SE is a broken mess of bugs that are not fixed by Bethesda. You might notice the short list of compatible mods compared to the Skyrim version. The LOD of the gate should not really have a form id, but rather be static LOD usually. I will need to check what tpos does and then typically add some rules to fix stuff like that. DynDOLOD is using the correct and very much the same INIs and plugins.txt like the game. You might want to read up on how MO works in the background "updating" those files virtually before starting an executable.
-
Seems to me the LOD is correct, but didn't unload. See FAQ: Out of place objects / floating objects / flickering full model Could also be not following 2 step generation required for Open Cities. Could also be the game engine. See recent discussion with mohaderhangen Open console, click object, verify you have the correct object by using disable/enable in console, note form id and look it up in xEdit to see what record it is and what its EditorID ([source-plugin-name]_[source-form-id] points to. If the object has no form-id then it is static object LOD and a game engine problem that should clear with a save/load. We do these same troubleshooting steps every time and then I also always also ask for the DynDOLOD log to be uploaded or pasted to pastebin. The included manual and reference *might* mention that LODGen.exe uses terrain LOD meshes to optimize object LOD (remove unseen faces). If tree LOD generation is not checked, then existing tree LOD is scanned to build a list of trees that have tree LOD. However that will typically not have good results, since tree LOD does not preserve load order information of plugins that add tree references with the well known outcomes that pre-made LOD that wasn't made for the exact same load order is always incorrect and results in wrong/weird tree LOD textures and stuck tree LOD. So under normal circumstances only terrain LOD meshes (something DynDOLOD does not generate) matter for generating static object LOD.
-
Most of the large reference bugs only happen when existing data from Skryim/Update/DLC *.esm is modified by an *.esp. If the same modifications are done by an *.esm it is usually fine, with a few exceptions. So whatever DynDOLOD needs to do in regards to large references it does in DynDOLOD.esm and for the few exceptions just doesn't do them at all or in a different way that is not including the large reference system. This thread might be of interest https://forum.step-project.com/topic/12977-flickering-lod-magical-college-of-winterhold/ in case the technical bug report from Docs\SkyrimSELargeRefGrid\SkyrimSE-LargeRefGrid.html is too abstract.
-
Thanks for the update.
-
That is great. I already wondered quite a bit how that might have happened in the first place. It seemed very odd and from the log nothing stuck out. Anyways. Enjoy.
-
This can only happen in the 2nd step when the DynDOLOD plugins are generated. It should use the last overwrite from Open Cities to create the record in DynDOLOD.esp. For some reason in your case it did not. Make a screenshot from the advanced options window so I know what to use when I try to replicate tomorrow. (provided you still have the problem next time)
-
Hmm there might a bug, that happened because of one of the past beta updates. I will need to verify that. I may only get to it tomorrow. In the meantime, the base record should still point to the STAT from Open Cities.esp. Just drag WRMainRoadPlains [sTAT:000193E6] from Open Cities.esp to DynDOLOD.esp and save. That should do it.
-
The decision to use the large reference does not depend on using DynDOLOD or not, but if you are using plugins that modify large references and them causing noticeable texture flicker. Some plugins get away with their modifications because most people do not notice that both full and LOD models show at the same time because the models do not occupy the exact 3D space/planes that much. Depending on that decision you need to set the MCM "Large Reference Fix" accordingly. (It will try to default to the correct setting which is determined when LOD was generated) If you decide to not use large references you most likely want to check the "Upgrade NearGrid Large Refs" checkbox when generating LOD. Otherwise those thin waterfalls are probably not going to show past the loaded cells. Or use the INI setting IgnoreLargeReferences=1 to not care about large references at all. Then the thin waterfalls will show in their default NearGrid as they did in Skyrim.
-
The log keeps growing. Just delete it before doing a new set of generations. Consider zipping and uploading to a file service. The current way is fine though, since I could just stitch it together anyways and have a quick look. The only thing sticking out (beside the fact the Skyrim is installed into Program Files and DynDOLOD is installed into the Skryim folder) is that the HomeMapMarkersForOpenCities.esp plugin was still loaded for the first generation. It should depend on Open Cities and also be removed I suppose. It probably doesn't change anything though, but please test anyways. Do these tests: Test with new game, coc whiterunexterior01 from main menu and then walk to the inside. 2nd test coc riverwood, tmm1 to enable markers on the map, fast travel to Whiterun. Disable both DynDOLOD.esm and DynDOLOD.esp and test if the problem still happens. Can you open console, click the stuck LOD and get a form id? Use disable/enable commands in console to see if you go the right object. What is its form id? These tests only make sense if the problem is 100% and the stuck objects have a form id. If it only happens sometimes and they have no form id, I am afraid its the engine problem.
-
The version of the plugin did not change since 2.30. It only changes if there are data changes in the plugins/jsons that require the newer versions of the papyrus scripts. Regarding the waterfall you could test if is only with large references or without. Did you check upgrade NearGrid LargeRef? I assume it is a native waterfall. Tell me the form id. Good to know. Thx. Which typically means LOD just turned off because you are out of the Grid (Near/Large/Far) whichever is doing its "LOD"
-
Start the game from the launcher once, so the registry settings are updated with the correct path information. If that is not it, double check the command line parameter. You maybe accidentally adding a switch that can be used to define the path to the INI.
-
Looks a bit like you might be using Open Cities Skyrim and did not follow the two step generation instructions. Hard to tell without load order / DynDOLOD log.
-
SKSE64 and PapyrusUtil SE seem to work stable and reliable, unlike Skyrim SE which is a completely broken disaster Take note of the .patch installation files replacing some of the esp in the Resources. It requires newer version Wrye Bash to install. Otherwise things are pretty similar.
-
There is no need to create a new thread with the same question. I can still not help with 3rd party instructions or mods. Whatever your problem with water has nothing to do with DynDOLOD since it only does tree and object LOD as explained in the manual. There is a Realistic Water Two LOD Fix mod available that might help with that problem. Only you can find out if the tree LOD is 3D or 2D. Get close to the LOD trees with tfc and compare them to the installed 2D billboards and 3D LOD models. Check the DynDOLOD log which reports in detail which full model tree uses which LOD models. Search this forum for related posts, for example: https://forum.step-project.com/topic/11518-dyndolod-skyrim-special-edition/page-11?do=findComment&comment=210844 https://forum.step-project.com/topic/12589-skyrim-se-missing-trees/?hl=%20i2uhzlnexqo https://forum.step-project.com/topic/12520-ultra-trees-tutorial/?hl=%2Bi2uhzlnexqo
-
I am unable to give support for 3rd party mods/videos or instructions. You should ask the creator directly. If you wonder why you would have to install resources or do certain things, it may be a good idea to first read the DynDOLOD main manual and the differences of Skyrim SE, watch the included GamerPoets video. Then proceed to read the 3D tree LOD manual docs/trees.ultra/DynDOLOD-Trees.html
-
Not sure what else to tell you right now. Skyrim.esm and DLCs are full of records with form versions There should be no reason for Wrye Bash to complain about these records in Skyrm.esm/DLCs or their overwrites since they are certainly valid and work without problem. Edit: Zilav pointed me to https://github.com/wrye-bash/wrye-bash/issues/403#issuecomment-354641012 which is the related issue. Lets see how this is going to be addressed in Wrye Bash in the near future or if there is something xEdit/DynDOLOD needs to do.
-
It seems that Wyre Bash version you are using has some kind of bug if it expects form version 39 STAT / DNAM with 12 bytes (the source in Skyrim.esm), as that only has 8 bytes. It is form version 44 that has DNAM with 12 bytes. None of the other things matter.
-
Care to give some more info about the record which is most likely copied and updated from some other plugin?
-
This obviously is a problem unrelated to DynDOLOD/TexGen with the compression tool being used. Use the native windows zip with right click/send-to, as shown in the "simple" videos or copy/move files manually into a new mod folder.
-
Water itself is never a large reference. Most of the the water is "cell" water which doesn't have a reference. Those form IDs start with FF. Cell water belongs to terrain LOD and thus is not changed whatsoever by DynDOLOD, for better or worse. Terrain LOD water can only have on type of LOD water for an entire map. The flicker problem could be large reference ice floes (depends what is flickering?) or just normal z-fighting because the flat surface of the water and the flat surface of the ice is pretty close together. Just turn off large references in the launcher and you will know which.
-
Because of the new patching feature for the optionals like White Exterior etc, remove old DynDOLOD Resources SE and all its plugins. Remove old output and DynDOLOD.esp. Then do the clean save. Then install and generate everything like usual.
-
Looks like there was a bug in the fomod installer file preventing some patch files to be installed correctly, DynDOLOD Resources SE 2.36 beta1 fixes that. No need to reinstall if you fixed it manually. You probably want to update to the more recent and stable MO version 2.1 The intensity of the glow can be changed by setting FakeLightsIntensity=1-9 in ..DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini, then generate LOD. To change the size you would need to edit ..Meshes\DynDOLOD\lod\effects\fxglowdefault[1-9]_dyndolod_lod.nif (replace [1-9] with whatever number is set in the INI for FakeLightsIntensity) You can also change the intensity in the shader of course. Editing this file will have an immediate effect in the game.
-
Make sure the patch files were installed to ..data\DynDOLOD\WhiterunExterior_Tamriel.patch or whatever the equivalent is depending on which mod manager you are using. For example, you need a recent Wrye Bash version so the automatic installation works. If the files are installed correctly, then check ..DynDOLOD\Logs\DynDOLOD_SSE_log.txt for lines like "Processing 33 patches from dyndolod\whiterunexterior_tamriel.patch"
-
The flickering is most likely because you have not turned off large references. The wrong LOD textures happen because the object LOD texture atlas does not belong to the generated object LOD meshes, they are from different generations.
-
This is a vanilla "bug" and has nothing to do with LOD. Bethesda simply did not add all full models beyond the walls to "optimize" for weak hardware like consoles. DynDOLOD Resources SE ships with the optional "Whiterun Exterior" and "Solitude Exterior" patches to add a few of those "missing" full models when creating the DynDOLOD plugins.
