Jump to content

Recommended Posts

Posted (edited)

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.

Edited by dunc001
Posted (edited)

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.

Yeah I knew that would happen, that code is not yet updated to not add masters to the esm. I was hoping we might not have to worry about the total number of persistent references, that the limit would not exist in Skyrim SE.

 

You think that it could be cause the of that CTD? I mean, do you have that many plugins comparable to what would trigger that type of problem? I'll try to update that code to not add masters to the ESM as well tomorrow maybe.

 

In the meantime, you could check maybe if a mesh is the cause by setting the debug:true in the json and check the papyrus log as explained in the readme.txt

 

And if that does not reveal anything see if not using the ESP does not CTD (it will complain about it mising). If it does work without the ESP, try removing references in batches from the ESP worldspaces to see if you can pin it down to some specific record. You know, my usual suggestion of removing 50% and either keep going or remove the other half while the problem is happening until you only end with the problematic records.

 

Or just wait for my update for the temporary=1 to work as intended.

Edited by sheson
Posted (edited)

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.

Edited by dunc001
Posted (edited)

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.

New beta 7 should now generate the ESM without ESP master when using temporary=1. However that type of problem typically prevented users from loading into the game at all if I remember right.

 

If non fast travel works fine for the same area, then it is unlikely there is a problem with any assets or data in plugins. Then it sounds more like an resource problem as it would always load the exact same assets, data. Though if large references are involved anything is possible, as we learned from iNeed/ACTI that under certain circumstances the models don't show when walking, but showed fine with fast travel. I believe the models are loaded anyways, since the collision worked, but at least there is a difference between walking and fast travel.

 

The next question would be if it happens 100% and if its limited to certain areas. If that is a case and you can verify if it only happens with a certain plugin there is a good chance you can narrow it down to a certain record / types of records.

Edited by sheson
Posted

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.

Posted

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.

Posted

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?

Posted

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.

Posted (edited)

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:

 

2uvHtOa.png

 

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?

Edited by dunc001
Posted (edited)

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:

 

2uvHtOa.png

 

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?

But DynDOLOD is not using this MSTT for anything, is it? See if any references using this are from DynDOLOD or changed by DynDOLOD.

The only way there should be a connection is when DynDOLOD scripting checks if the reference is enabled/disabled. Don't get me started on irregulraties of large references and scripting.

 

Seeing that no one else reported similar problems yet, set the unkown2 data flag back. There is no reason for a mod to remove it (It is probably missing because the plugin was converted from Skyrim and CK is dumb).

 

I know the flag has something to do with large references. It needs to be set or they sometimes don't show. At least that is what I noticed with copies that DynDOLOD uses for LOD.

 

You should probably also update the bounds again. The engine does check the bounds when it loads large references. They need to match the bounds that were used when large reference data was added to the world record (in SKyrim.esm or the DLC) or else the usual texture flicker thing starts to happen in case the object all of sudden is too small to be a large reference.

Which is a bit odd, as logic would dictate that bounds only matter when large reference data is generated and then only use the pre-made data instead of checking bounds in the game for no other reason than to burn CPU cycles. Did I mention that Skyrim SE is fubar?

Edited by sheson
Posted

So to clarify, this is what the record looks like in DynDOLOD.esp:

 

rdEKczA.png

 

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.

Posted (edited)

To clarify, other than adding the Has Distant LOD flag DynDOLOD does NOT reference 51577 at all:

 

IHuvv5q.png

 

So should is even be being flagged with Distant LOD?

Edited by dunc001
Posted (edited)

To clarify, other than adding the Has Distant LOD flag DynDOLOD does NOT reference 51577 at all:

 

IHuvv5q.png

 

So should is even be being flagged with Distant LOD?

Yes, because with DynDOLOD it now does have Distant LOD. If that flag and overwrite on MSTT alone would cause problems we would know, because it is done for everyone everywhere.

Edited by sheson
Posted (edited)

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

Edited by dunc001
Posted (edited)

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

I tried the mod a bit. The plugin has an ITM and does not forward all WLRD/CELL records correctly. Probably unrelated, but for my tests I fix that kind of stuff.

 

I have yet to have a CTD with the unkown2 flag set, I fast travel all over the place and direclty to giants camp no problem. I had a CTD with the flag missing in the last overwrite.

 

What is your ulargerefloddistance setting?

Did you try new game? With uGrids=5?

 

EDIT: Just did more tests, with ularge=11 and uGrid=5/7, unknown2 set, new game, no problems with extensive fast travel. Check if you can replicate that.

 

Though I think the best options for this mod is to not do any extra LOD for the fires the mods changes, as the LOD does not always match its state anyways.

 

Overall it may be a good idea to stay clear of having any scripts on large references and for DynDOLOD to ignore any large references that a mod overwrites and attaches a scripts to, just to be safe. Depends if more users notice problems with such plugins.

Edited by sheson

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

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