Jump to content

z929669

Administrator
 View Profile  See their activity

  • Posts

    13,086

  • Joined

  • Last visited

 Content Type 

Everything posted by z929669

  1. z929669
    Thanks both. This is now fully comprehended by yours truly. Though both of these methods are plausible, I think it intuitively seems best (if practical programmatically) to implement what I call the 'layered' approach by which all rules are consolidated according to governing global/local/load-order prioritization and processed into a final rule set. This seems like a more foolproof way to effectively preserve user-created rules unbound to any plugin in the same manner as shipped rules are preserved.
  2. z929669
    Thanks, I'm getting there ... So if I have a saved preset with a bunch of custom rules I have painstakingly configured and ordered AND I have a new plugin from a mod that I created with a rules config file that I want added to my mesh processing rules, then the ONLY way to get everything from BOTH is to: Click low/medium/high - this loads all predefined rules that ship with DynDOLOD and also loads my new plugin rules (I finally understand this ... unless I don't ) Load my saved preset - this loads all of the custom rules I created previously but wipes out all of the rules applied via #1? (and my new plugin rules will still be there OR will be processed from my plugin-loaded INI?) Is it impossible to get both? Trying to find a foolproof method that will include all of the shipped rules AND all of my own 'global' rules AND all of my plugin rules I do understand that if I somehow can get all rules I want into the GUI grid, I can save that and get it back whenever I load them in the future (and loaded rules will also be saved as 'default' for next run if I take none of these actions next run)
  3. z929669
    This still doesn't answer my question explicitly ... I must assume/infer from your responses. I understand about plugin-loaded files (including INI definitions). I want to know: if I have a plugin with associated rules as described in the documentation, will my pligin-loaded rules be read and applied by DynDOLOD if the plugin is enabled in my load order, and ... I do not click a low/medium/high preset In DynDOLOD GUI and hit 'OK'? I load my own previously-saved preset In DynDOLOD GUI and hit 'OK'? (saved before I began using the plugin that is loading my NEW rules) I completely understand that rules added into the rules grid in the GUI will be wiped out if I click on a preset or load a saved preset. That is intuitive and apparent. It is the rules conveyed by INI in the background I want to understand. Follow-up question: Are plugin-loaded rules added to the preset and saved between runs just as those I add via the GUI rules grid?
  4. z929669
    I did, but again, it's not necessarily stating this: I added this Maybe no rules are read from anywhere, including mods without clicking low/medium/high in the GUI, but that would be a faulty implementation I believe. It's not foolproof. Loading a preset does not require clicking one of those buttons, so plugin-loaded rules would still need to be loaded. Maybe I'm being dense ... wouldn't be the first time
  5. z929669
    I didn't see those words in the doc. I think the doc is more/less saying that the GUI rules will replace any custom rules applied via the GUI window. From my understanding, plugin-loaded rules will apply regardless. Perhaps it was posted explicitly here, or I missed those words in the doc? I added this EDIT: But totally agree that we shouldn't be supplying preset files that user loads via the GUI
  6. z929669
    As usual all good info, so thanks for that. Still want to know if these rules will be read (not necessarily applied if superseded) regardless of whether or not I load a preset or click low/medium/high (or ONLY if I also use a preset, or not at all because this method is wrong): Create DynDOLOD_SSE_{whateverWeLike}.ini with following content and place it anywhere in my mod list (or must it be tied to a specific plugin name?): [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,
  7. 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.
  8. z929669
    need to check new optional file to see if this is better: Embers XD - Patch - Glow Eliminator
  9. 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?
  10. 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.
  11. 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.
  12. z929669
    We still want SMIM compat, correct?
  13. 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.
  14. 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
  15. 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%
  16. z929669
    Fixed
  17. 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.
  18. 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.
  19. 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.
  20. 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)
  21. 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).
  22. 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.
  23. 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
  24. 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
  25. 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)
×
×
  • Create New...

Important Information

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

  I accept