[WIPz] TES5Edit

[Arthmoor]

Oh? Cool deal. Look forward to seeing what he has to update

[zilav]

Oh? Cool deal. Look forward to seeing what he has to update

Uploaded new version.

Great news - xEdit no longer leaks memory for the first time ever.    See changelog.

Case sensitive names in Oblivion too.

[Arthmoor]

I wasn't aware it leaked memory, but that's good that it won't now

 

The case sensitivity is working, thanks.

[JaxFirehart]

Hey Zilav, any chance that you or Elminster could take a second look at the PNAM sorting for FO3/FNV? Over at TaleOfTwoWastelands we are trying to merge our NV-style Speech Challenges into the main file and with PNAM sorting off, it's rearranging the records and causing numerous dialog bugs. With it on, attempting to copy as override fails frequently. The only other option we see is to manually reimplement the changes using the GECK PU and that is a LOT of man hours and duplicated work.

[zilav]

Hey Zilav, any chance that you or Elminster could take a second look at the PNAM sorting for FO3/FNV? Over at TaleOfTwoWastelands we are trying to merge our NV-style Speech Challenges into the main file and with PNAM sorting off, it's rearranging the records and causing numerous dialog bugs. With it on, attempting to copy as override fails frequently. The only other option we see is to manually reimplement the changes using the GECK PU and that is a LOT of man hours and duplicated work.

Uploaded new version.

He already fixed INFOs sorting, actually would be nice if you can extensively test it, since I'm going to remove an option to disable sorting.

Papyrus VMAD version fields are now marked as ignored since data is lined up, this allows to detect more ITM records, even found several in USKP (though I have a previous version iirc).

[JaxFirehart]

This will make my life SO much easier. I will report back how it goes.

[zilav]

This will make my life SO much easier. I will report back how it goes.

Make sure you downloaded the latest version since I replied before updating the first post link

[JaxFirehart]

I got r1617, copied all referencing dialogs for VNPCFollowers into a new file with sorting turned on: no errors. I looked at specific DIALs that I knew to be problems, no errors.

 

I'll keep messing with it tonight and get back to you later, but the first test shows great success.

[hlp]

Did you see my last reply to your question on the GeckPU download page ?

[JaxFirehart]

No sir I did now, but I did now! This is going to be a great weekend for modding. You guys are the best.

[alt3rn1ty]

Uploaded new version.

He already fixed INFOs sorting, actually would be nice if you can extensively test it, since I'm going to remove an option to disable sorting.

Papyrus VMAD version fields are now marked as ignored since data is lined up, this allows to detect more ITM records, even found several in USKP (though I have a previous version iirc).

 

I just let it loose on my previously cleaned :

 

Update.esm - Removing: MS11OpeningCrimeScene [sCEN:000206AE]

[Arthmoor]

Are we sure it's actually safe to ignore the VMAD version data?

[zilav]

Are we sure it's actually safe to ignore the VMAD version data?

I can't be sure until it is tested. However the only difference between VMAD v4 and v5 is the order of Alias ID and FormID in a property of Object type. Since TES5Edit can now line up them against each other and detect changes, the meaning of version fields itself (4 or 5, 1 or 2) becomes kind of irrelevant.

[Arthmoor]

Problem is I wouldn't have the slightest idea to go about testing to be sure this isn't going to make the game unhappy

[zilav]

Problem is I wouldn't have the slightest idea to go about testing to be sure this isn't going to make the game unhappy

The worst thing that could happen is that some records can be cleaned out when they shouldn't be. However I can't imagine such situation - if all fields in compared VMADs are equal including properties except a version fields, then those VMADs have the same meaning for the game and hold the same data regardless their version.

[Arthmoor]

Why do things like this show up as errors with the check for errors function?

[00:05] [iNFO:0001BC8F] ('Ulfric's right-hand man, Galmar Stone-Fist, has located what he believes is the final resting place of the Jagged Crown.' in GRUP Topic Children of MQ103KorvanjundIntroTopic "What's the mission?" [DIAL:0001BC86])
[00:06]     INFO \ Conditions \ Condition \ CTDA -  \ Parameter #1 -> 9
[00:06] [iNFO:0001C5C4] ('That's not for you to decide, soldier.' in GRUP Topic Children of MQ103TulliusBookA2 "We lost a lot of good men. I hope it was worth it." [DIAL:0001C5BF])
[00:06]     INFO \ Conditions \ Condition \ CTDA -  \ Parameter #1 -> 4

Both of those parameters point to alias ID numbers in quests. They're perfectly valid. I suspect the remaining large number of these reporting on the USKP are also of the same type. Shouldn't they only show up as wrong if the quest actually doesn't have the alias ID?

[Arthmoor]

BODT and BOD2 should have slot 43 marked as "Ears". Edit currently marks them as "Unnamed", which is wrong.

[zilav]

Why do things like this show up as errors with the check for errors function?

Call me a noob because I forgot to remove hardcoded alias ID to number conversion even for errors checking after making alias resolving always on

 

 

BODT and BOD2 should have slot 43 marked as "Ears". Edit currently marks them as "Unnamed", which is wrong.

Done.

Uploaded new version.

[hlp]

On the subject of ignoring VMAD version, as long as cleaning will remove the whole VMAD, and not just an object, then the whole record will be coherent from the CK/Engine perspective.

 

So the possible issue would be that past a certain version for the whole form, all VMAD should be of at least a certain version, which doesn't look likely base on the code used to load form.

[zilav]

On the subject of ignoring VMAD version, as long as cleaning will remove the whole VMAD, and not just an object, then the whole record will be coherent from the CK/Engine perspective.

Cleaning will remove the entire record, not only VMAD.

[hlp]

Ok, was I asleep at work ?

[zilav]

Uploaded new version.
New fixes and advanced ModGroups support.

Info from Elminster

ModGroups are now not just loaded from the TES5Edit.modgroups file (same folder as exe), but also from *.modgroups files that have the same name as the esm/esp files and are sitting beside them in the data folder.

e.g. you could pack a Unofficial Dawnguard Patch.modgroups file into the archive together with the .esp with the following contents:
[unofficial Dawnguard Patch]
Update.esm
Unofficial Skyrim Patch.esp
Dawnguard.esm
Unofficial Dawnguard Patch.esp

or a Unofficial Hearthfire Patch.modgroups with:
[unofficial Hearthfire Patch]
Update.esm
Unofficial Skyrim Patch.esp
HearthFires.esm
Unofficial Hearthfire Patch.esp

[unofficial Hearthfire Patch - Unofficial Dawnguard Patch]
Unofficial Dawnguard Patch.esp
Unofficial Hearthfire Patch.esp

and so on.

ModGroups from module co-files are only loaded if the module is being loaded.
ModGroups from the TES5Edit.modgroups file are always loaded.
For a ModGroup to be considered available, all the listed modules must be loaded in that order (but doesn't have to be in one block, doesn't matter if there are other modules in between).
After the dialog where you can choose what modules to load, if there is at least one available ModGroup, another dialog will be show to select which ModGroups to activate.
An active ModGroup basically represented the promise that: if these modules are loaded in that order, for each record, the winning version out of this list of modules is correct.
The effect inside TES5Edit is that in the detail view the versions of the record that don't matter are hidden.
So suppose you get a record that's defined in Skyrim.esm and then changed in Update.esm, Unofficial Skyrim Patch.esp, HearthFires.esm, and Unofficial Hearthfire Patch.esp. And because of the type of change made (USKP adds something, HeartFires removes it again, UHFP adds it back) this record shows up as conflict. With that ModGroup active, the detail treeview will only show the version from Skyrim.esm and Unofficial Hearthfire Patch.esp, resulting in it being classified as a clean override.

Currently, if you load:

Update.esm
Unofficial Skyrim Patch.esp
Dawnguard.esm
Unofficial Dawnguard Patch.esp
HearthFires.esm
Unofficial Hearthfire Patch.esp
Dragonborn.esm
Unofficial Dragonborn Patch.esp

And then do a filter for "conflict loser" you will see A LOT of red. The problem with that is that if you have a much more complex load order with 100+ mods, all these conflicts produce noise that makes it a lot harder to find any real conflicts.
With all the required ModGroups in place only very few remaining conflicts show up, and these are ones that you should fix in the UPs but haven't yet (the way the ModGroups are setup, conflicts between the Update.esm and between the DLCs for records for which the UPs don't get involved yet will still show up).
ModGroups have been implemented going all the way back to TES4View. (With the modgroups file beside the exe, being able to put them beside the plugins is new). They are described on the Information tab inside you can read inside xEdit. But I have the impression NOBODY seems to know anything about them. When they are actually the most important feature in xEdit to make conflict detection in large setups viable.
ModGroups allow you to perform conflict detection on a small subset (generally 2 modules, sometimes more if they have complex dependencies) of your total load order.
You can then either determine that if the two modules are loaded in a specific order, there are no actual conflicts and create an appropriate ModGroup, e.g:

[CoT-WP-NL3]
CoT-WeatherPatch.esp
CoT-WeatherPatch_NL3.esp

[GDO+WAF]
Guard Dialogue Overhaul.esp
Weapons & Armor Fixes_Remade.esp

Or you find that a compatibility patch is required, can generate one just for the two mods involved, and then again define an appropriate ModGroup. e.g:

[CoT+AOS]
ClimatesOfTamriel.esm
AOS.esp
AOS2_CoT3_1_patch.esp

[WAF+AOS]
Weapons & Armor Fixes_Remade.esp
AOS.esp
AOS2_WAF Patch.esp

That way, you can slowly work through a large and complex active module list, resolving conflicts for easily isolated groups of modules.
And with each additional ModGroup you define (after creating patches if required) the number of listed conflict losers for the load order as a whole gets less and less until you've got them all resolved.
The end point should be that you no longer have any reported conflicts for your whole load order.
But if you then add a new module at any position into your load order, you'll see any conflicts between that new module and the rest of your modules so that you can then again pick out subsets of modules that conflict, create an appropriate patch, define a new modgroup, and keep repeating till you once more are free of conflicts.

Two more changes to ModGroup handling:
First, modules in a ModGroup can be prefixed with a minus ( - ). This means that the module in question must be loaded, but it does NOT become part of the mod group. As an example:

[Weapons & Armor Fixes - Immersive Weapons]
-Weapons & Armor Fixes_Remade.esp
Immersive Weapons.esp
WeaponsArmorFixes_ImmersiveWeapons_Patch.esp

On one hand, as WeaponsArmorFixes_ImmersiveWeapons_Patch.esp doesn’t have Weapons & Armor Fixes_Remade.esp as a master, it’s technically possible to load the patch without loading WAF itself. But in that case, the promise of the ModGroup (if these modules are loaded together in that order, the winner is “correctâ€) doesn’t hold anymore.
On the other hand, -Weapons & Armor Fixes_Remade.esp shouldn’t become part of the ModGroup, because it contains a lot of levelled lists that conflict with Immersive Weapons.esp and which are NOT contained pre-merged in WeaponsArmorFixes_ImmersiveWeapons_Patch.esp
As an aside: Another valid prefix is plus ( + ) which means that the module is optional, if it’s present, it becomes part of the ModGroup, if it isn’t, it doesn’t prevent the ModGroup from becoming available.

Second, ModGroups will now never hide the original master.
Same ModGroup as above as an example.
WeaponsArmorFixes_ImmersiveWeapons_Patch.esp contains overrides for records that are newly introduced in Immersive Weapons.esp. Without this change, with that ModGroup active, the original record from Immersive Weapons.esp would be hidden, making the records show up as “single record†instead of master and override.
If another module (e.g. another compatibility patch for IW) would contain a version of the record that is identical to the version in Immersive Weapons.esp, it would wrongly show up as a simple (conflict free) override of the version from WeaponsArmorFixes_ImmersiveWeapons_Patch.esp, instead of being an ITM record that’s a conflict winner.

[ElminsterAU]

Lets make this easier to understand with a with a working example...

 

Get the new version of TES5Edit that zilav just uploaded today.

 

First, start TES5Edit loading ONLY the DLCs and the 4 UPs.

 

That is:

Skyrim.esm
Update.esm
Unofficial Skyrim Patch.esp
Dawnguard.esm
Unofficial Dawnguard Patch.esp
HearthFires.esm
Unofficial Hearthfire Patch.esp
Dragonborn.esm
Unofficial Dragonborn Patch.esp

 

After the background loader is finished, right click on the navigation treeview and select "Apply Filter to show Conflict Losers" (it's just a shortcut for a certain set of settings in the Apply Filter dialog, you could apply that filter manually, but this is faster).

 

Once the filter is done, you will probably see a sea of red. If you check out the details of these records closely, you will see that the large majority of them are actually ok. Despite them being flagged as conflicts, the record version that actually wins in the end is correct.

 

If there are any true conflicts in there, it's almost impossible to find them because of all that noise.

 

Given that these mods represent the basis for most modded setups, that means any attempt to find conflicts in a complex load order is made so much more difficult with this background noise when you are loading the same set of active plugins that the game engine would load.

 

Now close TES5Edit and download https://www.dropbox....ch_ModGroups.7z

 

Unpack it into your data folder

 

Start TES5Edit loading ONLY the DLCs and the 4 UPs.

 

After the plugin selection dialog, you should get a dialog asking which mod groups to load, right click and "Select All"

 

After the background loader is finished, right click on the navigation treeview and select "Apply Filter to show Conflict Losers"

 

Once the filter is done, it will now show only the remaining conflicts between the DLCs in records that the UPs didn't touch.

 

Optimally, these should get resolved in the UPs so that after applying the filter with these mods loaded and mod groups active, nothing at all shows. If for some reason these remaining conflicts can't or shouldn't be resolved by the UPs, then it's possible to define some additional mod groups to hide even these remaining conflicts away.

 

e.g. to hide the NAVM conflicts between Dawnguard and Heartfire, you could define a modgroup like this:

 

[HearthFires - Dawnguard]

Dawnguard.esm
-Unofficial Dawnguard Patch.esp
HearthFires.esm
-Unofficial Hearthfire Patch.esp

 

The minus prefix indicates that the mod in question must be active and must be in that order, but it doesn't become part of the ModGroup, it's presence at that position is just a prerequisite for the modgroup to be available.

 

What this is saying is: If you have the 2 Unofficial Patches active (and the 4 mods are in that order) then for any record that's defined in both Dawnguard and HeartFire, the HeartFire version is ok.

 

(Personally, I'm not convinced that's currently true, so please only see this as an example until someone who knows more about it than me has checked out these conflicting NAVM changes).

[Sharlikran]

The r1621 and r1630 Zip file contents are binary equals except the TES5Edit Readme.txt which has one line added, "- advanced ModGroups feature". Can you upload a new zip file when you have time?

[zilav]

The r1621 and r1630 Zip file contents are binary equals except the TES5Edit Readme.txt which has one line added, "- advanced ModGroups feature". Can you upload a new zip file when you have time?

Uploaded r1633