[WIPz] TES5Edit

[Arthmoor]

The two DLCs are public releases, so we can talk about them openly.

 

Yes. I've made a test plugin using Automatron as a master. Made a minor edit to Codsworth's dialogue. The ESP file that resulted has all of the original properties that Fallout4.esm shows. Including the loss of the "Unknown 14" flag.

 

Made a similar test file for Wasteland Workshop. Minor dialogue edit. The ESP again inherited everything from the QUST record as it existed in Fallout4.esm.

 

Based on this, I agree it needs to be reported on the private forum. I'll do so in a bit here.

[zilav]

If those quests and related removed data still work in game with DLCs loaded, then this flag is indeed meant for inheritance similar to how NPCs inherit portions of data from templates. Maybe this is another difference between the public cut version of CK and the real one.

But if this is indeed a genuine error, then I can't belive how they allowed it to slip through into the relase versions of DLCs because those data removals should be breaking quests.

[hlp]

It's not a mistake, as it works in game. I added the flag (Partial Form).

This will need a new category for comparison, or we will have to create the missing values from the direct master so the comparison works. The later might be easier. Still need to avoid saving the changes unless the end user changes it. Also, we need to know which SubRecord are affected by flag 14.

[Arthmoor]

It's a moot point - they patched it out with the 1.5.151 beta update. So THEY appear to have agreed it wasn't working right in that instance

[zilav]

It's a moot point - they patched it out with the 1.5.151 beta update. So THEY appear to have agreed it wasn't working right in that instance

What about COMCodsworth [QUST:000BBD94] in Automatron with similar missing data? Or it is intended change?

[hlp]

Still flagged as partial, so the possibility has still to be handled. Only DLCWorkshop01 was updated with the patch.

[Arthmoor]

What about COMCodsworth [QUST:000BBD94] in Automatron with similar missing data? Or it is intended change?

They didn't issue a patch for Automatron, so one would assume they intend to leave that change in. Perhaps it's actually working right. I'm not entirely sure why the other one wouldn't be, but they clearly agreed the record in Wasteland Workshop needed to be removed.

[zilav]

Uploaded new build.

Updated FO4 definitions and better handling of new plugins.txt format in Beta patch.

Combined references will be displayed as [Placed Object] in square brackets and mesh name is added into the name

 

[REFR:000782AA] (places BldWoodPBgRoomCorner03 [sCOL:0001E597] in GRUP Cell Temporary Children of MinutemenHoldingCell "Minutemen Holding Cell" [CELL:000782A8] in Precombined\000782A8_0105A45C_OC.nif)

 

New option in filter window by precombined status.

[Arthmoor]

Some stuff for Fallout 4:

 

A couple of record types that could use the sorting logic for ITM purposes:

https://i.imgur.com/ee4Fpjq.png

https://i.imgur.com/kXTPtl9.png

Identified a linked subrecord indicating alias collections:

https://i.imgur.com/1JShdSB.png

The ALCS marked as unknown is the Hex equivalent of the Alias ID in the ALST.

[zilav]

ARMA is waiting to be decoded, I'll mark it later.

Precombined entries in CELL were sorted at some point but caused huge lags when copying records because amount of entries in some of them reaches 22000+, so I disabled sorting. xEdit needs some update for internal sort timings and avoid excess ones when copying containers.

How do you label ALCS? I know that it is an alias, but no idea about it's purpose.

[Arthmoor]

ALCS stands for Alias Collection. With Fallout 4, it's now possible to use this to store multiple objects into the same single alias in the CK. Makes things far easier for handling generic groups of stuff so you don't need dozens of aliases.

 

Wish Skyrim had this because it would have come in quite handy for RFYL and WVA

[Kesta]

I was browsing the latest commits in order to figure out some kind of changelog for the new build, and stumbled across this :

https://github.com/TES5Edit/TES5Edit/commit/1f9c3d82da25fd7c83b86aab460ad523128f5720#diff-0b4f74bad86541ce7581b8321928769dR14775

 

Is this normal that "EarlySunrise" is actually "EarlySunrire" ? (no idea what the incidence would be, but I'm guessing scripts trying to access this element would have to take account for the typo ?)

[zilav]

Nope, will fix later.

[Kesta]

Any opinion on the feasibility of this :
 

Kesta, do you know how people are going to get around the 'precombined' objects thing? As I see it, if you made a change to a static world mesh, you would need to regenerate all cells featuring that mesh. It basically means I can't do anything because that is pretty much what I do. It seems like a nightmare for compatibility.

In the future, once things are more stable and decoded, we can envisage some major xEdit script to run at the end of the setup (like dyndolod or skyprocs patchers) that would recombine them properly  or regenerate the cells (or whatever there is to do to have them work) based on the user's installation. But that's not going to happen before a while.

 

For now authors are advising to set bUsePreCombinedObjects to 0 in Fallout4(custom).ini, but I see a lot of potential issues arising with this, and several peoples reported performances issues with this tweak.

 

(Sounds like a job for Sheson )

[zilav]

You can write such script now:

1) Loop over references of STAT

2) check if it is precombined

3) get precombined mesh it is in

4) remove that mesh/ref from XCRI index of CELL for all refs that are precombined together in the same mesh

 

This way you are uncombining only refs that needs to be instead of everything when using ini setting.

 

Better is to recombine meshes that this references are a part of, but that will require mesh work which is out of xEdit's scope for now.

[fireundubh]

Is it possible to uncombine a mesh in a way that each individual object that makes up the precombined mesh is replaced with a miscellaneous object?

[zilav]

Is it possible to uncombine a mesh in a way that each individual object that makes up the precombined mesh is replaced with a miscellaneous object?

No idea. I even not sure that the above method is a good idea since there are occlusion and LOD issues when you start uncombining references judging by comments on nexus.

[Kesta]

I just installed this : http://www.nexusmods.com/fallout4/mods/12562/?

 

For some reasons, the 2 GMST edited aren't present in Fallout4.esm ? There is two with a similar tame minus the "T" (fDiffMultHPToPCSV and fDiffMultHPToPCSV but no fDiffMultHPByPCTSV or fDiffMultHPToPCTSV). Should this kind of records be included in the "hardcoded" file ?

[fireundubh]

Not all game settings are in Fallout4.esm, and their Form IDs don't matter.

[Sharlikran]

I just installed this : http://www.nexusmods.com/fallout4/mods/12562/?

 

For some reasons, the 2 GMST edited aren't present in Fallout4.esm ? There is two with a similar tame minus the "T" (fDiffMultHPToPCSV and fDiffMultHPToPCSV but no fDiffMultHPByPCTSV or fDiffMultHPToPCTSV). Should this kind of records be included in the "hardcoded" file ?

Those might be from the author and not in CK or hardcoded in EXE. So no only real  GMST should be in Fallout4.Hardcoded.keep.this.with.the.exe.and.otherwise.ignore.it.I.really.mean.it.dat.

[Arthmoor]

As far as I understand it, the only things that should go into the hardcoded forms file are things that show up in the CK with absolutely nothing loaded. They need to have actual form IDs though, not the 00000000 IDs most of those settings variables list with in the CK.

[zilav]

As far as I understand it, the only things that should go into the hardcoded forms file are things that show up in the CK with absolutely nothing loaded. They need to have actual form IDs though, not the 00000000 IDs most of those settings variables list with in the CK.

Indeed. GMST records should have a valid FormID, however it is unused by the game and xEdit, they override each other by name in Editor ID field. So any mod that wants to set a game settings can either override the one from the game master if it exists there, or just add a new GMST with appropriate name.

[Kesta]

Yap, I knew about the formID thing being replaced by edid for GMST. My surprise was just that despite being valid (the changes do take effects in game) you don't see it in xEdit if oyu don't have a plugin already editing it.

And since this GMST isn't in Fallout4.esm nor anywhere where fo4edit can reach it, you can't compare the mod's value against the vanilla one.

 

Edit: Come tot hink of it, I've seen some other cases of this in Skyrim, though I wasn't that much interested by all of this at this time.

[fireundubh]

There are a ton of undocumented game settings that are not in Fallout4.esm. I compiled this list last year, so there are probably new game settings now.

 

Complete list of game settings (under Uncategorized; any categorized setting is an INI setting)

 

I don't know if most of these even show up in the CK's game settings editor.

 

All game settings are hardcoded, so you can't actually add new settings. You can only override game settings, and you do this by using load order and the same Editor ID.

 

In the case of GMSTs, what Zilav means by a "valid Form ID" just means a Form ID that is unused by the engine and any plugin.

[Nico coiN]

Thanks for these game settings fireundubh. I'm looking for a setting that may increase the max distance between the player and the camera when zooming out in 3rd person view. fPitchZoomOutMaxDist has no effect. Any idea ?