Jump to content

sheson

Mod Author
 View Profile  See their activity

  • Posts

    13,180

  • Joined

  • Last visited

  • Days Won

    431

 Content Type 

Everything posted by sheson

  1. sheson
    https://forum.step-project.com/topic/13118-issue-with-dyndolod-and-legacy-of-the-dragonborn https://forum.step-project.com/topic/12662-having-issues-with-dyndolod-and-legacy-of-the-dragonborn See the linked threads. I do not know what "couldn't access the Guide house" means. I assume you can not access it because its door is not visible. All that DynDOLOD does is to unset the IsFullLOD flag on the guild house and related stuff so it can be replaced by a LOD version in the distance. You failed to mention which form ids you prid and disabled/enabled, make sure do all of them. The order should not matter. You can also try the recycleactor on the references that are not showing, e.g. the childs of the enable parents, the objects themselves. That list could be long. If all fails, remove the overwrites.
  2. sheson
    Thanks for letting us know.
  3. sheson
    FAQ: DynDOLOD.exe: Exception in unit xxx line xxx: Can not copy xxxx from xxxx.esp into xxx.esp A: Often caused by a broken bashed patch. Use a newer Wrye Bash version to create the patch or do not use the merge patches option. A: There might be plugin in the load order with errors. Check the load order for errors with xEdit.exe before generating LOD. Fix all errors. See this video for help. The log is saved when the program is closed. Otherwise it can be copied and pasted from the Messages window. If runs through with Based Patch disabled, then you know you have a broken patch that should not be used.
  4. sheson
    In cases like this do a multiscan https://www.virustotal.com/#/file/22d12e6548f6c83d94b61563548a68c600da2d3aa30d32967c5d8eb5189e61de/detection
  5. sheson
    Look like MO does not like shortcuts. A *.bat with the line "c:\path\to\xLODGenx64.exe" -sse -o:"c:\path to output\" works as expected though. Edit: I applied the xEdit 4.0.1 updates to xLODGen beta 0.35 Maybe the latest compile fixes whatever it is that confuses MO.
  6. sheson
    MO prints the log line before xLODGen is executed. I suppose it could have to do with MO being confused by file properties. Create a windows shortcut with the arguments and execute that from MO instead. Or a batch file.
  7. sheson
    Yes. Edit: The log lines show that the path F:\FO4 LODgen Output is not surrounded by quotes. Compare to my log where there are escaped quotes \" around the path.
  8. sheson
    Not sure what limit that would be. This is a first.
  9. sheson
    Yes that requires a clean save.
  10. sheson
    Making a manual save works? Making a quick save works? Are you using SSE Engine fixes? What happens if you remove other large plugins that modify/add a lot of things to Tamriel worldspace? (probably hard to test, I suppose) You notice similar problems in smaller worlds, like interior to Solstheim?
  11. sheson
    Can you leave the interior without enabling DynDOLOD.esp, keeping the esm and the static object/tree LOD? What happen when you disable autosaves?
  12. sheson
    DynDOLOD.exe supports rescanning of the load order and worlds for newly added mods and adding their new objects next to the existing ones into DynDOLOD plugins and regenerating static object LOD as well. Only new objects are added to DynDOLOD plugins and none of the existing ones are changed. New or changed mesh rules will apply to all old and new static object LOD generated by LODGen.exe, but only to new dynamic objects. Existing dynamic objects will stay untouched. Static object and tree LOD is always generated from scratch based on current settings and rules. There is no need to generate LOD just because a new mod was added. New objects may be missing LOD, but that is only a visual problem. Typically it should be enough to start DynDOLOD.exe with the current DynDOLOD plugins and generate (in this case update) LOD for the worldspace(s) the new mod changes. Then merge (overwrite) the files from the output path with existing files from the former generation. A clean save game cycle is not needed, however use an interior save between updates. Check the DynDOLOD SkyUI MCM for the message 'No DynDOLOD for this world' to be sure to not be in a world with any DynDOLOD data. If still not successful, check if a generation from scratch works.
  13. sheson
    I have no problem with xLODGen beta 0.34 and MO 2.16 RC1. it also works using a command prompt or a Windows shortcut. Both versions x86 or the x64. I even download and used the archive from mega. I tested on Windows 7. Make sure to use the correct double quote " around the path Check the MO mo_interface.log in its logs folder. This is what I get [D] Spawning direct process < "C:/Skyrim/xLODGen/xLODGenx64.exe" , "-sse -o:\"c:\\The Output from xLODGen\"" , "C:/Skyrim/xLODGen" > [D] Creating process hooked: < "\"C:\\Skyrim\\xLODGen\\xLODGenx64.exe\" -sse -o:\"c:\\The Output from xLODGen\"\u0000" >
  14. sheson
    Which version? Do a test through via a command prompt or a windows shortcut
  15. sheson
    What are you using to start xLODGen?
  16. sheson
    If you are currently using PapyrusUtil for dynamic LOD, test if updating the papyrus scripts from DynDOLOD Resources to the ones posted here make a difference. If it doesn't make a difference, test if using DynDOLOD DLL instead makes a difference. If neither change anything, set debug true as explained in the readme and see if the papyrus log shows more / posted entire log.
  17. sheson
    The code in xEdit that parses the command line hasn't been changed in ages. Everything still works as expected here in latest xLODGen or latest xEdit.
  18. sheson
    Make sure to put quotes around the path -o:"D:\Modding Tools\xLODGen\Output\"
  19. sheson
    Did you just randomly copy and paste a few log lines? I am confused why the message about the fid files, which should be near the start of the entire process, are that close to the message that it generates tree LOD. There would be lots of other stuff that takes several minutes between that. It is perfectly normal not to find fid files when DynDOLOD is running the first time. The usual reason for such issues are file read/write problems either caused by installing into UAC controlled folders, AntiVirus or MO interfering. Make sure that nothing, game, MO or DynDOLOD is installed into Program Files x86. Do not install DynDOLOD into game or MO folders. Make sure sure UAC/anitivir or other processes does not block any file and folder access. Make sure the destination drive is not full. Other than that, it can be invalid tree LOD billboard textures, though in that case it should happen in the other worldspaces before, since usually SkuldafnWorld does not have unique billboards - but it still could be because of mods. Generate LOD for the worldspace all by itself, see what happens. Uncheck tree LOD in the advanced options see what happens. Check if there are any plugins/mods modifying the worldspace. Check all plugins for errors with xEdit and fix them as possible.
  20. sheson
    The Markarth Worldspace does not use the LOD of its parent world. It has its own drastically castrated cells and land records outside the city (for performance reasons) that does not reach very far. However, the Markarth Worldspace is set to share the persistent "Use Sky Cell" with Tamriel, which is where all models with the Is Full LOD flag reside. the persistent cells of all worldspace that are connected through parent/child settings share it programmatically and visually. I would be possible to add programming to the scripting to turn off certain dynamic LODs object, however I did not bother if you can not see it normally. Another solution would be use have Markath use Tamriel for LOD like the other worldspaces. It's possible that the performance impact is not too bad for Skyrim Special Edition. Or you could let is use its own SkyCell, though I am not entirely sure about other side effects when doing that.
  21. sheson
    xLODGen is based on xEdit, not zEdit. Once the games launcher is started, the folder and files in My Games are created. Unless maybe the OS or some third party software is preventing the launcher from doing that. That should trigger some kind of message. If that doesn't work, let Steam install the legal version of the game into its normal folder structure and try again.
  22. sheson
    The entire dynamic LOD of a worldspace is done by all the references in the persistent cell. 0000D74 for Tamriel/Skyrmi and 040142EC for DLC2SolstheimWorld/Solstheim. If that data removed waterfalls, fires, windmill fans etc should be gone. You might have a second plugin (in MO Overwrite folder?) that loads after the one you are editing.
  23. sheson
    Do not link directly into MO profiles, that is prone to cause problems. Instead let it automatically use the native/official path to the INI like everyone else does and has no problems with. If MO does not map the INI from the profile to C:\Users\[username]\Documents\My Games\Skyrim Special Edition\Skyrim.ini and if programs started from MO executable drop down can not access the INI, then there is something wrong with the general setup of the game and nothing will work properly. If you say crashes, is there an error message or does it just close? That probably happens trying to access files under direct control of MO instead of the virtual mapped ones. What happens when you use the latest xEdit version?
  24. sheson
    If you get a warning "Found Open Cities Skyrim.esp. Do not load this mod when generating LOD Restart and uncheck from Master/Plugin list." for the second run, then not all of the required edits to DynDOLOD_TES5.ini were made. Remove 'Open Cities Skyrim' from the WarnModFileName= list. Comment out all lines under [skyrim Tamriel].
  25. sheson
    Since all data in the DynDOLOD plugins is copied from the other plugins in the load order, it is possible to trace down to the source of problem. As already suggested remove the worldspace from the plugin and check if it makes a difference. If it does, restore the plugin from backup. Then remove the persistent cell. Again, if it changes anything restore from the backup made just before the change. Then start removing reference in batches from the persistent cell. Then move on to the temporary cells, same procedure. Backup the plugin if the error still keeps happening. Restore plugin from backup in case the problem went away and remove other records. That way you will hopefully end up with a singe record that causes the problem. Keep in mind that in 4 years nobody else ever reported such issues, so the source is something obscure.
×
×
  • Create New...

Important Information

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

  I accept