TES5Edit (by ElminsterAU)

[zilav]

Everything is intentional. xEdit does some clean up according to it's definitions and hardcoded fixing procedures similar to CK when you save a plugin, just in a different way.

[Kesta]

Trying to give some more details than zilav from an advanced user perspective (he's the dev guy, too direct :P )

 

• Are #1 and #2 intentional?
  • If so, is there a reason not to sort records in, say, RACE or MGEF (probably a few others too) which seems to have its records ordered any which way?
  • If not, is this a problem?
  • It looks like the things that got sorted are just the things that had records deleted from them, so I'm guessing xEdit is just rewriting the edited groups based on its internal data model.
• Is #3 desirable?
  • If so, wouldn't this be better for something like USLEEP to take care of, rather than the Update.esm cleaning process?
  • If not, is it actually a bug in xEdit?
• What's the deal with #4?
  • I'm just completely confused about why we would want to do this.  Is this something that people don't usually see because it gets UDR'd later or something?
• The release notes for 3.0.32 make it sound like #5 was intentional.  Can you please help me understand what OFST is and why it's OK to aggressively delete it by default?
  • I've been using the UESP wiki as my primary source for everything, and the WRLD page leaves OFST as a big fat "unknown", so if nothing else, I'd like to at least update it to mention that xEdit seems to be able to just delete it with no apparent negative repercussions.
• Is #6 desirable?
  • 3.1.0's patch notes say "Improved DOBJ handling", but in theory based on my knowledge of what's going on here, this action shouldn't require any changes to DOBJ.
  • Though the original version does look like it has an "interesting" amount of padding.

Sorry for the barrage here.  From my perspective, I expected xEdit to make as few changes as possible when asked to just remove ITMs, so I was really surprised to see all these "extra" changes.

 - Normally, the top groups that xEdit re-order are those it edited. If it didn't have to do any modification in MGEF or RACE because there was no ITM in those top group, then this is why it didn't re-order them. The importance of the order of records doesn't seem to matter as far as the game is concerned, though the CK do complain of odd things from time to time which might be due to an order issue. Basically, your assumption is correct.

 

 - Not sure about #3, but there is several fields/sub-fields unused by the game (records have tons of leftovers from Fallout and Oblivion), this is probably one of those that doesn't need to have any specific value, and thus is set to a default whenever xEdit make changes to the record.

 

- If #4 is what I think it is, xEdit delete all of the data from references that have their "deleted" flag turned on, because this REFR record can never be used by the game, it's just extra useless weight. I'm not super happy with that behavior either  though.

 

- For #5, this is essentially for xEdit's performance reason. This field is unused and is ultra huge, making the program use lot more memory than needed. You can prevent xEdit to delete those informations in the options (right click in the left pane -> other -> options, untick "Remove OFST data"). Edit: Don't do this, see zilav's reply below.

 

- Finally, #6 is perfectly fine, because DOBJ is merged at runtime, so only the relevant changes need to be in a plugin, despite the fact that the whole original record usually get copied. Then again, extra-useless weight, both for file size and for the amount of memory xEdit need.

 

 

Note that my answer are just insight from someone who've been messing with all this for... long. Not from a dev point of view.

Edited October 1, 2016 by Kesta

[zilav]

Always remove OFST because it contains absolute file offsets to cells and and as soon as plugin is saved they are invalidated. This is a "debugging" option.

[airbreather]

Thanks for the quick replies, all, that really did help.  Since my last post, I've started going through Dawnguard, but I got swamped with "real" work before getting to a point where I can speak intelligently about discrepancies between my intuition and what xEdit is doing.  It was quite a challenge to line everything up; [REFR:00023C63] alone made me basically rethink my whole life.

 

Got some more questions I've come up with during the process of Dawnguard.esm cleaning before I say I've got :

1. xEdit seems to change the rotation slightly on the DATA fields of the records when it touches them.  For example, [REFR:0007ABFC] has a rotation (in radians) of x=0.146080732 in Skyrim.esm, but x=0.146080568 after going through the UDR step.  Is xEdit storing values in degrees internally and then converting to radians if it needs to make an edit on the record or something?
   1. I realize that the magnitude of these changes is certainly so small that it makes no difference in the real world, so I guess this is probably just me whining.
2. What went into determining that [LVLN:0201513E] must have what appears to have a "dummy" LVLO field and thus a LLCT=1?
   1. My intuition is that there's an internal rule that every LVLN record must have a LLCT field and at least one LVLO field, so since the official Dawnguard.esm doesn't have these, xEdit just adds this so it's syntactically correct even though semantically it's garbage.  What would happen if we marked this record as Deleted instead, or just removed it entirely?
   2. Obviously it's not hard to make my tool match what xEdit does.  Anecdotally, however, I've had some crashes occur in the past involving Frost Atronach-looking NPCs, so seeing DLC1_BF_LCharFrostAtronachBoss on this record set off some alarms in my head.  This was reinforced when I ran xEdit's "Check for Errors" on this guy and got "LVLN \ Leveled List Entries \ Leveled List Entry \ LVLO - Base Data \ Reference -> Found a NULL reference, expected: LVLN,NPC_".  So I figured I might as well bring it up.
3. Why does xEdit truncate the fields of nearly every deleted record that doesn't get the UDR treatment, such as [sMQN:000F2199] and [NPC_:0007932F], but not the fields of [sTAT:000BD6A5], which is also marked as deleted?
   1. Follow-up question, I guess... would it be wrong to truncate these fields as well?
4. Why set the first byte in XLOC on [REFR:0200D055], [REFR:02009979] from a 0 to 1?
   1. Skyrim.esm seems to have a mix of both 0 and 1 values (15 records have a 1, 277 records have a 0).  I didn't explore these TOO deeply to figure out what kinds of references these are.
   2. My intuition is that xEdit is doing the right thing and that 0 might effectively mean "no lock".  I'd like to at least update the UESP wiki with this info.

[zilav]

1. Might happen due to internal float conversion. Beth uses 4-bytes floats which are not precise. In FO4 they even switched to 16-bits floats in Nifs which is even worse but saves them some memory on consoles.

2. LLCT and other similar count fields correspond to the number of entries no matter their actual content. if not matched then the game CTDs.

3 Deleted records should not have any content since they are, well, deleted.

4. XLOC 1 and 0 have the same meaning of "Novice", xEdit fixes that automatically for better conflicts detection.

[airbreather]

2. LLCT and other similar count fields correspond to the number of entries no matter their actual content. if not matched then the game CTDs.

The official "dirty" Dawnguard.esm's version of this record contained neither a LLCT field nor any LVLO fields.  I wouldn't have been surprised if xEdit added LLCT=0.

 

The part that was surprising to me was that xEdit added a LVLO field with all zeroes, and then set LLCT=1.  This is the part of the change feels really sketchy to me.

 

When I get some more time, I'll see if I can do some in-game testing with the "before" and "after" versions and see if I can reliably reproduce a version of the crash that I had mentioned before.

[zilav]

Ok I see whay you mean here.

"Leveled List Entries" element is marked as required in xEdit definition of Skyrim records so it is always added if missing, then automatic counter field updater procedure kicks in and creates LLCT=1

I probably need to remove required flag from it to avoid such cases, though they are extremely rare and doen't affect the game itself.

Edited October 17, 2016 by zilav

[Rebel47]

I'm currently going through my whole Skyrim mod list in TES5Edit checking every mod that loads after USLEEP for errors.

 

What I would like to know is, what errors should I be looking out for and what the best course of action would be to deal with them if any action should be taken, for example if LOOT doesn't list a plugin as dirty but it has UDR's is it wise to remove them

 

The one's I'm curious about are

 

• UDR that LOOT hasn't detected (and doesn't tell you not to clean it) example
  • Record marked as deleted but contains: Base
• ITM that hasn't been detected by LOOT
• Error: Could not be resolved errors
• Found a Null reference but expected a different value
• Navmesh warnings such as
  • Warning Navmesh Triangle not found in....
• Quest alias errors such as
  • Warning: Quest Alias not found in...
• <Unknown 11> (NAVM record)

 

Any advice would be greatly appreciated, while there is a lot of information out there regarding this kind of stuff, there doesn't seem to be too much in the way of information regarding what values are safe to clean and what should be left alone.

[zilav]

LOOT doesn't detect anything, it only shows you reports from other people. If you are checking plugins manually, ignore all those reports.

"Record marked as deleted but contains: Base" ignore

"Error: Could not be resolved" that's bad

"Found a Null reference but expected a different value" usually can ignore but depends on context

"Warning Navmesh Triangle not found in...." will break pathing for NPCs and followers

"Warning: Quest Alias not found in..." breaks quests

Unknown values can be ignored.

Edited November 18, 2016 by zilav

[Rebel47]

It seems that very little LOOT records have been submitted for Fallout 4 as yet, but most of these errors I found were initially found in Skyrim Plugins, the Navmesh warning was from Legacy Of The Dragonborn, but I've not seen any mention of it or problems associated with it on the mod's page,

As for mods with the Quest Alias errors, they are Wet & Cold, aMidianborn Content Addon and Helgen Reborn, now I'm fairly certain that aMidianborn Content addon does not add quests, so that could be an erroneous entry ?, as for the other 2 I'm not sure on if Wet & Cold adss quests or not, Helgen does though and I don't know if it's fixable by me, or should be reported to the author, assuming they're still active.

 

 

The mods with "Error: Could not be resolved" are listed in bullet point, checked with the FO4 version of XEdit, will be checking again with the SSE version to see if there are any changes.

• Eternal Darkness Redone (JBMod - ELFX3 Patch/esp)
• Morskom Estate (Morskom.esp)
• Hunting In Skyrim (Hunting in Skyrim.esp)
• Skyrim.Wayshrines.Immersive.Fast.Travel (WayshrinesFT.esp)
• Leaf Rest (LeafRest OnePiece.esp)
• Dwemertech - Magic of the dwarves (Dwemertech - Magic of the Dwarves.esp)
• Legacy of the Dragonborn - Patch Central patcher (BM_CACO_Patch.esp)
• Summerset Isles (summersetisles.esp)

 

Unknown errors were a concern for me as it's something I've not come across before, but glad to know they can be ignored, the "Null reference but expected a different value" was Dwemertech.

 

Watching videos from Matortheeternal and a host of other people's tutorials on YT about XEdit, the suggestions they have are that "Marked as deleted but contains; Base (UDR), and the mods with the "Error: Could not be resolved" should be deleted, I'm cautious in removing them just in case it breaks the plugin although I do keep backups of everything I change.

 

Thanks for the help thus far, hopefully I can learn more and eventually come to know how to deal with this stuff myself.

[zilav]

Custom made mods can contain unused content, the same as the vanilla game itself. Author decided to scrap an idea but did not clean up, or decided to add a new feature but had no time to finish it. That's why you need to know the context of errors to make a decision. Just deleting something because it has an error is not the best approach either because it can lead to even more errors if not cautious.

[Rebel47]

That's why I am cautious and haven't deleted anything unless specified to do so by mod author or LOOT. I will however contact the authors of said mods and confirm whether the errors I've found are safe to leave in or not, Thanks for the help Zilav

[TechAngel85]

Soo...is TES5Edit, FO4Edit, and SSEEdit all the same program?

[alt3rn1ty]

Soo...is TES5Edit, FO4Edit, and SSEEdit all the same program?

Yep, SSEEdit, TES5Edit, TES4Edit, FO3Edit, FO4Edit, FNVEdit, TES4LODGen, FO3LODGen, FNVLODGen, TES5LODGen, TES4Files, MasterUpdate, MasterRestore...

 

.. and now also SSELodGen. I used it recently to generate Simply Bigger Trees SE lods ( after installing its billboards )

https://forums.nexusmods.com/index.php?/topic/5114015-simply-bigger-trees-se-formerly-skysight-sbt/page-42&do=findComment&comment=45806045

 

The xEdits need the edit scripts folder, and the relevant game data file, aswell as being named correctly

 

 

Edit : Struck through TES4Files, I thought incorrectly that was also one of them

Edited December 28, 2016 by alt3rn1ty

[zilav]

TES4Files is a different program though, and not ours ::