Jump to content

z929669

Administrator
 View Profile  See their activity

  • Posts

    13,028

  • Joined

  • Last visited

 Content Type 

Everything posted by z929669

  1. z929669
    Very useful specifics ... however, I want to be sure that these are NOT corrections to my post but more information that can be used to confirm assumptions. I did not mention clicking on high/medium/low buttons, and I did see this in the doc: ... are you saying that NO rules will be applied (regardless of path) if these buttons are NOT clicked (even custom rules)? This statement from the doc: ... implies (IMO) that a rule file lacking *_low|medium|high.ini suffix is applied independently of whether or not any of the presets are clicked (or when ANY of the presents are clicked?). Was anything I posted just flat-out wrong? No need to explain why if so, since there are ways to verify as you mentioned. It would just be helpful to me and possibly onlookers if you specify any incorrect assumptions in my post so that I can correct once I know for sure ... to block any misinformation.
  2. z929669
    need to check new optional file to see if this is better: Embers XD - Patch - Glow Eliminator
  3. z929669
    From the documentation and sheson's last comment on this ("Anybody uploading presets for guides should remove the outputpath line"), I believe that the rules are layered. So if a higher-priority path defines a mesh mask same as that of a lower priority path, the higher priority wins. Any new rules sheson adds to a preset should be highest priority, since no others exist. Also, If a more specific mesh mask applies at lower priority, I think that it would supersede a more general one at higher priority. I am thinking that priority is defined by ini file path AND LODGen# within each file. I am not clear on how this line numbering behaves between files though ... if our custom rules use LODGen1-LODGen3, then they should be higher priority than same rules defined at LODGen11-LODGen13 in a lower-priority path. Also from the doc, I see that [Skyrim LODGen] section is the default, so I am assuming that if we stripped everything out of our supplied general (not mod-specific) presets except the rules we are specifying, this should combine with but supersede the 'default' preset shipped with DynDOLOD. I think naming this like DynDOLOD_SSE_{whateverWeLike}.ini should work without tying it to any specific mod. Content (our custom rules) would be like: [Skyrim LODGen] LODGen1=mountains,Level0,Level0,Level1,None,FarLOD,Unchanged,1, LODGen2=\rocks0,None,None,None,None,None,Unchanged,1, LODGen3=treeaspen,Billboard4,Billboard4,Billboard1,None,FarLOD,Unchanged,1, @sheson Can you correct me if I have any of this wrong?
  4. z929669
    @TechAngel85 DY wants to accept this one it looks like. I don't have enough info/opinion to say either way. What do you say? We only need to look at conflicts with ELFX and determine what to use from each if using both. I can do that at some point, but I'm not checking all of these meshes against vanilla and ELFX. Word of mouth is fine with me.
  5. z929669
    I vote to accept this one per Tech's posts. I admit I haven't tested this, but Tech has (extensively), so I second.
  6. z929669
    We still want SMIM compat, correct?
  7. z929669
    @DoubleYou Does your map mod rely on this? If not, lets abort testing for this. I strongly advocate your new mod be accepted for 2.0.0 outright once posted.
  8. z929669
    Yeah, I fixed it on the wiki. Might take some time to propagate to the guide but the mod page is correct on the wiki. Will check the forum though ... not on forums yet
  9. z929669
    We have tested with larger/taller grass in NGIO, and this produces a similar effect without the performance hit. DynDOLOD runs fine. Give that a try. DynDOLOD grass density can be as low as 35% and still look 'full' under these conditions. i forget the grass size scale we used, but I would go with something like 125%-150%
  10. z929669
    Fixed
  11. z929669
    OK, I just looked at the mod, and you should be using the Main File (you linked an archived version it seems) as well as the Billboards Optional File. https://www.nexusmods.com/skyrimspecialedition/mods/50961?tab=files This mod doesn't have any 3D LOD models that I can see, so you can use "traditional tree LOD" in DynDOLOD 2/3 I would think.
  12. z929669
    Why do you continue to not provide the logs from your DynDOLOD runs? We have mentioned numerous times that this is the only way sheson can help outside of guessing.
  13. z929669
    In that case, keep testing the vanilla profile, and ensure some best practices as described in our system setup guide. Also ensure that this isn't an issue by following the best answer here: Lastly, see first post and provide your logs as instructed. There should be at least two logs and possibly a bugreport.txt in root of your DynDOLOD installation. Truncate the debug log to last run or simply delete all logs before running again against vanilla profile. Otherwise, they are too big.
  14. z929669
    Be sure to clear out previous TexGen output and that all required mods are active and none of those contribute files conflicting with that output. If all else fails, load a vanilla-only profile (if using MO or Vortex) and try that. If that runs, you know it's an issue with one or more mods in your mod list (or plugins in your load order, which should always be sorted with LOOT prior to running any of these apps)
  15. z929669
    Also, keep in mind the difference between loading a clean save, a normal save, or a new game. There are also a couple different versions of the patches that have different dependencies (I assume), so be certain you are set up to use the latest main File patch and that your save is compatible with that (hence try new game).
  16. z929669
    Run it again, and this time, as was mentioned "click 'help for this message'" if the error box appears again. Then copy/paste that. Then look for bugreport.txt in root of DynDOLOD dir. Then find relevant log and debut_log in /Logs. Then post. Also try rebooting or generally resetting your modding environment if you know how to do it manually without a reboot. Part of the problem could be OS related.
  17. z929669
    I believe the problem is that there are > 1 causes for this rather generic error. It's either the 'security'-based issue (which you have resolved via Windows Security exception(s)) or one or more other problems that are possibly more (or no more) syntactically accurate with respect to that terrible error message. In other words, I think it could also be a bad texture, NIF or other file-related issue. This would explain why it happens seemingly at random. I would post logs and bugreport.txt if you have them (tip: delete logs after last good run so that each log is only as long as last run). Also, a reboot can resolve in some cases ... see best answer on this topic
  18. z929669
    Run it again, and this time, as was mentioned "click 'help for this message'" if the error box appears again. Then copy/paste that. Then look for bugreport.txt in root of DynDOLOD dir. Then find relevant log and debut_log in /Logs. Then post. This way, you will get the path to answers. Otherwise, only a remote Vulkan mind meld would maybe help
  19. z929669
    @sheson You may already have plans to address this, but I bet you are more weary than I am of seeing questions about "The system cannot find the path specified" and the resulting assumption that it is a TexGen or DynDOLOD application issue. If you have some method of detecting the probability of the cause, a simple error message change should avert/assuage at least half of these erroneous assumptions/conclusions. Perhaps this is a general OS message over which you have little/no control, but it is doing you a disservice ... "cannot write to the specified path, due to some process that blocks write access" (maybe even worth months/years arguing with MS support to improve their generic messages)
  20. z929669
    I use this one, and it's very handy ... although I have not set it up completely. If you care to install this with all three of the mods mentioned as we have them configured in the guide and tweak around to see what you find out, that would be helpful. I mostly do targeted mod config and testing outside of standard gameplay and likely have not had issues because of that; however, I suspect it's just a matter of configuration to get all of these working properly together (I just don't have time to test the unsupported setup with controllers): https://www.nexusmods.com/skyrimspecialedition/mods/5682
  21. z929669
    This generally isn't necessary, but it's good practice, especially with a modded setup. Whenever you are in a dungeon or any non-worldspace cell, you are technically 'indoors'. If I really care about a save game, I will typically go into a mundane, small NPC home. Anything is less problematic than outdoors. It is related to scripts, timers, and triggers in effect, and there are always a lot more of those outdoors or in very active cells.
  22. z929669
    Try loading the last save, and go into a interior cell (indoors) before saving. Do nothing else. Then try to load that save. If it loads fine, talk to the NPC and go indoors again to save. When modding a game, it is important to save your mod-manager profile before changing your setup if you have a save that is important. In MO or Vortex, this is easy. Then you make your changes in the new profile. If there are issues, you can easily go back to your previous profile as a fallback. There are ways to check and troubleshoot the problematic cell, but that's complicated. That error is essentially meaningless and unhelpful, IMO, since the count is identical. Others may have specific advice for this error. I don't play so much as mod, so saves are not really anything I care much about for my own games.
  23. z929669
    Always save indoors as a first measure when trying to fix. Always use uGrids 5 if that has been raised. What exactly changed between your setup that generated that save and your current setup? Reverting to that previous setup should resolve, and then you can go from there, adding changes piecemeal.
  24. z929669
    How do you know controllers are not compatible with these mods? I think some workarounds have been posted for issues with these mods and controllers if you search these forums. I use a xBoxOne controller and have found no issues. I also use a remapping mod for that controller. Sounds like you need to mess with your configuration. We don't support controllers (or mention them) because there is so much variation in what people use and how they may or may not want use it. The mod you are suggesting has no clear description. Why use SkyUI if you are going to hide its menus? SkyUI makes the vanilla menu system much more efficient and usable on a PC in our opinion (which is why it is recommended and the most highly endorsed SkyrimLE/SE mod of all time). I don't see any rationale or before/after screens that would make me want to use that mod. Seems like a personal choice (for whatever seemingly-illogical reason).
  25. z929669
    Discussion topic: Pine Branches Redone by TheSithLord Wiki Link Looks like a promising optional enhancement to EVT and vanilla trees in general Doesn't look right with EVT. Causes duo-tone branch colors, darker on top.
×
×
  • Create New...

Important Information

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

  I accept