[WIPz] TES5Edit

[hlp]

The definition was wrong so the error was displayed. The plugin itself wasn't changed.

[VaultDuke]

oh, so the error is, that it reports an error. there is not actually one in the plugin. all right, thanks. that sure puts my mind at ease.

[zilav]

Uploaded new version.
Fix for COCT inventory counter reported above.
Improved LODGen, it now should generate more optimized objects LOD compared to what Bethesda provided even when using vanilla meshes only on a vanilla game.
Added "Has Distant LOD" to records that support it in game but not shown in CK (TREE, ACTI, MSTT, CONT, FURN, DOOR).

[snarfies]

Using xEdit 190515 to clean Skooming Skyrim 1.1 (http://www.nexusmods.com/skyrim/mods/65259/?) yields the following when I attempt to clean UDR records:

 

exception message : [REFR:0009EC86] (places NULL - Null Reference [00000000] in GRUP World Children of Tamriel "Skyrim" [WRLD:0000003C]) is not contained in a group of type "Cell Persistent Childen", "Cell Temporary Children" or "Cell Visible Distant Children".

 

Full bugreport:  http://pastebin.com/dzs46CgF

[Sharlikran]

Using xEdit 190515 to clean Skooming Skyrim 1.1 (http://www.nexusmods.com/skyrim/mods/65259/?) yields the following when I attempt to clean UDR records:

 

exception message : [REFR:0009EC86] (places NULL - Null Reference [00000000] in GRUP World Children of Tamriel "Skyrim" [WRLD:0000003C]) is not contained in a group of type "Cell Persistent Childen", "Cell Temporary Children" or "Cell Visible Distant Children".

 

Full bugreport:  http://pastebin.com/dzs46CgF

Snarfies, when reporting a bug you can't use a preexisting esp from the Nexus. The reason is that Mator's merge script could have been used, the author could have used the CK incorrectly, the author could have stripped out masters with the CK which can break the plugin, any number of things could cave ruined that CELL. So like I have mentioned on the Nexus since this is the eleventh update the program is pretty stable. Granted it may not be 100% bug free but I highly doubt that the error is caused by a bug in TES5Edit and rather by an issue with the CELL itself for the reasons stated.

[Sharlikran]

Snarfies, my initial review of the plugin shows the TES4 Header to look like this.

[00] Skyrim.esm
[01] Update.esm
[02] Dawnguard.esm
[03] Dragonborn.esm
[04] Hearthfires.esm
[05] Skooming Skyrim by BigBizkit.esp

Then there are FormIDs that are not assigned to what they should be.
 

[00:13] Background Loader: <Note: xGSxBooksACTsafe "Books & Papers" [ACTI:0408763F] was injected into Dragonborn.esm>

Should be [05]08763F more then likely.
 

[00:13] Background Loader: <Note: xGSxLockerRoomDoNotEnter "Warehouse Bookshelves" [CELL:0407F4E3] was injected into Dragonborn.esm>

This is a new CELL that should be in the new plugin with a possible FormID of [05]07F4E3.

So the plugin is sketchy at best. I wouldn't consider it stable. I still can't be 100% sure but it was almost defiantly made with one of Mator's Scripts and the author didn't even bother to load it into the CK and try to update and finalize it. When using Mator's scripts authors need to load the plugin into the CK and save it. Then they need to see what changed.  If something is broken then they need to understand that's because they tried to use a shortcut by using Mator's script. They should not be surprised if they have to redo certain portions of the plugin and possibly rebuild certain things from scratch.
 

PATHFINDING: Navmesh 05117955 Cell '0SKHiddenSewerAKASkoomaLab' (050CB472), Triangle 2 and 46 have opposite normals but are linked
PATHFINDING: Navmesh 05117955 Cell '0SKHiddenSewerAKASkoomaLab' (050CB472), Triangle 2 Edge 0 and Triangle 46 Edge 1 should be linked, but they are not.

EDIT 1: In addition to that there are the typical CK errors caused by the CK in regards to the NavMesh.

EDIT 2: Do not use that plugin! It has duplicate FormIDs in both the persistent and temporary cells. Screen shot 1 and Screen shot 2. This is also after saving the plugin with the CK.

[Kesta]

Hello,

 

Following a suggestion from TechAngel on the STEP forum, I started an updated (and STEP-friendly) guide for xEdit on the STEP wiki.

Note that I originally intented to write stuff in there and then asking people like sharlikran or zilav to review (at least quickly) to make sure there wasn't any error in the content before diffusing it. However the guide have been made public by the STEP Staff so everyone can contribute. Not a bad idea, but that's two faces of a coin...

 

 

I'm not here to advertise nor to ask for review, there isn't any technical content that need actual review yet. However, I came across a little semantic problem and wanted some clarification on this point. Here is how I used to call things : 

A record is a "templated object" saved in the plugin. Records are displayed in the left-pane of xEdit once their GRUP have been expanded. example : WEAP

A record-detail is one of the information that constitute the actual record. example : WEAP\KWDA, this is a line in the View tab of xEdit

A subrecord is an information defining a record detail. example : each Keyword in the list for the WEAP\KWDA record-detail, i.e. WEAP\KWDA\Keyword, this is an indented line in the View tab of xEdit.

 

Problem : What's the word to define the actual data saved in the plugin, like WEAP\KWDA\Keyword\VendorItemWeapon[KYWD:FormID] ?

I used to call it a record-detail or subrecord-detail as well. However there is a slight difference between what I previously defined as a record-detail and this. The first one doesn't depend on the plugin, there is always a record-detail called KWDA for a WEAP record. However the content defining this record-detail change from a plugin to another.

 

I searched and tried to remember if I had ever seen such definition before, but nothing came to mind :/

 

Or could I wrong on my own deifnition of  a record-detail and a subrecord ? Still, their is only 3 name for 4 different elements.

 

 

 

Completely other (and almost pointless) subject :

 

While talking about semantic, when writing the guide, I noticed that the "Hidden" functionality is actually weirdly named. Not from an xEdit point of view of course, this is behaving as a checkbox, and when the checkbox is checked, the content is actually "Hidden" so it look perfect. But when describing it in documentation, you end up talking about the hidden funtionality, kinda sound like their is a functionality which is hidden somewhere in the program 

#xEditPunOverload

[zilav]

A record is a "templated object" saved in the plugin. Records are displayed in the left-pane of xEdit once their GRUP have been expanded. example : WEAP

A record-detail is one of the information that constitute the actual record. example : WEAP\KWDA, this is a line in the View tab of xEdit

A subrecord is an information defining a record detail. example : each Keyword in the list for the WEAP\KWDA record-detail, i.e. WEAP\KWDA\Keyword, this is an indented line in the View tab of xEdit.

Problem : What's the word to define the actual data saved in the plugin, like WEAP\KWDA\Keyword\VendorItemWeapon[KYWD:FormID] ?

I used to call it a record-detail or subrecord-detail as well. However there is a slight difference between what I previously defined as a record-detail and this. The first one doesn't depend on the plugin, there is always a record-detail called KWDA for a WEAP record. However the content defining this record-detail change from a plugin to another.

That is really weird naming. Plugin files consist of only 3 different elements: groups, records and subrecords (Bethesda call them chunks internally). They all have "signatures", 4 capital char words to identify particular type of data.

Groups, or GRUP signatured records contain other records inside (ARMO, WEAP, etc.), this is what you see in the left pain of TES5Edit though it hides "GRUP" signatures and displays more human readable labels like "Armors", "Block 0,0" or "Temporary".

In the right pane you see subrecords of selected record, they are organized in logical structures (again to be human readable). Nodes that have signature in name are what is really stored in a plugin, everything else is a fake structure provided by TES5Edit for the ease of viewing and editing.

[Kesta]

 Nodes that have signature in name are what is really stored in a plugin, everything else is a fake structure provided by TES5Edit for the ease of viewing and editing.

Super-valuable information (for me), thx a lot. Also thanks for the explaination. 

 

About everything else you said : So I had it wrong (semanticaly speaking) about sub-records, since they're (from an xEdit point of View) actually rows with a signature in their name. (What I called records-detail in the previous post). And what I used to call sub-records are just various elements of an array (array-like structure ? or maybe table-like ?) defining a sub-record, displayed in xEdit as single row for readability. 

I started using the "record-detail" terminology recently, when re-reading miax's FO3Edit Guide. Since it had been reviewed by Elminster, I assumed terminology in there was the best one to use for a public guide. I'll just forgot about it.

 

Big thanks for the quick and straight to the point answer. 

 

This plus a little private session I just had with mator gave me way better understanding of what's displayed and what's behind.

[Arthmoor]

Where is the structure definition for the TES4 record located? The one on UESP is missing details on the topmost portion of the record.

 

There's some question as to whether the "Data Size" field is a 16 bit integer or a 32 bit integer. I need to know which one it is, and whether or not we know for sure if this field is 16 bit or 32 bit in Skyrim's actual game data.

 

EDIT: Nevermind, found the info I was after with a hex editor, but it would still be nice to know what file stuff like this is in

[zilav]

EDIT: Nevermind, found the info I was after with a hex editor, but it would still be nice to know what file stuff like this is in

A lot of information is on wiki actually

http://www.uesp.net/wiki/Tes5Mod:Mod_File_Format#Records

[Arthmoor]

Just in case you guys aren't seeing these for some reason: https://github.com/TES5Edit/TES5Edit/issues/199

[zilav]

Uploaded new verision.

LOD meshes in Skyrim STAT records will now be visible as ordinary strings instead of hex arrays.

[Arthmoor]

Thanks for that. Slight problem though

 

If the path info doesn't match, xEdit is still treating the entire block as an ignore and it shows up as ITMs: http://s16.postimg.org/7n7cvf44z/LODPath.jpg

 

This should probably be changed now that the information is readable and relevant.

[zilav]

Thanks for that. Slight problem though

 

If the path info doesn't match, xEdit is still treating the entire block as an ignore and it shows up as ITMs: http://s16.postimg.org/7n7cvf44z/LODPath.jpg

 

This should probably be changed now that the information is readable and relevant.

This is on purpose - LOD information is not used by the game at all, it is only for LOD generator in CK. Since it doesn't affect gameplay, it is cleaned. The other fields in STAT record are far more important to justify leaving ITM because of LOD info. You can always change EditorID slightly to avoid cleaning when needed.

[Arthmoor]

I think since the CK uses it it would be prudent to not have it cleared out by the ITM detector unless it really an ITM. Having to change editor IDs on stuff because of that is silly.

[zilav]

I think since the CK uses it it would be prudent to not have it cleared out by the ITM detector unless it really an ITM. Having to change editor IDs on stuff because of that is silly.

As you with, I'm just following Elminster's logic of marking as ignored service fields that don't affect game itself, like texture file hashes, marker subrecords, etc.

I personally can't imagine situation when you want to change LOD models for static without changing anything else. It should be easier to name new LOD models as vanilla ones in this case. Maybe only when adding new LOD level meshes non existent in vanilla.

[Arthmoor]

That philosophy mostly works for the older games, but the CK is making more use of internal data now and losing that is problematic.

[Arthmoor]

Have there been any changes to the format of INFO records in the last 2 CK updates from March? I'm starting to suspect the CK is saving more info than xEdit is showing us due to this issue: http://www.afkmods.com/index.php?/topic/4144-skyrim-engine-bugs/#entry156126

 

This hasn't ever become apparent with past work and I'm wondering if that's due to new record data we aren't seeing somehow that's not setting off error messages.

[zilav]

This hasn't ever become apparent with past work and I'm wondering if that's due to new record data we aren't seeing somehow that's not setting off error messages.

Except for a very rare occurencies of unknown DATA subrecord and legacy Oblivion style scripts using SCHR and QNAM subrecords (grouped under "Unknown" field in INFO), there is nothing undecoded left in INFO record.

The absence of PNAM on a lot of INFOs in vanilla master always troubled me too, that's the reason why INFO sorting didn't work in TES5Edit in the past. Even now it probably sorts such records by FormID only, didn't check that sorting code after Elminster updated it. Just don't have any idea how to properly sort decoupled INFOs without PNAM.

[Arthmoor]

Yeah. It's really odd, because I've since found the file as a normal ESP will display in the correct order. Flipping that file to an ESM displays in the correct order. Only attempting to override the contents into a master file (like when I do work on the USKP etc) is causing the order to come out wrong in the CK.

 

I can't really tell if it's something inherent to the CK or if xEdit is somehow causing it because up until this week I hadn't ever seen this happen before. Which means we've either been colossally lucky or it's some kind of relatively recent regression.

 

I went back as far as version 3.1 to see and it happened with them all so I don't know what to make of it at this point. I still think it's largely due to differences in form versions and not so much the lack of PNAMs since Oblivion has never demonstrated this problem at all and Oblivion.esm lacks PNAMs too.

[zilav]

Just always resave your plugins in CK after changing in TES5Edit if they have extensive vanilla dialogue edits, I don't have any clue on what to do here. Let's hope they'll change or improve this system in FO4 somehow.

[alt3rn1ty]

Just always resave your plugins in CK after changing in TES5Edit if they have extensive vanilla dialogue edits, I don't have any clue on what to do here. Let's hope they'll change or improve this system in FO4 somehow.

 

If the final product of the unofficial patches is always last touched by the CK ..

 

Then doesnt that introduce the possibility of the unofficial patches having random wild or dirty edits by the CK when its uploaded ?

 

Edit : I guess a final check with TES5Edit, and so long as nothing needs cleaned then you dont need to save .. But then when its not clean because the CK did introduce unwanted changes .. How to proceed becomes a possible repetitive problem.

[Arthmoor]

Saving the file wouldn't help in this instance anyway since the data gets scrambled during the merge into the master file. Plus we HAVE to run it through xEdit as the final step to get the esm flag back.

 

I don't know what to do here either since it appears to be a rather limited case.

[alt3rn1ty]

Wrye Bash Esmify