Jump to content

[Skyrim Classic/LE] TES5Edit - Records that merge at runtime


Arthmoor

Recommended Posts

Due to a freak CK accident, a record that ignores the Rule of One has been located.

 

In a worldspace, there is a section for Object Bounds. The Object Bounds section has NAM0 (minimum) and NAM1 (maximum) values which represent how large a worldspace should be.

 

Tamriel should universally have NAM0 settings of -57X and -43Y with NAM9 settings of +62X and +51Y.

 

An accident in the CK caused one of my mods to get the NAM0 Y value changed to -6115 and the NAM9 X value to be changed to 6113. Thus telling the game that Tamriel was a great deal larger than it should be.

 

This ended up producing a massive amount of stutter as the game was attempting to load LOD assets for an area 10x the normal size. This lag happened DESPITE the fact that at least 10 other mods loaded AFTER the accidentally edited one and reverted these values back to vanilla.

 

Thus, NAM0 and NAM9 are confirmed to be exempt from the Rule of One and conflict management becomes a very complicated issue with these. Two mods intentionally changing these values are going to have an unpredictable outcome on the game.

Link to comment
Share on other sites

I bet zilav would be interested to find out more about the NAM0 (minimum) and the NAM1 (maximum) value for worldspace(s) in CK.

 

So no one has never experience this yet until you did recently.

Link to comment
Share on other sites

Actually those fields are stored in game units, so 2 for example is 8192, but xEdit divides them by 4096 to show in cells since they are always dividable by cell size without a remainder.

They are already marked for conflict resolution, so don't know what else can be done here. Maybe adding a message while loading plugins if those values are unusually large.

Link to comment
Share on other sites

  • 2 weeks later...

Default Object Manager

 

DOBJ - DNAM [Objects]: ElminsterAU has confirmed that this record merges its data at runtime, therefore conflict management on this record if it exists in a mod is unnecessary.

Link to comment
Share on other sites

  • 1 month later...

NAVM is not, but yes, NAVI (the navigation info map) is. NAVI also merges at runtime for Fallout 3 and New Vegas.

Link to comment
Share on other sites

NAVM is not, but yes, NAVI (the navigation info map) is. NAVI also merges at runtime for Fallout 3 and New Vegas.

 

Even if NAVM doesn't merge at runtime, I don't think you'd want to try to do conflict management on it because the bulk of the subrecords are raw tri data.  But that's good to know.

 

BTW, you should check out the work in progress thread for Mator Smash here on afkmods if you haven't already.

Link to comment
Share on other sites

Yeah, you can't really get away with manually merging NAVM data. I've tried before. It just makes a mess and the CK declares your navmesh corrupted.

Link to comment
Share on other sites

  • 1 month later...

Just curious if, on loading all mods to Xedit, there is some way via scripting to pickup on the abovementioned baddies and make a BOSS/LOOT styled report for "easy" viewing?

Link to comment
Share on other sites

  • 10 months later...

I know that race records don't merge at runtime but am curious as to why all three atronach race records under vnam equipment flags have crossbow any idea why? I wouldn't have even noticed but I have a mod which has only one conflict, removing the crossbow flag so undecided which edit to let win....

Link to comment
Share on other sites

I know that race records don't merge at runtime but am curious as to why all three atronach race records under vnam equipment flags have crossbow any idea why? I wouldn't have even noticed but I have a mod which has only one conflict, removing the crossbow flag so undecided which edit to let win....

Crossbow flag was added with Dawnguard update iirc, all mods after it's release have that flag by default, prior to it don't have.

Link to comment
Share on other sites

Yeah, you can't really get away with manually merging NAVM data. I've tried before. It just makes a mess and the CK declares your navmesh corrupted.

To update this, now that we know what all the bits in NAVM are, it is possible to merge things manually. But very difficult. And you have to do things 1 (or very few) triangle at a time, save, load in CK, select a vertex, and save again -- which will update the NAVM blocks at the end, and the NAVI.

 

In fact, after even ITM cleaning that removes a NAVM, you have to save, load in CK, select a vertex, and save again. TES5Edit dosn't clean the corresponding NAVI, so you have to induce CK to do it. This is a step usually left out of cleaning descriptions.

Link to comment
Share on other sites

  • 1 year later...
  • 1 year later...

This is a very useful thread. Found it while googling for DOBJ records on the assumption that they might not need CR (geez, my load would be a mess if it needed). This answered my doubts about this and more. I realized I'd been lilkely breaking my game trying to "resolve" navmesh and worldspace "conflicts". Even nagged Jenna about her navmeshes in ETaC (I did have a conflict in Riverwood which turned out to be fixed by adjusting the load order). My bad - and thank you @Arthmoor for making this clear. In a perfect world one should read this site through before attempting to play with mods.

Link to comment
Share on other sites

  • 4 years later...
On 3/13/2014 at 1:14 AM, Arthmoor said:

ISMQN - QNAM [Quest Count, Quests] subrecord: Data contained within the QNAM subrecord will merge at runtime as demonstrated by numerous mods which share these nodes to add quests to the lists which all function together properly.

This is not true. At least, not for Skyrim SE/AE.

If needed, I can provide evidence, but only if you are going to test it/check it, otherwise I would rather prefer not to lose my time.

Link to comment
Share on other sites

The things in this post have been validated as still working in SE (there is no AE for this purpose). You'd need to come up with something very specific and detailed AND easily reproduced before this gets removed from the post.

Link to comment
Share on other sites

So, well here is the test. The attached file SMQN_TEST contains 4 mods that I will describe and which are simple enough to be checked quickly in CK or SSEEdit.

After that, the 5 test cases to prove my point. Even if only the 4th is relevant, it would be wise to do the 5 of them in ascending order to do a proper verification.

None of the mods overwrite vanilla records. The tests were done in Skyrim SE 1.6.353, but I know the results are the same in older versions, because this is an issue I found on a real mod long long ago (in 2018 I think,) where that mod was destroying a certain Dawnguard minor content (and it still does...)

So, the description of the mods and what they do:

- Base Mod (Whiterun): This mod defines a change location node called "MyQuestNode". Besides that it adds to that quest node a quest called YYYMyWhiterunQuest. This quest prints on screen (using one of those lazy Debug.Notification)  "A change location happened in Whiterun Hold!" every time a change location event happens with the player being anywhere that belongs to the Whiterun Hold.

- Derived Mod 1 (Eastmarch): This mod uses the first one as master, and it adds to the MyQuestNode another quest called YYYMyEastmarchQuest. This quest does exactly the same than the above one but in Eastmarch and printing "A change location happened in EastmarchHold!"

- Derived Mod 2 (Haafingar): This mod uses the first one as master, and it adds to the MyQuestNode another quest called YYYMyHaafingarQuest. I bet you can guess what it does... yes, it prints "A change location happened in HaafingarHold!" when changing location in Haafingar.

- Patch Mod: This mod has all above as masters,  and resolves the conflict between Derived Mod 1 and Derived Mod 2. It doesn't add anything new of its own. If these quests really merged at runtime, then this patch mod wouldn't be needed because the game would already do that, right? Well, my point is that this mod is actually needed to resolve the conflict because that runtime merging doesn't happen.

 

All of the three quests of the mods have mutually exclusive conditions to start: Player.GetInCurrentLoc(WhiterunHoldLocation), Player.GetInCurrentLoc(EastmarchHoldLocation) and Player.GetInCurrentLoc(HaafingarHoldLocation).

All of them get stopped after printing the message, so that the quest can run again on the next change location event.

For testing the mods, the easiest way is just to enter/leave buildings in the city of the respective holds so that the change location event triggers.

 

And now testing time.

 

Test 1

For this test I'm going to ask you to only have "Base Mod (Whiterun).esm" enabled, and not any of the others mods of the test. And well, just test what the mod does. Verify that "A change location happened in Whiterun Hold!" is printed every time a change location happens inside Whiterun Hold. Also verify that it doesn't happen in any of the other holds.

 

Test 2

For this test I'm going to ask you to only have "Base Mod (Whiterun).esm" and "Derived Mod 1 (Eastmarch).esm" enabled, and not any of the others of the mods in the test. Obviously have Derived Mod 1 below in the load order, since it uses the first as master.

So, this is how it looks in SSEdit 4.0.4 now: https://imgur.com/a/SRs8uU4  Nothing odd there.

Verify that the combination of these mods do what you can probably guess: print "A change location happened in Whiterun Hold!" when a change location happens in Whiterun Hold and print "A change location happened in EastmarchHold!" when you change location in Eastmarch, and that it doesn't happen anywhere else.

 

Test 3

This test is pretty much like 2, but instead I will ask you to only have "Base Mod (Whiterun).esm" and "Derived Mod 2 (Haafingar).esm" enabled.

This is how it looks in SSEEdit: https://imgur.com/a/XIeWJPU Again, nothind odd yet.

So, again, verify that it does what it should do, which is the same that Test 2, but replacing Eastmarch with Haafingar.

 

Test 4

This is the most important test. Make sure to have "Base Mod (Whiterun).esm", "Derived Mod 1 (Eastmarch).esm" and "Derived Mod 2 (Haafingar).esm" enabled, and of course, do NOT enable "Patch Mod.esp", because that would enterely defeat the purpose of the test. Make sure to have Derived Mod 2 below Derived Mod 1 in the load order (otherwise it would happen exactly the opposite, although that would prove the point aswell)

This is how it looks in SSEEdit: https://imgur.com/a/HyzGK1E  And the problem starts. But hey, the colors in SSEEdit seem all nice, right? Almost as if it was expecting that those would really merge at runtime... It is worth to mention, that older version of SSEEdit (from the 3.x branch, 3.2.1 in concrete) would actually display these in red. But at some point, they changed that. I don't know which exact version did it. It is my guess that this change in SSEEdit may have happened precisely because of the information in this thread. Which is actually unfortunate, because now some modders are not aware when the issue happens, they see the colors all good, and they think everything is okay.

 

So, as you may have guessed, two different things may happen when running this test, depending on which info is correct, but only one of these will actually happen:

a) If it as the information in the op post says, then the quests will merge at runtime. And so, the three messages "blah blah Whiterun Hold", "blah blah Eastmarch Hold" and "blah blah Haafingar" will be printed in their respective holds.

b) If is as I say, and these runtime merge doesn't happen, the result of this test will be identical to Test 3. Or in other words, the messages of Whiterun and Haafingar will happen, but the message for the Eastmarch Hold will never happen.

 

On my end, b) happens always, not matter how many times I run the test or how many times i change location. Verify that it is the same on your end.

Test 5

This test isn't really needed, if by doing Test 4, the issue has been confirmed. But just for completion. This time enable "Patch Mod.esp" aswell.

This is how it looks in SSEEdit: https://imgur.com/a/3tcl01D

So, verify that the mod indeeds resolve the conflict and that the message is printed in the three holds. Like I said at the beginning, if the merge happened in runtime, this mod wouldn't be necessary... but it is.

 

 

 

 

 

 

 

SMQN TEST.zip

Link to comment
Share on other sites

On 5/16/2022 at 8:42 PM, Arthmoor said:

The things in this post have been validated as still working in SE (there is no AE for this purpose). You'd need to come up with something very specific and detailed AND easily reproduced before this gets removed from the post.

And in this post I will attach the same test case for Skyrim LE, classic, Oldrim or whatever people call it these days.

The test is identical to the one of my post above, but for Skyrim LE. Besides that, the only other difference is that this time Derived Mod 1 & 2 are .esp and not .esm (just in case that could have affected results, and also for having another test case).

The result is identical in classic Skyrim: the quests in SMQN don't merge at runtime. I don't think they ever did.

 

SMQN_TEST for Classic Skyrim.zip

Link to comment
Share on other sites

I've had a chance to test this now. The conclusions are mixed:

For LE, everything works as expected. There is no need for the patch .esp file. This was a fresh install of LE with no mods as I had long since uninstalled it and needed to get it back.

For SE, the patch .esp file is necessary and I'm able to duplicate your results exactly.

There is only one thing I did to both of these before using the scripts - I changed the call to Debug.Trace instead of Debug.Notification because I've had instances where those notifications are not reliable.

So it appears as though Bethesda did something in an SE update at some point which has removed the runtime merging of the QNAM group. I've checked my current game load order and this issue would only have affected a minor node between the Bruma mod and the Dawnguard DLC for follower commentary. So it also seems that somewhere along the way Bethesda also quietly resolved the conflicts the files used to have with each other, which was what prompted the original LE testing to begin with.

In any case, what this means is that I'll need to put up a second post for SE that leaves out the QNAM information since that's now wrong.

Link to comment
Share on other sites

  • Arthmoor changed the title to [Skyrim Classic/LE] TES5Edit - Records that merge at runtime

Thanks for testing. The mod you mention, Bruma, is actually the mod I was talking "that removed minor content of Dawnguard" (just a few of the comment of Serana that are goberned by those 3 quests, she still does a lot of other comments goberned by different quests, which is probably why no one else noticed that bug). Surprisingly, at least from my experience and the mods I use, there aren't many mods with conflict in SMQN, which may have been the reason why the whole thing hadn't been spotted before.

As for LE,I will give it another try. This time, to be on same scenario than you, I'll uninstall the game, make sure it is uninstalled, and install it again. 0 mods scenario, I won't even install SKSE. A 2011-11-11 experience. (well, not really, because there are the dlc and the updates, so I guess it is more like 2013 experience)

If Debug.Notification is unreliable, I will use something else. I personally prefer something I can notice in game, and not outside, so I think I will go about adding a different fixed amount of gold in each hold. Even if for whatever reason the message that the game itself displays that gold has been added were unreliable too, the amount of gold in the player pockets should still be updated.

I'll post the results later in the day. If they didn't match your results, I will post an updated test case (but this time only for LE)

 

Edit: on  a second thought, instead of giving player gold (which can be problematic to count if you test multiple holds), I will giving the player exactly 1 arrow in each hold. but a different type of arrow in each hold. That should make the test less prone to mistakes.

Link to comment
Share on other sites

I've run the test again. The issue of quest not merging in Skyrim LE persists on my end, upong having a blank Skyrim.

Since it is a bit redundant to post it here, too, see my latest post in https://github.com/TES5Edit/TES5Edit/issues/1016

There I uploaded Test Case 2 for LE. Besides the change to arrows I said in the previous post, I also added a small change to account for the possibility of human errors while testing (it is detailed in my post there).

 

Link to comment
Share on other sites

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...