Jump to content

sheson

Mod Author
  • Posts

    13,181
  • Joined

  • Last visited

  • Days Won

    431

Everything posted by sheson

  1. Zip log files and upload them to the file service as explained instead of splitting them across several pastebins or fileservices. Taking screenshots on PC is a rudimentary computer skill, which is explained in countless guide, explanations, videos etc. If you want people to help you, make an effort to make things as easy/accessible as possible for the people trying to help you instead of making them work for you. I wrote/linked those instructions for a reason. Also upload ..\Skyrim\DynDOLOD\Logs\DynDOLOD_SSE_Object_Report.txt as requested. As explained in https://dyndolod.info/Generation-Instructions#2-Generate-The-LOD-Mod-with-DynDOLOD, In case a summary of messages was created and opened in the default browser check all its entries to learn about problems and if they need to be addressed. The log/summary reports https://dyndolod.info/Messages/Billboard-For-Model-Has-Different-CRC32 Generate LOD billboards for the current load order with TexGen first. As explained in https://dyndolod.info/Generation-Instructions#Prerequisites, Do not install any 3rd party tree LOD billboards. Use TexGen to generate all desired LOD billboards. If problem persists with tree LOD not matching, upload new DynDOLOD log, debug, DynDOLOD_SSE_Object_Report.txt and also the TexGen log and debug log. No useful screenshots for waterfalls have been posted. It is not a good idea to use NeverFade* on a NIF that is used many times across a worldspace, especially for performance reasons. Using reference rules to target a limited list of waterfall references would be a better approach. Do not set Level0, Level1, Level2 and uncheck Dynamic to not have both LOD types added. See https://dyndolod.info/Help/Mesh-Mask-Reference-Rules
  2. Don't compare file sizes, they can end up being identical. Check the version info in the DLL and/or the CRC32 of files. Re-uploaded the archives.
  3. That is great to hear. It is either the extra checks I added to make sure a ref handle is still valid mid process or making sure something doesn't run twice at the same time. Neither should happen the instant the game starts notifies that it is loading, since all processing is stopped, but the engine does whatever the engine does.
  4. No DynDOLOD.log with debug enabled or crash log was provided. The markers list contains xMakers and persistent large reference that are used to work around large reference. Indeed your troubleshooting means the problem is most likely not with a specific entry. Replace the DynDOLOD.DLL and .PDB in .\SKSE\Plugins\ with this test version https://mega.nz/file/EUgHkCaS#yGkqCz0fRPi0w7PSsoZcpzFLNF-wpMagxK52i5WPQaQ and check if there is anything different. If the issue persists, edit ..\skse\plugins\DynDOLOD_Data\DynDOLOD_NG_Worlds.txt and change debug=true and add a line underneath debuglevel=5. Then reproduce the crash and upload c:\Users\[USERNAME]\Documents\My Games\Skyrim Special Edition\SKSE\DynDOLOD.log and the new crash log.
  5. Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload Also upload the c:\Users\[USERNAME]\Documents\My Games\Skyrim Special Edition\SKSE\DynDOLOD.log as explained in https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds#Testing Make sure to use the latest version of everything.
  6. If you are using Open Cities you are never really inside the Solitude or Whiterun child worldspaces which the exterior patches are for. The grass cache can improve performance sine it won't have to generate grass for each new cell every time. What is the message? Upload the DynDOLOD.log and papayrus.log. Only replace the DLL and PDP with the test version, keep the scripts from DynDOLOD DLL and Scripts 3 Alpha 26. Get the latest DynDOLOD DLL NG and Scripts Alpha and let us know that everything works OK now.
  7. Check if there anything different with this version https://mega.nz/file/gEpAnDaA#i7oOFVG6_ywgBsV1V5cXnlso1AEmc_LqSZ8pwajJQ54 You installed the DynDOLOD script patch for Laterns? What are you setting speedmult to? In case there are crashes with the test version, temporality disable the NGIO DLL or generate and use grass cache in case you haven't.
  8. Upload the DynDOLOD.log (with debug=true and debuglevel=5) and crash log after all entries for all 3 sections have been removed.
  9. You uploaded 3 FNVLODGen_log.txt. All of them show the output folder was c:\output It is one of the first things I check. Can not help if information is not provided. As explained on the first post, in the Readme.txt includes in the download archive: Always set -o:"c:\OutputPath\" command line argument to change where files are generated to. The default is the game folder which risks replacing existing files and is problematic with mod managers, especially if they use some kind of virtualization. Do not generate into any game or any mod manager folders that are part (direct or indirect) of the virtual file system. Do not generate into the Overwrite folder of MO2. Install the output as a mod.
  10. What do you mean by "debug area"? If you do not understand an instruction or explanations, then you need to ask a specific questions about it. See https://dyndolod.info/Help/Grass-LOD
  11. That's a good hint. Still would be nice if you could do the binary search and then provide the DynDOLOD.log with a matching crash log.
  12. You reported that the problem happens with vanilla plugins and assets, BSAs etc. and default INIs. Generating LOD meshes and textures with xLODGen will not change the game having some kind of issue.
  13. The log you uploaded shows that tree and object LOD but no terrain LOD was generated. It shows that no FNVLODGen.esp and no MuchNeededLOD.esp are being loaded. If files - like meshes and textures generated by xLODGen - do not exist (virtual or physically) in the load order (that means the data folder the game loads plugins and assets from), they can not affect the game. Random files in random folders outside of the mod manager and game folders - for example c:\output - can not affect the game. MO2 stores the INIs in the the corresponding profiles folder. The INIs in the MO2 profile virtually replace the physical INI in located in C:\Users\... That would be the INIs you would need to restore to default. The log shows that there also is a FalloutCustom.ini
  14. The RealisticWaterTwo.esp you have has the CRC32 5797862F, the one in the 5.6 download archive has CD346494 Did you change it or have any idea where you got it from? Backup ..\skse\plugins\DynDOLOD_Data\DynDOLOD_NG_Tamriel.txt from the DynDOLOD output. Edit it in notepad and find the section [Resets] near the bottom. Remove all its entries and test if it makes a difference. If not, find [Markers] in the middle and test if removing all its entries makes a difference. If not, find [Objects] at top and test if removing all its entries makes a difference. If removing all of the entries for a section made a difference, use binary search to narrow it down to a single line. Binary search means to make a backup, remove half the entries, test if the problem is still there. If not restore backup and remove the other half. If the problem still exists repeat until you are down to a single or a couple entries left that are required to cause the problem. If removing all entries for all 3 sections makes no difference at all, let me know, too. Once you did all that and you have a minimal DynDOLOD_NG_Tamriel.txt with either 1 or no entry in any of the 3 sections, edit ..\skse\plugins\DynDOLOD_Data\DynDOLOD_NG_Worlds.txt and set debug=true and add a new line debuglevel=5 underneath it. Then reproduce the crash, upload that crash log and c:\Users\[USERNAME]\Documents\My Games\Skyrim Special Edition\SKSE\DynDOLOD.log
  15. No log was provided for the new LOD generation. The MO2 mod list shows no xLODGen output mod, no LOD Fixes and Improvements - NVSE mod, no FNVLODGen Resources mod, no Much Needed LOD mod, no Much Needed LOD fixed rocks color etc. The FNVLODGen_log.txt that was provided shows no FNVLODGen.esp being loaded, no MuchNeededLOD.esp being loaded etc. xLODGen does not change anything. It generates LOD meshes and textures to the dedicated output folder - reported as C:\Output\ in the provided FNVLODGen_log.txt. If this output is installed as mod in MO2, simply uninstalling the mod removes the meshes and textures again from the load order and everything is as before.
  16. Does "game with 0 mods enabled" mean, you kept the tree and object LOD generation shown in the FNVLODGen_log.txt - which was made with mods in the load order and thus does not match the load order with 0 mods enabled anymore? Does "game with 0 mods enabled" mean vanilla INIs? If you want to test xLODGen output with the vanilla game, then generate LOD for the vanilla game - including terrain LOD. See https://vivanewvegas.moddinglinked.com/lod.html
  17. Please keep this load order with this DynDOLOD output in a sperate MO2 profile. Do not change it, while we test different things with it. Can you confirm the crashes still happen with the DynDOLOD.DLL removed from the load order as before? Enable papyrus logging and upload it together with a corresponding crash log. 01792B8 and 09A1B92 are similar/same type of crashes, so either is fine.
  18. Moved to the DynDOLOD 3 alpha thread. Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which TexGen/DynDOLOD log and debug log to upload. If you have issues following a third party guide, then you need to ask its author questions about it. I suggest to read https://dyndolod.info/Help/Grass-LOD, which explains the requirements of grass LOD and how to generate it. Note the https://dyndolod.info/Help/Grass-LOD#No-Grass-LOD-Check-List at the bottom.
  19. Upload log files as attachment or paste to paste bin. See my signature. The screenshots seem to show a problem with terrain. The log shows no terrain LOD generation, only tree and object LOD generation. The MO2 load order does not seem to list an xLODGen output mod. The issue shown in the screenshot only happens with the xLODGen output enabled? Test with default INI settings. I seem to also remember reports of mods causing this, unrelated to what tools was used to generate LOD / vanilla LOD. See https://vivanewvegas.moddinglinked.com/lod.html
  20. Provide common sense rudimentary information about the load order and the mod manager being used. Upload FNVLODGen_log.txt.
  21. Post one of each crash log that are at a different address in the SkyrimSE.exe. It is entirely possible there are different causes for crashes. If the crash logs were created with newly generated DynDOLOD output, upload the new DynDOLOD log and debug log as well. You can create and upload one zip file with all the logs in it. What version of RealisticWaterTwo are you using or did you change anything in the RealisticWaterTwo.esp?
  22. Those different crashes have similar crash logs I assume? Crash at SkyrimSE.exe+09A1B92 and the Stack mentioning FormType: Cell? They might be (cell) water related. Can you test what happens if you temporarily remove ..\SKSE\Plugins\DynDOLOD.DLL from DynDOLOD DLL NG and Scripts 3? Keep the scripts. Ignore the error message after loading, then run around to see if it crashes. Test what happens if you install DynDOLOD DLL NG and Scripts 3 Alpha-18 from https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds#Requirements If there is anything different, install Alpha-19 and so on until the problem starts again. If there is no change with older versions, test what happens if your deactivate DynDOLOD.esp only. If no change, test what happens with deactivating DynDOLOD.esm as well. Report results.
  23. What steps are required to reproduce this crash? Is this with an existing save? Can it be replicated starting a new game?
  24. What does "the problem remains the same" mean? If you have a crash in the game that only seems to happens with the DynDOLOD LOD patch in the load order, then post the crash log and the DynDOLOD log and debug of the LOD patch generation used in the game. If the crash reports a form ID and NIF, check those as already suggested and report the result.
  25. Large reference data defined in non master flagged plugins (ESM) is not used by the game. This mean the data is not used. It does not do anything. The data can be removed from the worldspace record. This means the data can be removed, but does not have to See the xEdit documentation to learn how it works. To remove something in xEdit, typically click right on it and select remove. e.g. right click the "Large References" RNAM list. If teh entry is not shown, uncheck 'Hide "never shown"' in the xEdit options. https://dyndolod.info/Messages/Duplicate-Reference Showing the same model twice with exactly the same properties is just wasting resources, in case of animated objects or trees it might even be visually noticeable. https://dyndolod.info/Messages/File-Not-Found-Scripts If it has been verified that the script is not required try to remove or update the unused record/entry so the non existing filename is not being referenced. Maybe check the mod that contain fixes and patches for it. The rest of the mod will typically work fine, not just the things that use the script, whatever they might be. You uploaded two crash logs so far, they show 2 different load orders and crashes.
×
×
  • Create New...

Important Information

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