Jump to content

z929669

Administrator
 View Profile  See their activity

  • Posts

    13,028

  • Joined

  • Last visited

 Content Type 

Everything posted by z929669

  1. z929669
    This mod is just better than Embers HD, IMHO. I also think the flames are better than Inferno in all cases. EDIT: Just noticed that the candle flames in the campfire shots are also better for Embers XD (less aura). Not positive that candles are impacted though. Could it be the brightness of the Embers XD flames wash out the aura?
  2. z929669
    Discussion thread: New Thinner Torch by IceKK Wiki Link This is a SLE mod that can be used for SSE. Recommend drop in favor of using EmbersXD version EDIT: I had a version of Ultimate HD Torch that included torch.nif, which is incorrect. Screenshots follow. Note that the flames are largely dictated by the mesh: Ultimate HD Torch + New Thinner Torch + Inferno Fire Effects + Embers HD (Step) Ultimate HD Torch + Inferno Fire Effects + Embers XD (swapping for the Embers XD torch.nif) EmbersXD (all torch assets) I propose we drop this in favor of the mesh used by Embers XD, since the flames look and behave much more believably with that mod's mesh
  3. z929669
    Discussion topic: Embers XD by mindflux Wiki Link NOTE: Embers XD is ENB compatible but performs nicely without ENB. LATEST COMPARES Vanilla vs Embers XD campsite rocks v2.5.6 glow options Campfires: Inferno + Embers HD (Step) > Embers XD (orange/red flames) Sconces: Inferno + Embers HD (Step) > Embers XD (orange/red flames) Torches: Ultimate HD Torch (Step) > Inferno + Embers HD > Embers XD (orange/red flames) NOTE: Torch flames for Ultimate HD Torch and Inferno + Embers HD lick very fast. Embers XD flames lick more slowly and behave more realistically. Forge: Inferno + Embers HD (Step) > Embers XD (orange/red flames) NOTE: FPS gain with Embers XD ... need someone to confirm.
  4. z929669
    Will do ... thanks
  5. z929669
    @sheson I'm getting a new reproducible fault for xLODGen64. It seems to happen towards the end of gen for all worlds during DLC2SolstheimWorld. Log Name: Application Source: Application Error Date: 4/30/2021 10:29:29 AM Event ID: 1000 Task Category: (100) Level: Error Keywords: Classic User: N/A Description: Faulting application name: xLODGenx64.exe, version: 4.1.3.1, time stamp: 0x60705f99 Faulting module name: KERNELBASE.dll, version: 10.0.19041.906, time stamp: 0x2f2f77bf Exception code: 0x0eedfade Fault offset: 0x0000000000034b59 Faulting process id: 0x855c Faulting application start time: 0x01d73dd390256030 Faulting application path: C:\Modding\Tools\xLODGen\xLODGenx64.exe Faulting module path: C:\Windows\System32\KERNELBASE.dll Report Id: 09a8a8fe-346f-444a-8157-e9b313c7ab42 Faulting package full name: Faulting package-relative application ID: Also, does it make sense to replace all instances of LODGenx64.exe with the version you pointed me to (i.e., I replaced this under DynDOLOD 3 alpha but not under xEdit or xLODGen app dirs.)? EDIT: I got around the issue by copying all output from failed run to MO followed by gen of just DLC2SolstheimWorld and DLC2ApocryphaWorld. I then copied that to the mod with overwrite. EDIT2: I just noticed that I generated terrain without first activating the SSE-Terrain-Tamriel.esm ... not sure if that could be a potential cause EDIT3: I should also note that I am running the latest 77 beta UPDATE: It ran without issue after including SSE-Terrain-Tamriel.esm
  6. z929669
    I was getting the same nondescript error code. Sheson provided a tweaked EXE that fixed it for me: EDIT: My system specs are in my sig. You may want to add yours to the wiki and link. There could be illuminating commonalities.
  7. z929669
    I have 32 Gb RAM and found that DynDOLOD64 2.xx will consume all of it at times during generation. This was sometimes an issue for me under that version. AFAIK, 64-bit apps will consume whatever memory they need, so there might be a memory issue if the app wants it. If Windows is not "system managed" with respect to pagefile on a drive suited to it (SSD with free space seems best), or if you don't have the proper 'manual' allocation, you might hit the ceiling. Under DynDOLOD 3.00 alpha 33, this is no longer an issue for me. I found that increasing LODGenThreadSplit in DynDOLOD_SSE.ini to my core # or just under (12/16 in my case) drastically reduced max memory usage on my system during generation. With LODGenThreadSplit=12 on my system, I don't seem to use more than 6-ish Gb RAM during gen, but I would still get your pagefile set correctly if it isn't, particularly under 2.xx of DynDOLOD (assuming that the LODGenThreadSplit setting is not an option in that version).
  8. z929669
    Ahh, OK got it. I use a controller half the time, so the UI tells you what button/key to press to take all from a container ... just like when using the keyboard/mouse.
  9. z929669
    I guess I never tried that ... on a coin purse or when they are scattered? Either?
  10. z929669
    Hmmm .... that sure looks like it could be grass in the distance but colored differently. Res isn't high enough in the screen to tell. This can happen if the DynDOLOD grass coloring isn't set as needed, or TexGen lighting. Are you using ENB? This could be another factor. Grass LOD billboards can be off in color. I see an area closer on the left with same coloring as in distance. If you hide your grass folder in MO (under SKSE64 I think), and generate DynDOLOD without grass (alter all necessary INIs accordingly), then you will have a baseline for compare. EDIT: Don't reloacate your grass data. Wait for sheson to chime in again or go back to the drawing board. There is a lot of stuff that you need to have configured properly for DynDOLOD to be set up for success. Perhaps go through the doc and your build setup. Revert back to vanilla and try that way to rule out all of the potential issues.
  11. z929669
    If they are just loose septims, you can only pick up one at a time. If they are in a pounch, you can take all with the pouch (no other option). If 250 septims and a daggar are on a dead NPC, you have the option to take each or take "all". Same as any 'container'.
  12. z929669
    ok, good ... but set these like so. Set GrassLargeReference to 1 in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini so grass LOD starts right beyond the large reference distance (uLargeRefLODGridSize, typically between 5 = off and 11). Use this with DynDOLODGrassMode = 2 in ..\NetScriptFramework\Plugins\GrassControl.config.txt Run TexGen and DynDOLOD again after with the settings I posted. Reboot PC first. Sort with LOOT first. Also, delete all logs before running again so that you get clean logs after. Also, Cathedral landscapes has INI setting for Grass that override BethINI, so be sure that those are aligned how you want.
  13. z929669
    I have regenerated 3x so far with this file under similar conditions. Issue hasn't resurfaced yet.
  14. z929669
    Since this same exact question was created by same exact member in two different forums, i propose to use only one of them (this one). My response to same question: Logs were also posted over there, but they don't have any useful info AFAIK
  15. z929669
    DynDOLOD_SSE_Log.txt has multiple runs, and the most recent run failed basically just after starting the DynDOLOD program (presumably via MO). So there is no indication of the error. You will need to check your Win event logs at the time to see what caused the issue. Also need to know if it is reproducible. If this only happened once and you can't get it to happen again, then it's a fluke. Restart Windows and try again. You also need to look at the mod page for No Grass In Objects. You need to set cache booleans correctly. and from the DynDOLOD 3.00 OP2: Second option looks best. For TexGen: DynDOLOD: Lastly, please do not post same question in multiple forums if you don't get your answers fast enough. It creates extra and needless work for those trying to assist.
  16. z929669
    Still looking, but I can't see your log at that URL. Just zip/archive your DDL log and any log it references to check at the end of that file and drag to a post. I assume the Tamriel log, but who knows. Need to know what error you are getting at fail.
  17. z929669
    Please explain this Please capture screens of your exact TexGen and DynDOLOD settings and all changes made to DynDOLOD_SSE.ini and GrassControl.config.txt (drag images/files into post). There are several values that need to be changed in the latter, so read the OPs carefully again and also carefully read the instructions on No Grass In Objects mod page on Nexus. Finally, please post any relevant messages in DynDOLOD_SSE_log.txt and files it calls. It should take you 1-2 hr to precache grass successfully, and grass could be under SKSE64 mod if you use MO (or possibly overwrite).
  18. z929669
    It occurs about half the time in expert mode with increasing chances for longer runs (generating dynamic LOD, ultra). Same two errors repeated in tandem several times over the past few days, so reproducible. Never any error output to terminal that I can see. LODGenx64.exe just quits and xEdit window remains open with error message.
  19. z929669
    From the Event Viewer: --------------
  20. z929669
    I have been getting this error about half the time I run DynDOLOD lately. No additional info though so hoping you have a clue. A couple of other users have reported this error and no further error info in the logs indicated: [43:59] <Error: LODGenx64.exe failed to generate object LOD for Tamriel. LODGenx64.exe returned E0434352. Check C:\Modding\Tools\DynDOLOD-3.00\Logs\LODGen_SSE_Tamriel_log.txt> Logs.7z EDIT: Seems to happen mostly(only?) when including grass LODGen ... so longer or more intensive DynDLOLOD runs seem to produce this.
  21. z929669
    Question: I know that 3D trees require modified static based upon the full model with matching CRC in the file name of the static, so any changes to the base model will 'break' pairing with the 3D static. The same is not true for billboards created by TexGen though, correct? Those match on the plugin formID, right? So if I have a mod with a custom tree with matching 3D static (obviously referenced by the mod's plugin) and I alter the base model for that tree without updating the corresponding static, DynDOLOD won't generate the corresponding 3D tree. However, TexGen 3 will still generate Billboard1/2 for the base model, and DynDOLOD will use those ... ?
  22. z929669
    Just noticed a small UI-tooltip inconsistency: I think this should be same as:
  23. z929669
    Since these actors are not part of the static LOD, they are not going to show up until inside uGrids or loaded cell.
  24. z929669
    That looks like a trunk mesh without a texture. Use More Informative Console to discover the mesh. Open the mesh in Nifskope to discover the texture. Add the texture. I assume something may have gone wrong in copying assets from DynDOLOD output, or one of the mods does not properly reference it's textures or the 3D statics it has are not pointing to the correct texture.
  25. z929669
    I looked through all of the similar mods already, and found that this one is the 'best' in addressing the 1st/3rd person issues (same as 1st Person Candelight Fix) and also removing the horrible aura. Lastly, it repositions the little floating light slightly higher so that it's not right in your FOV. All-in-all, I think it is an ideal replacement. If you find something as good or better that doesn't go too far with changing things, happy to hear your perspective. Mainly looking for feedback on whether people agree that this is preferable to 1st Person Candelight Fix.
×
×
  • Create New...

Important Information

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

  I accept