TES5Edit - Which record types DON'T need conflict patches

[Kuldebar]

EssArrBee, on 23 May 2014 - 11:42 PM, said:

Read the last paragraph of the quote you posted.

I wasn't ready to take the word of a single mod author describing his very first published mod that purportedly fixes an issue that I had never heard of, or knowingly encountered, before.

 

Seems like a single esp with all the appropriate MHDT forwards is in order...LOOT ordering can change each time you add a new mod and require new edits.

Edited May 24, 2014 by Kuldebar

[EssArrBee]

Manually move it to the end if you have too.

[Kuldebar]

Here's what Arthmoor posted concerning A simple WORLD patch by RdX995: 

 

 

Arthmoor :

 

Appreciate the effort here, but this really isn't doing much of anything.This MHDT data is speculated to have something to do with dragon height data. Telling them where they can and can't fly while airborn. Sort of serving as their navmesh. There is no solid proof of this though.Here's the thing. If this was true at all, this would have been discovered within hours of Dawnguard's initial release since it's the first DLC to introduce this field. There are no widespread reports of people being unable to access Castle Volkihar by way of the boat. There are no widespread reports of people getting thrown back to Solstheim trying to return to Windhelm. There are a scattered few incidents of both of these that can be traced back to misunderstanding what an ILS is.The scenario you are describing where you get the load screen but are thrown back is EXACTLY what I've found to happen through my own testing when the game borders are wrong. Or when you attempt to fast travel to a map marker that exists outside of them.With thousands of mods in the game not forwarding this data (because why would they - it requires DLC) there is no way that it being missing is going to matter. Every mod would break the game. Bethesda's own DLC would break the game, because Dragonborn's MHDT data will clearly not be taking Dawnguard into account, and vice-versa. So just the mere presence of Dragonborn in the game should cause Castle Volkihar to get blocked.And before someone says this can only be corrected for PC with mods, stop and think. The consoles are using all of the same data files we are. Beth's forums and tech support would be awash in complaints if this data had the effect that's being claimed here. They have no means to patch their games on consoles.

 

 

[keithinhanoi]

 

Here's what Arthmoor posted concerning A simple WORLD patch by RdX995:

 

Alright, that settles it. I need to remember: when not 100% sure, always use cautious language. I've edited my earlier post - thanks for pointing out this response from Arthmoor.

 

So, then is seems forwarding that MHDT data seems not to be necessary after all.

 

Still, it makes me wonder why that data is even there in the first place...

[Kuldebar]

Still, it makes me wonder why that data is even there in the first place...

To confound all of us and make Arthmoor look good!

[blattgeist]

This topic is very interesting. I've send a pm to Keithinhanoi but will post it here anyways for discussion:

 

 

I had a pretty long talk with Mike Hancho regarding Tes5Edit conflicts. He is the Author of Helgen Reborn and is also in contact with Arthmoor and getting advice from him, from what I understand.

 

Some very interesting stuff popped up while speaking with Mike. Source: Comment section of Helgen Reborn.

 

Quote

blattgeist

 

Image #1

Quote

blattgeist

 

1. Regarding ELFX (Enhanced Lights and FX): My impression is that it would be better to load ELFX before Helgen Reborn, since I suppose you already made the correct lighting changes. BOSS places it AFTER Helgen Reborn, but BOSS is out of date. What is your suggestion regarding that matter?

 

Quote

Mike

 

 

Image 1: I don't know why they would set a vanilla light source to an enable parent state with the player as the parent and set to opposite. Because the player is ALWAYS enabled, this light source would never be enabled set like this. All I do is make the radius slightly larger because I have a couple of scenes right there and I needed a little more light. In this case, it wouldn't matter where it was in the load order as I don't set an enable parent on this reference, so this mod's parentage would still be valid unless some other mod set parentage on the same reference.

 

Quote

blattgeist

 

[1] One [general] question popped up while reading your reply:

Quote: "Image 1: [...] In this case, it wouldn't matter where it was in the load order as I don't set an enable parent on this reference, so this mod's parentage would still be valid unless some other mod set parentage on the same reference."

Do I understand this right that the parentage gets automatically forwarded? So far I considered Arthmoor's "merge on runtime" list to be comprehensive: https://afkmods.iguan...rge-at-runtime/

I see no cell or worldspace merge on runtime records in his list.

 

Quote

Mike

 

Here's the way I've always understood it to work. Let's say you and I make a mod and both edit a tree. You make the tree 1/2 the size it is in its vanilla state, but I move the same tree 100' to the left. In this case, since we do not edit the same setting - we only edit the same tree - the mods are 100% compatible. The tree will still be 1/2 the size, AND it will be moved to my new location. It doesn't matter the load order because we don't edit the same values, so both will be valid.

But, let's say that when I move the tree, I set it at 3/4 of it's vanilla size. Now, my mod's edit to the size of the tree would override your's, so if my mod was below your's your 1/2 scale would be invalid because it's overridden by my scale. However, if you place your mod below mine, the tree will still be moved by my mod, but your's would now invalidate my scale edit, and the tree would then be at 1/2 scale again.

Now, in the case of parentage, as long as my mod didn't edit the parentage of that object, that setting in the other mod would still be valid because nothing after it edits that value.

 

Quote

blattgeist

 

I would really like to read up on the forwarding behaviour of the tree example. Does it apply to all the cell subrecords that can be seen in Tes5edit, like XLCM, XLCN, XEZN, XLRT, Ownership, XCNT, XLRL or only to XESP (parentages)? Is there some source where I can read up more about that matter?

Mike

I'm not sure "forwarding" is the most accurate way to think of how it works, but i understand where you're coming from. I think of it in layers. The main, vanilla Skyrim.esm is the base layer. When you create an empty plugin - one with no edits whatsoever - you're adding a new clear layer on the base layer. Each edit you make is like a new piece of information added to that layer that records the changes you made to the base layer, or new stuff not in the base layer you added. More mods equals more layers that alter the information contained in the base layer. Anything unedited by one of the layers remains in its vanilla state and gets "forwarded" to the engine as it is in its vanilla state. Anything in any of the layers that alters the information in the base layer is "forwarded" to the engine which sorts out what these alterations are.

So, in the case of the enable parent on the light in the keep, the vanilla state is without an enable parent. Both Helgen Reborn and the FX mod edit that light source, but because I don't edit the enable parent value, but only edit the radius, the other mods edits to the parentage don't get "blocked" by my mod, because I don't edit that value. You can learn much of this stuff just by doing all the tutorials, and asking question in the forums along the way like this.

 

 

So yeah.. I really thought that Arthmoor's list would be the definite answer to everything but it seems it is not 100% complete as far as automatic merging and forwarding goes. It would be good to know more about this whole topic, what else forwards automatically provided there are no overriding conflicts?

Edited June 6, 2014 by blattgeist

[DocClox]

It could be interesting to test that. You could make three simple mods. One adds a standing stone to the middle of the road outside honningsbrew meadery; one that doubles its size and moves it down the road 200 yards or so and one that shrinks it by 50%. You could coc whiterun from the start menu and see how the load order affected its placement.

[blattgeist]

I got a definite answer from Arthmoor regarding the discussion.

 

I hope I don't discredit anyone with posting this here, this is for science :)

 

 

 

Hmm. Ok. All due respect to Mike, but he's misunderstanding. Every game using this system from Morrowind on up to Skyrim works the same general way.If I edit a tree and set it to 0.5 scale, then Mike edits the same tree and moves it 100 units in the X direction, the game will ONLY get one edit. If my edit loads before his, then the game only gets his 100 unit move. If my edit loads after his, then the game only gets the 0.5 scale. It will never get both without conflict management.His layering explanation is good, but it's also wrong. It's more accurate to think of Skyrim.esm as your primer coat. It lies at the base of everything. Every mod that comes along, regardless of what it is, adds some paint to the primer. Some mods, like the USKP, will leave behind a lot of paint covering lots of areas. Others, like, say, my Point the Way mod, will only leave a few dots and maybe a stripe or two.When two mods edit the same record, the second mod's paint completely covers over the first mod's paint. You cannot see it now. Even if it looks like you should be seeing a checkerboard or alternating stripes, or dots, or whatever. That won't happen.The way this is visualized in TES5Edit is that Skyrim.esm loads on the far left of the window pane. Update.esm should typically be in the second column. Anything it touches is the whole record the game will see. Then, in a typical game's load order, if you loaded up the USKP next, it would be in the 3rd column.Take a quick example: ForswornBoots. Skyrim.esm established the baseline. Update.esm added ArmorMaterialForsworn keyword to the item. The USKP removes the VendorItemClothing from the item. Notice that in the middle, where Update.esm is, the keyword count is 5. The USKP shows 4. The game will see only the 4 entries that its copy of the record holds.If another mod were to come along and change only the "FULL - Name" portion with only Skyrim.esm loaded, that mod would have Skyrim.esm's base record, plus their change to the name. Update.esm and the USKP may as well not exist because their changes are totally lost.This is know as the "Rule of One" and it's pretty well explained here: https://forums.bethso...bility-and-you/ The post is old, and probably should be updated and sticked to the official Skyrim forum too, but the basic information it explains is true for Morrowind, Oblivion, Fallout 3, New Vegas, and Skyrim.This is where the concept of "forwarding changes" comes in and why compatibility patches are needed. The compatibility patch would occupy the next column after Skyrim.esm, Update.esm, the USKP, and the mystery mod that changed the name. In that patch file, one would drag the entry for FULL over into the file. Then drag the USKP's corrections over with it. That compatibiltiy patch then has all of the proper information that the user should get. It's a tedious process though, so not a lot of these kinds of things get made except by people who know TES5Edit well enough to navigate it.In your imagine with the two conflicting light records, ELFX wins that battle. The light source will be completely disabled in the order that's listed. Move ELFX in front of Helgen Reborn and Mike's radius change wins instead and you'll get what he wanted from the scene. Though that may slightly disrupt whatever ELFX is attempting to accomplish there.BTW, the ELFX record you see there, that's what a UDR looks like when it's been cleaned. The stuff where the enable parent on the player is set is a method Elminster cooked up to be able to more forcefully get the game to disable an object that's been undeleted to prevent CTDs.Anyway, bottom line is, the only records that are exempt from the Rule of One in Skyrim are documented on the post at AFK Mods that you already had linked.

 

By the.. way.. I am in the process of making a conflict resolution patch for all my mods and want certain masters to be present as dependancies even though they are not required in that file. So I added them to the patch but when I ever get to the point where I want to remove a master dependancy I would have to clean them all, which would also remove the not required master files from that patch. Is there any way to remove only specific master dependancies from a mod with tes5edit?

 

You're probably questioning the intention behind the unnecessary master dependancies. Here is how I see it. It's for convenience. When I experience a CTD on startup I know that I removed one of the mods that were patched with the patch and I would have to modify it. So the unnecessary master dependancies are basically there to remind me of modifying the patch when I change my load order.

Edited June 6, 2014 by blattgeist

[DoubleYou]

I think it might also help LOOT to list implicit masters.

[keithinhanoi]

By the.. way.. I am in the process of making a conflict resolution patch for all my mods and want certain masters to be present as dependancies even though they are not required in that file. So I added them to the patch but when I ever get to the point where I want to remove a master dependancy I would have to clean them all, which would also remove the not required master files from that patch. Is there any way to remove only specific master dependancies from a mod with tes5edit?

 

You're probably questioning the intention behind the unnecessary master dependancies. Here is how I see it. It's for convenience. When I experience a CTD on startup I know that I removed one of the mods that were patched with the patch and I would have to modify it. So the unnecessary master dependancies are basically there to remind me of modifying the patch when I change my load order.

 

There are two ways, one that is safe but may involve a few more clicks, and an another method that is potentially "unsafe":

 

1. Right-click on the name of the plugin in the left-hand pane of TES5Edit, and choose Clean Masters. This of course removes all masters from the plugin's header that are not referenced in any of the plugin's records. After doing that, you will need to manually add back all the desired implicit masters (ones that the patch provides compatibility for, even though there are no records referencing that master) - again by right-clicking on the plugin and choosing Add Masters...

 

2. If your implicit masters are listed at the end of the list in the plugin's header, you should theoretically be able to manually remove them one-by-one by right clicking on them while viewing the plugin's header record, and choosing Remove. The potential danger here is that there might actually still be records in the plugin referencing to that master, and by removing it from the header, they become invalid references. So, after manually removing masters, a check for should be done by right-clicking on the plugin name in the left-hand pane, and selecting Check for Errors. If no errors are found. then it's safe to save the plugin. Otherwise, you'll have to use option 1 above, and/or hunt down the records referencing the master that you want to remove.

 

I think it might also help LOOT to list implicit masters.

 

Absolutely it does help, and with all of the Audio Overhaul for Skyrim 2 patch plugins included with the new FOMOD installer, I've made sure to add masters even if TES5Edit didn't automatically add them. This needs to become standard practice for anyone creating compatibility patches, in the new "age of LOOT" load order sorting.

[blattgeist]

 

2. If your implicit masters are listed at the end of the list in the plugin's header, you should theoretically be able to manually remove them one-by-one by right clicking on them while viewing the plugin's header record, and choosing Remove.

That's what I was looking for. #1 is of course possible but I wanted to avoid adding them one by one again and again whenever I remove a plugin from the patch (although that did not happen so far). And of course I made a separate list for the patch, where I noted all the included changes (must have!).

 

Will try out method #2 now. --> Does not work. It only lets me edit the Master in the header, but not remove.

 

Well I guess that means adding all the masters one by one each time something gets removed.. or I simply drop the idea about having unnecessary masters in that file. That may be be the best option.

Edited June 7, 2014 by blattgeist

[keithinhanoi]

Oh dear - I'm sorry!

 

I forgot to mention the trick to getting the remove option in the contextual menu is to click in the blank spot above the name of the master you want to get rid of, as seen here:

 

 

I hope that helps!

[blattgeist]

Oh dear - I'm sorry!

 

I forgot to mention the trick to getting the remove option in the contextual menu is to click in the blank spot above the name of the master you want to get rid of, as seen here:

 

 

I hope that helps!

'Yeeeeep! Thanks. My textfile keeps growing... :o

[CJ2311]

Oh dear - I'm sorry!

 

I forgot to mention the trick to getting the remove option in the contextual menu is to click in the blank spot above the name of the master you want to get rid of, as seen here:

 

 

I hope that helps!

Does that actually work for you? Every time I try messing with that list, even by just removing the last mod (let alone a mod that's in the middle of the list), the file goes all nope and starts spewing out unresolved references next time I load it. :|

[Kelmych]

The only way I remove a master is to remove all references to it then select "Clean Masters". If all references to the master are gone TES5Edit will remove that master from the list of masters. Otherwise there is at least one remaining record that references that master, and just removing the master from the list of master files will cause the problem that CJ mentions.