Update support for Starfield about libloadorder

[Ortham]

Starfield.ccc is used to load plugins, though I haven't checked if they get treated as early loaders. It's also used when it's in the My Games directory, and if the file exists there, the game path file isn't used.

Setting sTestFile<N> does still disable plugins.txt and Starfield.ccc.

[Ortham]

Plugins in Starfield.ccc load before plugins in plugins.txt, but the game adds plugins in the former to the latter as active plugins, listing them before other plugins (active or not) that were already listed there.

[Ortham]

BlueprintShips-Starfield.esm loads after masters listed in plugins.txt, but if listed in plugins.txt it will load in the position it's given there, so it's still implicitly active. However, the game will remove it from plugins.txt if it is there.

[Ortham]

SFBGS003.esm, SFBGS006.esm, SFBGS007.esm and SFBGS008.esm are also implicitly active and behave the same way as BlueprintShips-Starfield.esm (modulo differences due to their medium/light flags).

[Silarn]

I believe all of the core plugins now behave this way, including Starfield.esm. They temporarily adhere to plugins.txt but are later removed from the file and will load after plugins.txt unless required as a dependency.

You say that Starfield.ccc plugins are added to plugins.txt, but what happens if the core plugins are listed there? Since they're removed from plugins.txt that could be rather odd.

[Ortham]

I believe all of the core plugins now behave this way, including Starfield.esm.

I just tested OldMars.esm and Constellation.esm in plugins.txt and yup they behave the same way.

You say that Starfield.ccc plugins are added to plugins.txt, but what happens if the core plugins are listed there? Since they're removed from plugins.txt that could be rather odd.

I added SFBGS003.esm to Starfield.ccc and it loaded earlier than the medium master I had active in plugins.txt, but was not added to plugins.txt by the game.

[Ortham]

Testing the order in which the implicitly active plugins are loaded:

• The light plugins are loaded in the order Constellation.esm, OldMars.esm, SFBGS007.esm, SFBGS008.esm
• The medium plugins are loaded in the order SFBGS006.esm, SFBGS003.esm

[Silarn]

There is an overall load order independent of each type. In the RE server, Expired posted a list from in-game. It included a couple custom mods that had Starfield and BlueprintShips as masters. If you remove those, it looked like the order would be this:

Starfield.esm, Constellation.esm, OldMars.esm, BlueprintShips-Starfield.esm, SFGBS007.esm, SFGBS003.esm, SFGBS008.esm, SFGBS006.esm

3 and 6 are the only ones that don't generally agree with your list. I'm not sure why there was a discrepancy there.

[Ortham]

3 and 6 are the only ones that don't generally agree with your list. I'm not sure why there was a discrepancy there.

I retested and I'm definitely seeing SFGBS006.esm load at FD00 and SFGBS003.esm load at FD01.

[Silarn]

One other thing that came up was that plugins in plugins.txt which are disabled can still affect the load order. If he has the tracker's alliance creation installed and disabled it may have moved SFBGS003.esm up in the order. That's a dependency it has.

[Ortham]

I've retested overlay plugins, and while the overlay flag does still interact with the light flag and extension as I found before, overlay plugins now take up a load order slot, so the flag seems a bit pointless. I've been creating overlay plugins by setting the flag in a hex editor, as I can't find any way to do it in the Creation Kit.

I've yet to test:

• how the overlay and medium flags interact
• if a plugin's masters' flags still affect how FormIDs are resolved (see loot/loot@3abad01)

but I think I've now retested all the functionality I'd previously implemented support for.

[Ortham]

I created a new plugin in the CK that had my Blank.full.esm, Blank.medium.esm and Blank.small.esm test plugins as masters and overrode their xxxxx806 records, then saved the plugin and opened it in a hex editor to see what FormIDs it wrote:

• The masters were listed in the order Blank.full.esm, Blank.small.esm, then Blank.medium.esm
• Blank.full.esm's overridden record was written with the FormID 00000806
• Blank.medium.esm's overridden record was written with the FormID FD000806
• Blank.small.esm's overridden record was written with the FormID FE000806

I then added a new record to the plugin, saved it and took another look at it in a hex editor. The new record was given the FormID 01000810, and the FormIDs of the other records did not change.

So it looks like the behaviour is still different from previous games, where I'd expect the plugins' overridden records to have mod indexes of 00, 01 and 02, and the new record to have a mod index of 03 or higher. I decided not to update esplugin to support Starfield's behaviour before, hoping it would change, but apparently not.

Ignoring how easy it is to break plugins by changing their masters' flags, identifying which plugin a record in a plugin comes from (itself or one of its masters) now requires knowledge of the masters' flags, and I need to be able to do that to identify if a record is new or overrides an existing record, and to detect if two plugins override the same record.

---

I tried to export my new plugin as a small or medium master, but when I did that the CK warned that I had record FormIDs that were out of the valid range, and offered to compact them, but doing so seems to have broken the plugin as the overrides for the medium and small masters now have FormIDs of 0100000x, so it would look like the plugin is adding new records instead of overriding existing records.

That suggests that it's not possible to have a small or medium master that overrides plugins from other small or medium masters, but I'm sure that previous games have allowed light plugins to override other light plugins' records.

[Ortham]

I've tested how the medium and overlay flags interact, and it's equivalent to how the light and overlay flags do: a plugin that has both medium and overlay flags set is loaded into a FDxx slot, taking up that slot.

I've now tested everything I've thought of so far.

[Ortham]

I haven't updated libloadorder's plugin hoisting behaviour to match Starfield's, so it loads the current load order incorrectly. While fixing that I realised it would be good to test the various combinations of plugin flags to see what the new behaviour was.

Apparently the CK won't let you create a plugin file that depends on another plugin file - if you load a plugin file but don't set it as the active file, its records appear in the editor, but if you edit them and save to a new plugin, the new plugin doesn't have a MAST entry for the source plugin and the edited record appears as a new copy.

I got around that by manually setting the master flag in the first plugin before loading it to create the second plugin.

With hoist.1.esp overriding a record from Blank.full.esm at 0x806 and adding a new record at 0x80A and hoist.2.esp overriding 0x806 from Blank.full.esm and 0x80A from hoist.1.esp:

• with hoist.1.esp and hoist.2.esp both unflagged and loading in that order, hoist.2.esp's changes are applied and hoist.1.esp loads in the 03 slot
• with them unflagged and loading in the order hoist.2.esp, hoist.1.esp, hoist.1.esp's changes are applied and it loads in the 04 slot (i.e. ESP-MAST-of-ESP is not hoisted)
• with the order hoist.2.esp, hoist.1.esp and hoist.1.esp medium-flagged, hoist.2.esp was loaded at 03 and hoist.1.esp was loaded at FD02, but the former's override was treated as a new record. I then changed the FormID of the overridden 0x80A record in hoist.2.esp to have a mod index of 0xFD02 and then hoist.2.esp's content was not visible at all in game.
• with the order hoist.2.esp, hoist.1.esp and hoist.1.esp light-flagged and the 0x80A override in hoist.2.esp given a mod index of 0xFE000, hoist.1.esp's changes were applied and it loaded in the FE004 slot, while hoist.2.esp's content was not visible at all in game.
• with the order hoist.2.esp, hoist.1.esp and both light-flagged with the 0x80A override still appearing as 0xFE00080A, hoist.1.esp's changes were applied and it loaded in the FE005 slot, while hoist.2.esp's content was not visible at all in game.
• with the order hoist.2.esp, hoist.1.esp and both medium-flagged with the 0x80A override appearing as 0xFD00080A, hoist.1.esp's changes were applied and it loaded in the FD03 slot, while hoist.2.esp's content was not visible at all in game.
• with the order hoist.2.esp, hoist.1.esp and hoist.1.esp medium-flagged and hoist.2.esp light-flagged with the 0x80A override appearing as 0xFD00080A, hoist.1.esp's changes were applied and it loaded in the FD03 slot, while hoist.2.esp's content was not visible at all in game.
• with the order hoist.2.esp, hoist.1.esp and hoist.1.esp light-flagged and hoist.2.esp medium-flagged with the 0x80A override appearing as 0xFE00080A, hoist.1.esp's changes were applied and it loaded in the FE004 slot, while hoist.2.esp's content was not visible at all in game.
• with the order hoist.2.esp, hoist.1.esp and hoist.2.esp medium-flagged, hoist.1.esp's changes were applied and it loaded in the 03 slot, while hoist.2.esp's content was not visible at all in game.
• with the order hoist.2.esp, hoist.1.esp and hoist.2.esp light-flagged, hoist.1.esp's changes were applied and it loaded in the 03 slot, while hoist.2.esp's content was not visible at all in game.
• with the order hoist.2.esp, hoist.1.esp and hoist.1.esp master-flagged, hoist.1.esp was loaded in the 02 slot and host.2.esp's changes were applied
• with the order hoist.2.esp, hoist.1.esp and both master-flagged, hoist.1.esp was loaded in the 02 slot and host.2.esp's changes were applied
• with the order hoist.2.esp, hoist.1.esp medium-flagged and hoist.2.esp master-flagged, hoist.1.esp was loaded in the fd00 slot and host.2.esp's changes were applied

As a summary table, with the horizontal axis representing hoist.1.esp and the vertical representing hoist.2.esp:

Flag	Full ESM	Medium ESM	Small ESM	Full ESP	Medium ESP	Small ESP
Full ESM	Y			Y	Y
Medium ESM
Small ESM
Full ESP	1	1	1	N	N	N
Medium ESP	1	1	1	N	N	N
Small ESP	1	1	1	N	N	N

1: ESM loads before ESP anyway, so no need for hoisting.

As this is very time-consuming I think I'm going to stop there and assume that medium/small flag makes no difference and that the new behaviour is simply that ESMs and ESPs can be hoisted before ESMs.

[Ortham]

Also, I've noticed that the CK displays a plugin that has only the overlay flag (and optionally the master flag) as an "Update Master file", so I should probably switch to using that terminology. If the overlay flag is set in conjunction with the medium or light flags, the plugin is just shown as "Master File (Mid)" or "Master File (Light)".

[Ortham]

Done as of d67cfa7.

[Ortham]

3 and 6 are the only ones that don't generally agree with your list. I'm not sure why there was a discrepancy there.

I just retested this I found that SFBGS003.esm loaded before SFBGS006.esm, which agrees with what you've got.

---

Reopening this as libloadorder needs to set the load order of Starfield's implicitly active plugins in some way other than writing them to Plugins.txt, since the game will remove them from that file on load.

[Ortham]

Actually, I'm going to close this again as I don't really want to open the can of worms that is making Starfield.ccc writeable, I'd rather continue treating the CCC file order as a fixed read-only order, and write to the CCC file outside of libloadorder before refreshing the load order handle's state.