dunc001
-
Posts
468 -
Joined
-
Last visited
-
Days Won
3
Recent Profile Visitors
750 profile views
dunc001's Achievements
-
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.
