Jump to content

z929669

Administrator
  • Content Count

    7,130
  • Joined

  • Last visited

Everything posted by z929669

  1. It's not reliably reproducible. The file I posted contained two separate errors that occurred in two runs one after the other. The third run went without issue. All three runs were exactly the same but for the time.
  2. Yes, not sure if this is informativeAppErrors.txt
  3. So no bug report or anything useful. All logs for this run attached, including TexGen logs in case they have any clues. I am running again and will watch the DynDOLOD xEdit process this time ... meh. Logs.7z EDIT: My DynDOLOD settings for these failed runs. This is the only piece for which I have made any changes. INI settings haven't changed for past 20-ish successful runs. Maybe the Billboard2 changes for the wrTemple* trees? I assume all settings here have fallbacks. EDIT: Well, I guess the app wanted my attention is all. Absolutely no changes aside from me watching it for 20 minutes straight to confirm the LODGen64 process started without DynDOLOD closing. Completed successfully this time with those settings.
  4. It's strange and looks like it's going to happen again. Symptom is that the DynDOLOD xEdit window closes, while LODGenx64.exe process continues running. Once that is finished, it just closes, so my issue is the DynDOLOD process. I will post relevant log(s) once completed.
  5. DynDOLOD quit unexpectedly after about 40 min with no helpful details but for the following from end of LOSGen_SSE_Tamriel_log.txt: ... plants\srg_shrub01half_n.dds=7: 2162 -> 2245 | 130, 4 Log ended at 2:29:57 PM (35:41) Code: 0 What is "Code: 0"? First issue I have had for alpha 33 (I have run with many varieties of settings around 30x on full modded setup). The new *Threads* INI params have completely resolved memory management issues for me (32 Gb system RAM, 8 Gb VRAM here), which occasionally 'broke' running object LOD in 2.xx beta when upwards of 30 Gb system RAM utilized. I will run again and post back with more detail if issue repeats.
  6. If you are using EVT - Lush/Large with the Alternative Trees optional file, then this is a known issue. I have submitted an updated version to the mod authors, which should be available soon-ish. If you are not using EVT with those options, please disregard this post.
  7. I fixed issues related to Alternative Trees optional file. See the latest bug reports for details.
  8. Most of our xEdit gurus are either taking a break from modding, retired from modding, or AFK. I am personally an xEdit hack and use it only as a reference. My advice is to make your changes and examine results. Nothing like diving in as a learning process
  9. You can drag nodes or the plugin header to copy all. Otherwise, I don't think you can edit more than one record set at once manually (in the right pane). Tools like Mator Smash can automate much of the manual labor, but you still should probably check results in xEdit if you understand what the records are doing. That tool is also fairly mysterious and is no longer under development, AFAIK. Mator may still be reachable here or on Nexus for questions, but the tool works.
  10. We technically need the mod to incorporate the fixed file(s), due to copyright and permissions. We can link to this report though.
  11. Yes, that should do it. Change and restart PC. If you still get the error, then sheson may have some instruction.
  12. Thanks for letting us know. Are you following the Skyrim SE guide or the LE guide? The mod page you linked is for LE, not SE. Regardless, LOOT is saying that this fix is already present in the USSEP for SE: In MO: Double click on the mod Select Optional ESPs tab Select GQJ_DG_vampireamuletfix.esp Click left-pointing arrow to move it to "Optional ESPs" in left pane This will remove the redundant plugin. Re-run LOOT and re-sort. The same process applies to LE. I will update the guide instructions
  13. Do you have a 64 bit PC with 4-8 GB system RAM? You will want to enable your page file and let your OS manage it. In Win 10:
  14. No worries, but if you ever do rebuild grass cache, please do share details Vids look good.
  15. I played around with distance INI settings for LOD and grass, and reducing to "BethINI Low" quality from "BethINI Ultra" had almost no perceptible impact on my FPS. Same for shadows and a couple of other INI tweaks. I finally recovered about 10 FPS by reducing the LOD distance settings of DynDOLOD via the MCM menu (using defaults now with extended LOD16 and tree view distances). Previously, I had doubled all distances for LOD levels and trees, so going back to default for LOD4/8 gave me some frames back without affecting in-game quality.
  16. The guide itself is obviously here: https://stepmodifications.org/wiki/Fallout3:Unofficial-Kelmych-1.0.0 To edit, just log into the wiki using your forum password (select 'remember' checkbox), and select the asterisk to go into 'edit' mode to make changes. You can either edit the entire page from the top menu or by section as indicated below (probably easier to find what you want to edit):
  17. ok, so your lower grass density will impact length of time to pregen, but possibly so will your grass distance and LOD distance settings (I'm guessing here). All things being equal, you should be able to generate in less time than me, but almost certainly not 1/3 of the time. I'd think like 4/5 or 3/4 or possibly even 2/3 would be more expected. If you are getting 80 FPS when taking that shot, my guess is that this will go down a bit if you have 100% grass (like me) and possibly if you increase the distance settings similar to my own. Would you mind pregenning with the settings I used to test at a time when convenient for you? No rush at all. Just changing grass density to 100 and your INI settings and to mirror my own as I described should be all that is necessary. If you are also running SE 1.0.0, we don't need to consider mod diffs for objects, trees, and grass. This will give us a "high-end GPU" grass pregen baseline for the 'ideal' ultra settings. I will search for changes that get my FPS up to 45+ or 60 if possible, but first I need to get my performance with 2.xx DynDOLOD and maybe tweak some things to get to the 45+ lower threshold outdoors!
  18. See my appended Qs in previous post ... GPU is the limiting factor, and your GPU is better than mine, so that explains some/most of it. What i7 are you running? I think my grass settings are a good deal higher than yours set via NGiO, but I am not sure how that thing works, so that's why I disabled all of those and let BethINI handle it: OverwriteGrassDistance = -1 OverwriteGrassFadeRange = -1 OverwriteMinGrassSize = -1 Almost forgot: What monitor resolution are you running? I cap FPS at my monitor refresh (144) and at 60 in load/menu screens. Outdoors, I get between 30 and 144 FPS, depending on where I am. Indoors, I am always maxed out. Monitor res is 2560x1440 NOTE on precaching grass: While I ran this for about 1:45, the game loaded to a loading screen, and I had my Radeon metrics monitor up. Game restarted about 20x and GPU was working hard at some points, maxing fan and clock. No issues though.
  19. This mod shouldn't have this issue, since it doesn't seem to have been recently updated, and the instructions don't mention it. I don't remember. Depending on how MO informs you as you download install: Download and install the Main File. MO will prompt the user. Expand the FNIS Behavior SE x.x.x folder. Right-click on Data and select Set data directory. Click OK to install the mod. Enable the mod. Alternatively, right click on the downloaded mod installer and "Open file", then you can manually drag files around to fix. To do this: Install the mod and ignore the warnings right click the mod in the MO left pane and select "open in explorer" Move files around here or delete and drag files from the opened installer archive, situating as normal (see other mods or the "Data" tab in right pane fopr proper structure)
  20. So since your grass precache took only 1/3 the time it took me, I must assume that skyrim INI view distance and settings in addition to No Grass in Objects (NGiO) and DynDOLOD 3.00 INI settings play a factor. I have turned off NGiO 'master' grass fade/distance/render settings in favor of letting skyrim INI keep that control. I have also set NGiO 'use' precache grass settings to True. My relevant BethINI distance settings: EDIT: What kind of FPS are you getting when you are taking that shot? What are your skyrim INI settings (i.e., BethINI) If you restore your TexGen and DynDOLOD 2.xx mods and resources (and properly reinitialize DynDOLOD) with pre-cached grass, so you see any difference than with DynDOLOD 3.00? I ask because the precached grass is still in effect, and it also improves 2.xx as far as I can tell.
  21. I followed exactly as instructed in the DynDOLOD 3.00 OP1 and OP2 posts. I used the settings corresponding to using "DynDOLODGrassMode = 2" in No Grass in Objects mod. Otherwise, my run settings are as posted (basically mirroring what we have in the current SE 1.0.0 guide where there is overlap). Ran Terrain and Occlusion as in SE 1.0.0 guide but with 3.00 resources and pre-gen grass (which gets placed into SKSE64 > /grass in my setup). This config was quite taxing on my system, which is high-end (see sig). My limitation is only my GPU, which is pretty much near top of the line for Radeon, but Nvidia hardware probably is better. I am also running some 4K stuff that I probably don't need to be running. I'm only mildly overclocking my system and not overclocking my GPU beyond it's base config OOtB. I am regenning LOD again now with lower settings and will post once I have data finalized.
  22. ... so then it sounds like the mips are used by the full textures in the span of the fade transition rather than in LOD4. Here is a vid of transition on terrain, but it's probably grass object and not terrain I'm thinking. Very subtle. See center screen.
  23. True. I just mentioned it, because the settings I linked don't have that and to spur any comments as to the legitimacy of doing so.
  24. Doh. I hadn't seen that. Ok, carry on!
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.