[WIPz] TES5Edit

[zilav]

The first FO4 DLC will be out next week, but unfortunately I won't have time to update FO4Edit the next few days either. So I decided to inspect it's ESM file right now and make necessary changes for proper support. The technical summary of DLC01:

• it has several archives, so archives loading is back to partial names matching as in Oblivion unlike Skyrim that required the exact match between BSA and plugin names
• ONAMs in TES4 header as in previous games. I already knew that after talking with the author of Spring Cleaning mod, but now it is "officially" confirmed
• TNAMs in TES4 header. Hlp said that the game doesn't read them, but they are still present
• the "bug" with respawning and disabled sprinting in modified cells is not a bug as I was expected, just requires some changes in the CELL record itself: VISI and/or PCMB field. This makes more complicated cell edits since you'll need to remember to update those fields accordinly after using "Copy as Override" in xEdit.
• "PNAM - Previous Info" is back in INFO records, so sorting of INFOs is still required(?). No idea why the base game works without them just fine
• edits can be made to QUST children records (DIAL, INFO, SCEN) without overriding the quest record. in xEdit it looks like "Children of XXXXXXXX" where X is the FormID of QUST in master files. That's really awesome for compatibility, you no longer need to copy the entire quest data just to make changes in it's dialogues. Kind of bad for xEdit since it doesn't have ability to create children groups yet, needs updating.
• there is one instance of QUST being overridden and missing a lot of it's data: stages, aliases, etc. But there is a new flag in record header. I suspect this means "partial" changes. If true, this is another great feature for compatibility, but a can of worms for conflicts resolution.
• various additions to other records: SADD in RACE for base(?) state groups template, WGDR god rays in LGTM lighting templates, unknown PNAM in RFGP.
• usual Bethesda stuff: ITMs and UDRs.

[InsanePlumber]

^^^   Let's add to this list Beth standards as ITM and UDR

Apparently without    I'm blind.

[Kesta]

The 2 quest-compatibility things sounds really awesome. Same for partial ba2 loading (finally a way for bsa-packaged mods to get rid of the size-limit). Beth learn slowly, but Beth learn.

[Arthmoor]

You never had to edit the root quest to change dialogue in its quests. That's never been necessary going all the way back to Oblivion. Unless I'm missing something here, that's not anything new

[zilav]

You never had to edit the root quest to change dialogue in its quests. That's never been necessary going all the way back to Oblivion. Unless I'm missing something here, that's not anything new

Dialogues in FO4 no longer have their own top group and are in children group of quest records, so to modify them you need to copy all parent records. The same as to modify exterior REFR both parent CELL and WRLD records have to be copied.

[Arthmoor]

Yes, but you seem surprised that the DLC has dialogue edits that don't edit the quest record. Given past history, this isn't that surprising.

 

I am aware they made the dialogue trees children of the quest records, at least as far as xEdit has been able to tell us. If you're seeing dialogue edits that don't include the parent records then maybe the UI representation of them is not correct somehow.

[zilav]

Yes, but you seem surprised that the DLC has dialogue edits that don't edit the quest record. Given past history, this isn't that surprising.

I was surprised to see children groups without parent records, that never happened in any of previous games, so that's really surprising. Maybe it is just an error in ESM from buggy CK, we'll see soon. There is no problems with representation in xEdit afaik.

[Arthmoor]

Has anyone decoded the contents of a .cdx file yet?

[zilav]

Has anyone decoded the contents of a .cdx file yet?

Better wait for CK first, maybe it will have something related to CDX so no need to decode anything.

[InsanePlumber]

Can I use xEdit (3.1.3 be500bb) with other Beth games safely. (OBL, FO3, FNV, SKY)

I ask because 3.1.3 version has this option for "Row Height" which for me is very useful.

[hlp]

Yes. At the moment it is the most complete version, and anything really experimental is limited to Fallout 4.

[InsanePlumber]

@hlp

Thank you for the quick reply.

When cleaning Oblivion DLCs (I did not do this about two years) I encountered some discrepancies in comparison to the BOSS (2.3.2) and LOOT (0.8.1 245 g1a3a147) recommendations.

Errors (lack of update) in BOSS and LOOT "database" or I have made mistakes somewhere?

*************************************************
DLCVileLair.esp
BOSS or LOOT recommendations
- Contains dirty edits: 26 ITM, 1 UDR records.

xEdit 2.1.2 2015-11-09 or 2.1.3 be500bb
- 16 ITM, 1 UDR
*************************************************
DLCMehrunesRazor.esp
BOSS or LOOT recommendations
- Contains dirty edits: 21 ITM, 15 UDR records.

xEdit 2.1.2 2015-11-09 or 2.1.3 be500bb
- 14 ITM, 15 UDR
*************************************************
DLCBattlehornCastle.esp
BOSS or LOOT recommendations
- Contains dirty edits: 13 ITM, 74 UDR records.

xEdit 2.1.2 2015-11-09 or 2.1.3 be500bb
- 3 ITM, 72 UDR
*************************************************
DLCFrostcrag.esp
BOSS or LOOT recommendations
- Contains dirty edits: 73 ITM, 94 UDR records.

xEdit 2.1.2 2015-11-09 or 2.1.3 be500bb
- 71 ITM, 94 UDR
*************************************************
Knights.esp
BOSS or LOOT recommendations
- Contains dirty edits: 121 ITM, 257 UDR records.

xEdit 2.1.2 2015-11-09 or 2.1.3 be500bb
- 83 ITM, 255 UDR
*************************************************

xEdit log of cleaned ITM UDR in abovementioned DLCs.

[zilav]

2.1.2 is a very old version, a lot has changed since then.

[Kesta]

With a bit of proudness (yes, that's not an English word. But I'm not a native speaker either, so I don't care), here is my first "for the bigger public" xEdit script :

 

{
  Model Opener v0.1
  Hotkey: Alt+M
  
  Open the model (MODL) of the record into NifSkope
}
unit userscript;
 
const
  
  NifSkopePath = 'E:\Modding Tools\NifSkope\NifSkope.exe'; //Path to Nifskope.
  
var
 
  modelPath: String;
  
function Initialize: integer;
begin
  AddMessage('NifSkope installed in: '+NifSkopePath);
end;
 
function Process(e: IInterface): integer;
begin
 
  modelPath := 'Meshes\'+GetElementEditValues(e, 'Model\MODL');
  if ResourceExists(modelPath) then begin
    AddMessage('Opening: '+modelPath);
    CreateProcessWait(NifSkopePath, Format(' "%s" ', [DataPath+modelPath]), False, False);
  end
  else begin
    AddMessage('[Error] '+modelPath+' do not exist in the current data folder.');
  end;
end;
 
end.
 

 

Direct Download

(merge the "Edit Scripts" folder with the one into your xEdit installation folder)

 

This allow you to open the model associated to the currently selected record(s) into NifSkope directly.

 

You'll need to edit the NifSkopePath constant to your actual NifSkope path.

 

I haven't digged much into NifSkope's arguments, so for now you need the mesh to be EXTRACTED from its bsa. Gonna ask Jon if there is a way to work around this.

 

Once you've edited the script the first time to set your nifskope path, you can run it indefinitely by just pressing Alt+M with the records of which models you want to open selected in the left-pane.

 

This (currently) only work for records that have a model sub-record in Model\MODL. That's the case of Statics, weapons, art objects, ... and most of the "common" objects that have a mesh. Armors/AA aren't ok because they have a different path (because they point to two models, MOD2 and MOD3, one for male and one for female). If the record doesn't have a Model\MODL subrecord, the script will just consider the model is "Meshes\", and refuse to open it in nifskope because it cannot find a file named "Meshes\")

 

Happy modding

[Arthmoor]

If you ran Nifskope via the installer, I would think that plants a registry entry for the program path. So that should be the best option. If it doesn't do that, then that might be a useful suggestion to offer

[Kesta]

If you ran Nifskope via the installer, I would think that plants a registry entry for the program path. So that should be the best option. If it doesn't do that, then that might be a useful suggestion to offer

 

You mean to auto-detect the NifSkope path ? That would be an awesome solution if xEdit supported a language less esoteric than Delphi (or rather a custom implementation which make several Delphi tutorials on the web irrelevant, especially for this kind of "dirty" work. rant, rant, rant... xD), but for now looking up for a registry entry in a script is beyond my possibilities 

 

P.S. : Added a download link in the previous post for those who wouldn't know where to copy paste those lines.

[fireundubh]

If you ran Nifskope via the installer, I would think that plants a registry entry for the program path. So that should be the best option. If it doesn't do that, then that might be a useful suggestion to offer 

 

xEdit's script adapter supports only TRegistryIniFile.Create(sRegPath) and the root defaults to HKEY_CURRENT_USER. You need HKEY_LOCAL_MACHINE to get the NifSkope path, which means you need access to the TRegistryIniFile.FileName property to change the root key, or you need the TRegistry class. I think TRegistryIniFile inherits from TCustomIniFile, but I don't see the FileName property in wbScriptAdapterMisc.pas.

 

edit: Actually, FileName is read only, so I think you'd need TRegistry. Zilav probably knows better though.

[Kesta]

xEdit's script adapter supports only TRegistryIniFile.Create(sRegPath) and the root defaults to HKEY_CURRENT_USER. You need HKEY_LOCAL_MACHINE to get the NifSkope path, which means you need access to the TRegistryIniFile.FileName property to change the root key, or you need the TRegistry class. I think TRegistryIniFile inherits from TCustomIniFile, but I don't see the FileName property in wbScriptAdapterMisc.pas.

 

Ah, I expected that it would be somehow possible with some more magic from actual delphi coders. I'll put some hacky workaround together on my own then

 

 

Edit : Wait, I have an entry for nifskope under HKEY_CURRENT_USER. namely HKEY_CURRENT_USER\Software\Classes\Applications\NifSkope.exe

 

Not sure if this is because of something I did or default behavior, but if anyone can confirm, no need for a stupid external lib and an exchange file.

 

If some people could open Regedit (just type this and enter in windows "search" function), and in the program that open look for this entry in the arborescence, it'd be much useful.

[fireundubh]

The path you want is HKLM\SOFTWARE\Wow6432Node\NifSkope and the key you want is Install_Dir. But you can't get there without TRegistry.
 
I'm adding TRegistry and its methods and properties to wbScriptAdapterMisc.pas. About 75% done. Lunch time. But then I'll need to submit the changes to Zilav.

edit: Zilav says you can get there with TRegistryIniFile after all.

So, try:
 

TRegistryIniFile.Create('HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\NifSkope\Install_Dir');

[Kesta]

Uh, Almost missed your edit. Thanks a lot, gonna try

 

 

------------------

Something about a good old "debate" that came out once again today : ITM cleaning. Shot in the dark, I'm hoping I earned enough credibility around here to at least convince you to read the post before moving on an other thread.

 

Someone mentioned the hunterborn mod had a quest that would be broken if you removed the 9 ITMs reported in it.

 

After a quick check, I think there is a small chance that this would actually be a thing. Here is why there is 9 ITMs :

 

3 refs, in 3 different outsid-cells (worldspaces childrens) that the author referenced from his quest, giving them the persistent flag. 

So they're virtually moved in the persistent cell, leaving the original worldspace's cells  as 3 ITM, with their respective sub-block and block as ITM as well, leading to the total of 9 ITMs.

 

In the cleaned plugin, there isn't any trace of the original non-persistent cell groups, only thing left is the persistent cell with the (now-)persistent ref. Since there is a report of this breaking those quests... I'm wondering if it's not possible that somehow the game is unable to access the persistent refs, or treat them as such, because their "physical cell" records aren't in the plugin.

 

Have this specific case even been investigated before ?

 

I just installed the mod an am currently testing on a vanilla/skse/skyui/hunterborn-only game just to make sure this isn't one more of those " I'm sure I've found something that could be an issue, so I'm gonna claim that cleaning mods break them because the earth is flat".

 

Original reddit thread : https://www.reddit.com/r/skyrimmods/comments/4c0ojm/how_does_cleaning_mods_in_certain_cases_mess_up/d1eepa2

 

Edit : Well, since I started, i'll probably just see it for myself just to make sure, but for now, the bugreport is actually "I don't know what the issue is, but the mod author said there is one".

[zilav]

Does CK move those refs too into persistent cell when you open and save esp? Afaik all exterior persistent refs must be under a single persistent cell, all other exterior cells are temporary and can't hold persistent references.

[hlp]

There are only 8 ITM and the references moved to the persistent cell are still there after the cleaning. Only the UNCHANGED cells themselves are removed. So no, cleaning cannot break this mod.

[Sharlikran]

What's the new version number for DLCRobot.esm?  Does anyone have Automatron?  I don't have it yet.  The old version was 0.95 and Wrye Flash is throwing out errors with the DLC so I need to update Wrye.

[zilav]

What's the new version number for DLCRobot.esm?  Does anyone have Automatron?  I don't have it yet.  The old version was 0.95 and Wrye Flash is throwing out errors with the DLC so I need to update Wrye.

No changes, It is still 0.95 as Fallout4.esm

[Sharlikran]

No changes, It is still 0.95 as Fallout4.esm

 

At first I thought the ESM was just some random file.  After I learned it was the DLC then I thought the version number must have changed.  Do you have my experimental version of Wrye Flash?  Do you get any warnings about Corrupt/unrecognized File with the DLC?  I'm asking because a user reported an error that shouldn't be happening if that version number didn't change.