dunc001
-
Posts
468 -
Joined
-
Last visited
-
Days Won
3
Everything posted by dunc001
-
My bad, I thought I had deleted the entire contents, I must have just overwritten. Working fine now, apologies for the false alarm.
-
I am trying to update TexGen/DynDOLOD output on an existing game (just added Bruma in so need to run it all again). I have also downloaded the latest Nexus releases of the DynDOLOD 3.0 and the Resources. However I am hitting a problem at the very first thing I try to do. I have followed the correct in-game procedure to disable the previous DynDOLOD. I have made sure there are no billboards in MO2. I have generated a new grass cache. I then launch TexGen, it runs through all of the plugins and gives me the generation options screen. However as soon as I click Start I get another popup with options to Exit, View Log or Restart. There are no errors in the log window. Any advice would be appreciated. bugreport.txt TexGen_SSE_Debug_log.txt TexGen_SSE_log.txt
-
Apologies - something had got messed up when I installed 2.71. Wiping it and starting again it's all working fine. -
For some reason, after updating my standalone install to 2.71 whenever I now try to run TexGen or DynDOLOD through MO2 I am getting a warning popup: These are my settings, which have not changed since I last ran: I have not renamed the executables. I deleted the previous installed files completely and then unpacked 2.71 into the same directory, so no leftovers. Any idea how I can fix it?
-
So I tried adding -o E:\Skyrim SE\xLODGen\xLODGen Output\ to the arguments line in the executables setup in MO2 (tried with and without parenthesis around the path) and the result is the same as posted above each time. What am I doing wrong?
-
So running it through MO2 doesn't automatically place everything into the 'virtual data folder' (aka overwrite)? I checked in my actual data folder after running it and there are no new loose files at all, just the original bsa's. Like I said I'm pretty sure everything was output into overwrite but whereas I got this as mesh output: I only got this as texture output: I have some HD terrain LOD mods activated, and I have TexGen and DynDOLOD output enabled when I ran this. So does that mean that only those two worldspaces were missing terrain LOD textures and the rest had as good if not better already than what would have been output by xLODGen?
-
I've just run this (Terrain LOD only, not Object/Tree LOD) for the first time on a full load order (230+ plugins and a lot of new worldspaces). It took 7m31s. It seems to have generated meshes for all worldspaces but only textures for two of them. There were no errors in the logs but a lot of 'skipping this because they already exist'? Am I doing something wrong? I went with the various test settings alt3rn1ty posted on page 3 of this thread with LOD4 and LOD8 textures set to 888, others to DXT1 if any of that makes a difference. I ran it through MO2. I have renamed the x64 exe to SSELODGenx64.exe. Is it also supposed to generate an esm, because if so it hasn't. The meshes and textures which were generated were placed in the MO2 overwrite directory. LODGen_log.txt Edit - Ignore the esm comment, I had missed the links in the OP for the optional esm!
-
OK, so neither the Unknown2 flag or the bounds are causing the crash - I reverted each in turn to the vanilla values, and then both together and the crash was still there in all three instances. So it is presumably a conflict with the Dynamic Giant Campfires script when the MSTT record has the LOD flag added. It's not a big deal for me as I'll just delete the record from DynDOLOD.esp, but it would be nice to figure out why it's causing this. The script is very well annotated in the source file, and the only thing I can see is there is a distance from player check which might be causing the issue? As I said previously the mod only adds scripts to 10 instances of the giant campfire in specific locations, so I can't get my head around why it would crash on fast travel anywhere (although to be fair I didn't try fast travelling to one of the giant camps where the dynamic fires are). Maybe if you fast travel to a location that is outwith the 10000 units distance from player check in the script, but the Has Distant LOD flag is forcing the campfire to load at much greater distances this is causing an issue? Strange thing is I ran the mod on the LE builds with no issues at all alongside DynDOLOD. Like I say, don't put any time into it (unless you're curious as to the cause), I'll just do without LOD on the campfires. https://www.nexusmods.com/skyrimspecialedition/mods/2857
-
To clarify, other than adding the Has Distant LOD flag DynDOLOD does NOT reference 51577 at all: So should is even be being flagged with Distant LOD?
-
So to clarify, this is what the record looks like in DynDOLOD.esp: So all that DynDOLOD is doing is adding the 'Has Distant LOD' Record Flag. Removing the record from DynDOLOD, so basically removing that flag, cures the crashes. I'll try first reverting the Object Bounds, and then the Unknown Data Flag and see which of those is causing the crash when Has Distant LOD is flagged.
-
The issue is with 0051577 GiantCampfire01Burning. It's not a mesh issue because I have nothing overwriting the vanilla mesh. The only thing affecting that record in xEdit is Dynamic Giant Campfires which is altering the Object Bounds and removing the Unknown data flag: Other than that the mod only adds scripts to 10 specific Placed Object instances of the giant campfires, none of which are in the vicinity of Castle Volkihar. There are non-scripted instances on top of the coastal watchtowers which I guess is why the crash there, but why would Object Bounds be causing this? Unless it's something in the mod script that is affecting all instances of the campfires? Any ideas?
-
OK, so I've got it narrowed down to a problem with one of the Moveable Static records in DynDOLOD.esp. With that entire section removed the crash doesn't happen. Just going through a binary disable on it (118 records) to see if I can pinpoint it.
-
Temporary=1 makes no difference. Next move? Start stripping out DynDOLOD.esp in binary fashion to try and get to what records are causing the crash?
-
It seems to be pretty much any fast travel to any significant distance from the location at which you first load into the game. I say that because I can load in on any save and make one fast travel jump to somewhere relatively close by (ie within long range visual distance) and it doesn't crash, but attempt to fast travel any further or make a second jump and it generally does crash. I don't know if it makes a difference, and I hope I've not missed an obvious instruction anywhere for this, but I am running with uGridsToLoad=7. I am about 60 hours into this playthough and was using non-dynamic DynDOLOD the whole time so I am guessing this isn't the issue, but thought it worth mentioning. I'm going to try Beta 7 with Temporary=1 now and see if that gets me anywhere.
-
Well so far I can confirm that there is no crash with the beta 5 esp disabled (just the esm active). I'll run a few random fast travel tests and see if it is limited to certain areas, but so far it has happened exiting Darkfall Cave into Falkreath hold, fast travelling from Riften to the coast near Castle Volkihar, taking the boat from the jetty to Castle Volkihar, and somewhere else within Tamriel that I can't remember. So I'll regen with beta 7 and temporary=0 for now and see what happens, I'll try a good few fast travels and see if I can confirm any of the above. And yes you remember correctly, hitting the persistent records limit on LE would cause a 100% crash before main menu appeared iirc.
-
I'm pretty sure that my current build is nowhere near as heavy as the ones we had issues with on LE. I've none of the huge towns and cities mods, just a lot of smaller ones. I have a lot of NPC/creatures mods and a lot of quest mods, but nothing like LotD, etc. I'll test a few things tonight as suggested. The CTD happens on pretty much any fast travel, even from one location in Tamriel to another, but I can travel regularly across the map to the same locations without any issue. I need to check tonight as well but I think I might also have had the crash last attempt yesterday using the old non-dynamic DynDOLOD output which leads me to wonder if it's an issue with something in either the new resources which I'm pretty sure we left enabled, or the new TexGen output. Either way, the crash only happens with DynDOLOD enabled so there's either something wrong, I've broken something, or I am hitting a limit again. I'll report back tonight.
-
Further to the above - rerunning with Temporary=1 results in more esps being flagged as masters by DynDOLOD.esm. The esm is now looking for ELFX - Exteriors and my creatures merge as masters. I can upload the merged plugin (without the 650mb of resources...) if you want to check what is in it.
-
Ah well, you make it I'll break it... again! So I reran the full process last night, this time with TreeLOD=0 but left fallback at 0 this time. Everything else the same, beta 5. Generation took under thirty minutes this time and output was 1.9gb. ESM master issues all fixed, no errors anywhere so all good. However... I removed the old non-dynamic DynDOLOD and enabled the new one whilst in an interior cell (Darkfall Passage) and loaded up, all ok. But when I try to exit the cave into Tamriel worldspace as soon as I hear the ambient noise but before it fades from black I get an instant CTD. The strange thing is, if I disable DynDOLOD then exit the cave and save in the Tamriel worldspace, then close down, enable DynDOLOD and load back up straight into Tamriel there's no crash. I can run around for as long as I like (there's noticeably more lag than with the non-dynamic version). But as soon as I go inside or exit to another workspace and try and return to Tamriel the instant crash is there again. Disable DynDOLOD, enter Tamriel, save/exit/enable/reload and all is OK. Any idea what's going on? Is there a temporary toggle in DynDOLOD SE in case I am hitting a persistent records limit again?
-
Further to my last post above, is there a way I can get away with just regenerating the esm/esp without the hour and three quarters of LODGen or do I need to rerun the full process?
-
Excellent thanks, will it still fix the master issue if the plugin(s) in question are part of a merged plugin?
-
OK, well that took a loooooooooooooong time! i have a healthy load order (nothing like my LE load orders of old which broke the persistent records limit...) with a lot of quest mods, a fair few towns and cities mods, and a few new world mods (Beyond Reach, Wyrmstooth, etc). I set TreeLOD = 0 and TreeFullFallBack=1 but didn't change anything else. I toggled Candles and FX Glow, Windows, High, Fake Lights in Child Worlds, and the general High setting with textures at 512. It took 55 minutes before Dyndolod.exe gave me the Save/Exit options and a further 50 minutes after that before LODGen.exe finally finished with Tamriel. The resultant output is 7.21Gb :/ DynDOLOD.esm has also picked up two esps as masters - Teldryn Serious and They Took Our Jobs (the latter is part of a small merge I have but this is the only plugin in the merge with any worldspace records). So what took so long and why is it so huge - is it the TreeFullFallBack? And what needs done to remove those two esps as masters for the esm?
-
Awesome, thank you so much (for giving me back the headaches of updating DynDOLOD mid game again...) 😋
-
Dynamic Distant Objects LOD - DynDOLOD 2.27
dunc001 replied to sheson's question in DynDOLOD & xLODGen Support
Thanks both for the replies. I actually got to the issue last night (well, this morning at about 4am if truth be told!) after three days of searching! By disabling plugins in binary fashion I narrowed it down to one large merge (42 plugins). It was further complicated by the fact that on first load on a new game with the plugin enabled there was no crash, it was only after saving and reloading that the crash occurred so I went through the whole process several times discarding this plugin initially as it didn't seem to be the cause! Going through every plugin in the merge and checking all the Tamriel/WindhelmWorld cells didn't reveal anything. The merge however did also contain Snow Shader Fix - https://www.nexusmods.com/skyrim/mods/51495/? - which whilst having no direct edits in Windhelm does, well, snow right! Checking the mod OP there is mention of disappearing walls on the palace but nothing else, however checking comments reveals the answer to the riddle: So nothing to do with LOD, navmesh, NPCs or anything else I spent hours trawling through. Just a bloody snow shader/parallax mesh incompatibility that I found almost by accident! Thank you as always for the willingness to assist, much appreciated! -
Dynamic Distant Objects LOD - DynDOLOD 2.27
dunc001 replied to sheson's question in DynDOLOD & xLODGen Support
Also, I don't know if this is significant or not but I just checked the crash fixes log and the game is crashing with an exception address of 0x0. Is that OOM and if so why only in Windhelm? -
Dynamic Distant Objects LOD - DynDOLOD 2.27
dunc001 replied to sheson's question in DynDOLOD & xLODGen Support
So to extrapolate from what you are saying, presumably as I can get right to the cell boundaries in the Tamriel worldspace, if both the Tamriel and WindhelmWorld persistent cells load together they're not going to hold the error as they will have been loaded a long time before I get to within half a cells distance from the walls? But if it is also the case that the WindhelmWorld temporary cells only load if you are inside the city, and the Tamriel temporary cells only load if you are outside the city why does the crash persist both inside and outside the city? It is 100% repeatable. There is no Crash Fixes mesh warning, and one of the first things I did was to run everything in meshes/architecture/windhelm through NifHealer which reported no errors. I have checked different times of day and different weathers to rule them out. And as far as I can tell it is every cell containing Windhelm as per the area within the red lines in the image above. So I need to check through all of those cells presumably (both in Tamriel and WindhelmWorld?)?
