Jump to content

z929669

Administrator
 View Profile  See their activity

  • Posts

    13,086

  • Joined

  • Last visited

 Content Type 

Everything posted by z929669

  1. z929669
    That makes sense ... I launched the latest experimental mentioned and let it attempt to generate tree LOD. Plugins loaded without issue (i.e., no Dlephi error). So that was some random fluke. I went back to beta 81 and invoked via shortcut. Same random event resulted. It quit durring LODGen of DLC2SolstheimWorld this time. I searched the event and found that it is an unhandled Delphi exception: https://stackoverflow.com/questions/16602756/strange-0x0eedfade-exception-in-delphi-multi-thread-program I am happy to test resolutions if this gives you any path forward.
  2. z929669
    To confirm: Large ref system is in effect only in NearGrid range (11 to 21 cells by default)? Setting "NearGidToLoad" = uGrids turns OFF the large ref system, and setting to any value higher than uGrids turns it on? Ticking "Upgrade NearGrid Large Refs" when the large ref system is OFF ensures that dynamic LOD shows beyond uGrids up to but not beyond FarGrid? Ticking "Upgrade NearGrid Large Refs" when the large ref system is ON ensures that dynamic LOD shows beyond NearGrid up to but not beyond FarGrid?
  3. z929669
    What is the proper command-line switch to invoke terrain LODGen? I am using: -lodgen -sse This only gives me object/tree
  4. z929669
    Ah yes, I know that guy. Thanks
  5. z929669
    I would be happy to, but I'm afraid that I don't know how to use it from source. If I did, I would still need to figure out how to invoke the xLODGen piece. https://github.com/TES5Edit/TES5Edit/releases/
  6. z929669
    Finally got it to spit out something informative (still no bugreport, but got a delphi error in SSELODGen log). I rebooted and ran on a clean env with no MO or other utilities running. This is just running xLODGen via shorcut as described: LODGen_log.txtSSELODGen_log.txt
  7. z929669
    You must not have installed and configured in same way. I have none of that. OP has instructions that are accurate I believe. You definitely have something going on that I do not. I agree that's wild. EDIT: what inn is that? It's not the sleeping giant in Riverwood or the bannered mare in whiterun ... on second look, the EmbersXD flames are bigger. They should be toned down for campfires (at least the cooking ones if possible). That's why you see all of the smoke and sparks (volcano). It's definitely more realistic, albeit too much for a cooking fire. Regardless, the flames are better and brightness is fine with orange/red, IMO (see OP screens). The flames are also more realistic and animated more slowly than Inferno. What "other issues", because I found a lot of issues with Inferno and the Step torch/campfires. The main one is the super-fast flame animation. Also the coals (Embers HD I think) look like cartoons (again, see OP). Finally, the inferno flames are just not as realistic, IMO. They seem too 'furry' I guess is how I will describe it.
  8. z929669
    @sheson Running just xLODGen.exe with command switches from command line (or shortcut) yields same result with 81. No bugreport, no SSELODGen log, just quits with same event error.
  9. z929669
    OK, sounds like you and Greg will have ideas on that config. I am magic-ignorant with Skyrim. Never used it much at all. Probably because it was so lame
  10. z929669
    yes, that's what happens pretty reliably, but never at same point in process. Will do
  11. z929669
    First, .Net script framework is not an issue and should be installed if needed. You need to set it up properly of course in MO. grassControl.py is a script and not a mod. It must be placed into ../MO/Plugins directory. MO can also be installed in two ways and improper config of executables and profiles can also cause issues. Skim through our SE guide to check how to configure .Net Framewhork, MO, MO plugins and EXEs, etc. The TexGen error is because you previously moved content from TexGen_Output location and into a mod that only you could have created. If you don't know what the TexGen_Output location is or where it is, then you have not set up DynDOLOD according to standard instructions provided by that app and any number of other guides, including ours. It could be in Overwrite if you did not set things up correctly. This is all part of DynDOLOD config and MO EXE setup covered in the guide I linked. If you find your TexGen output, you simply right click the mod in MO and "Open in explorer". Delete files. You can also do the same thing via MO interface.
  12. z929669
    I am only posting what is available. No SSELODGen logs are created for these runs. no bugreport. System memory and disk are A-OK, and I don't think it's antivirus, since I would expect that to impact right away. These runs just randomly fail at varying times with no error outside of the events posted. Plus I have run these programs successfully many times before. I think it's these particular versions of late. If you point me to one of your versions prior to beta 77, I could give them a try to confirm. Otherwise, I will continue messing with 81 and the version you linked just above. I can try running after fresh reboot and under varying conditions to rule out any system issues.
  13. z929669
    For automated patching, Mator Smash and zEdit are probably more up to date and usable. I'm not sure if either works for LE though. I still wonder why people are running LE now.
  14. z929669
    I understand that this setting enables creation of *.btt files (I assume from plugin tree references) and hence, traditional tree billboards LOD. No tree object LOD will be created. Do non-tree mesh rules still apply when "Create object LOD" is ticked? When NOT ticked? From the doc: This is not possible. Ticking 'Ultra' automatically unticks "Create tree LOD" I don't understand this statement. Can you give an example of such instructions? I also don't understand this statement. "keep using" and "earlier" imply I ran it previously, so is this only useful during a second pass? Can you elaborate?
  15. z929669
    To be clear, previous bug reports are for latest full package for 81. Just ran again and it quit during Apocrypha without a bugreport or SSELODGen log. Only LODGen log: LODGen_log.txt Event: Tried again with 81 and no changes. Quits during Tamriel gen with no bugreport of SSELODGen log: LODGen_log.txt Event: Same issue a third time, same outcome. This time during Blackreach: LODGen_log.txt ... so I am not getting same errors that invoke bugreport, but nothing has changed but time since I had the two errors yesterday (so those are obviously not reproducible). Event: New file just posted: Same exact problem and outcome, this time during SolstheimWorld: LODGen_log.txt Event:
  16. z929669
    https://stepmodifications.org/wiki/Guide:Mod_Organizer#SkyProc_Patchers
  17. z929669
    I have read through the forums and searched this topic. I understand that Skyrim does not differential near grid from far grid but only uGrids from far grid, so dynamic LOD only applies outside of uGrids. Skyrim SE differentiates uGrids, near grid, and far grid I still don't fully comprehend: Checking the box Does this automatically set uLargeRefLODGridSize = uGridsToLoad in the background, because the settings GUI do not reflect this ... perhaps it is advice to consider doing so manually? "Near Grid" = uLargeRefLODGridSize? This claims "better visualizations" in the DynDOLOD GUI, can you elaborate? A large ref object is flagged as such by the plugin, and it has LOD: what happens inside uGrids and uLargeRefLODGridSize? Potential for z-fight only in the latter? Setting both to '5' resolves? At what cost to visualizations and/or performance? What is the advantage of SSE uLargeRefLODGridSize (pretend the large ref bug doesn't exist and this works perfectly) What is the disadvantage, given the LR bug in SE? NOT checking the box "in case the large referene system is used" - in SE the large reference system IS used, so this phrase confuses me. Mesh rule assigning a large ref to near grid will be overriden and vice versa? This setting is ideal if and only if all large refs are flagged properly by the 'winning' plugin? (otherwise, either fix each or "check the box"? *For best quality it seems that "Upgrade NearGrid Large Refs" SHOULD be ticked and uLargeRefLODGridSize > uGridsToLoad >= 5 ... is this correct? Is the caveat that there may be some z-fighting for large refs improperly flagged? *For best performance, it seems like "Upgrade NearGrid Large Refs" SHOULD NOT be ticked and uLargeRefLODGridSize > uGridsToLoad >= 5 STILL should be used. To avoid the LOD/full large ref conflic problem, then we can do uLargeRefLODGridSize = uGridsToLoad to fix the large ref issue at the cost of some performance ... is this correct?
  18. z929669
    Will do so next time. I cleaned out my logs and only have a successful run right now. As usual, I as able to complete in two partials.
  19. z929669
    Yes, but I'm trying to get a bit more info as to why some of the textures are so different. Currently, I am running terrain LOD with the xLODGen file overriding the DynDOLOD file textures (it provides only a handfull). Then I will gen object lod as normal after deactivating the xLODGen file. This may be completely redundant, but I want to hear it from the horses.
  20. z929669
    @sheson Finally got a bugreport.txt with this latest version of xLODGen: bugreport.txt EDIT: Reran and got another. Including logs as well this time: bugreport.txtLODGen_log.txt
  21. z929669
    @T4GTR34UM3R & @sheson While we have you both in here, and it's pretty quiet, I'd like your input as to how to treat the two LOD-specific files provided by MM: One file provided for use with DynDLOLOD and another for use with xLODGen. The xLODGen file provides only textures and is completely overwritten by the DynDOLOD file, which has many more assets and overwrites many of the DynDOLOD Resources 3.00 files. The seemingly redundant xLODGen textures are very obviously different than those same assets provided by the DynDOLOD file. Since there aren't any instructions that I can find on the MM Nexus page (sorry if I have missed them all this time), I have to think that T4's intent was that xLODGen be run with that mod active to gen terrain LOD and THEN activate the DynDOLOD file before running DynDLOLOD for object LOD. This is contrary to most of what I have learned generating LOD (no other mods or instructions I know of use the different versions of the same textures for these different pieces of overall LODGen). hopefully, you can both see that the textures are different just by looking at the thumbs in explorer: Note that the textures are on the same path. Intuitively, it seems like both texture versions could be used at different times, depending on what of the two mods is active, because a given mesh could use either version of any of these textures. Also intuitively, it doesn't seem like terrain LOD will generate anything that conflicts with object LOD, so this confuses me.
  22. z929669
    I think it's definitely an improvement from the screens. installing.
  23. z929669
    Seems like a no-brainer to me. Nice find.
  24. z929669
    Seems like a no-brainer to me. Nice find.
  25. z929669
    Seems like a no-brainer to me. Nice find. I particularly like that it is basically addressing vanilla meshes not covered by MM (or improving certain MM meshes, IDK?)
×
×
  • Create New...

Important Information

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

  I accept