Give Feedback
This is quite a technical article, so you can find a TL:DR at the top of the last section. If you want to discuss this topic we do recommend reading the entire thing though!
Since the release of the game, eager modders and tool makers have been poking and prodding Starfield to learn more about the Creation Engine 2. This is part of an effort to create some basic modding tools and understand any new modding concepts that might be important going forward. This is a work in progress and some information cannot be fully understood until we have access to the Creation Kit (or get confirmation from Bethesda).
Before we get into this, it's important to note that while the community members who unearthed this information are very talented, all we have for comparison at this point is the previous Bethesda titles (Fallout 4/Fallout 76/Skyrim). It's possible some of these changes were intended and just work in a way we're yet to understand.
The Plugin Subrecord Problem
To fully understand this problem, you must first have a basic grasp of how Plugins and Loadorder work in Creation Engine games. This section is intended as a brief primer on the subject.
Mods can include plugin (ESM/ESP/ESL) files, which are effectively databases that contain the game content. Each plugin consists of a collection of records, and each record (or form) has a "Form ID" that identifies it and a type that tells the game what kind of information it contains. Plugins can also reference records stored in other plugins, for each external plugin referenced this adds that plugin as a "Master". A plugin and its masters must be loaded together for the plugin to be valid. Inside the plugin, individual records can also - if necessary - reference other records (both in the plugin itself and inside the masters) these are known as "Sub-records".
Inside the plugin, records have an internal Form ID, which has a prefix that defines if the record is new data or is intended to override data provided by one of the masters. For example, in a plugin with Starfield.esm as its only master, records that overwrite data in Starfield.esm would be prefixed 00 and any record with an internal Form ID starting with 01 (or higher) is considered to be new data.
When the game engine loads all the data from plugins to start the game it uses the plugin load order to understand the priority of each plugin. This then allows the game to create a new set of prefixes based on the aggregate data from all plugins. On top of this, when the game reads data from a specific record in the load order, it also must look at any sub-records it contains and map those records to their corresponding load order position to access the correct data. The image below shows a very basic example of how data from plugins is mapped into the load order.
The problem lies in how for certain types of data the game does not properly map the Form ID of a record to its load order position. Instead, it uses the position as defined inside the plugin. In effect, this would mean that if a plugin at load order position 03 with no masters has reference to a Form ID at position 00 - which should be mapped by the game to load order slot 03 - could end up pointing to the data stored in Starfield's main plugin at position 00 which would not only be the wrong record but may not even be the expected data type and cause an error.
Even if a plugin had all the default Starfield plugins as masters as soon as another DLC is released or the mod is moved to another slot in the load order these references would no longer be directed to the correct data.
This isn't the case for all sub-records, but it does appear to be the case for a fairly random smattering of them. As of writing this article, the xEdit team have reported that the following form types with this issue:
- Material on Impact Data Set (IPDS) records
- Start Scene -> Scene (LCEP) in Scene (SCEN) records
- Keyword (KNAM) in Sound Keyword Mapping (KSSM) records
- Adjacent Snap Nodes (NNAM) in Snap Template Node (STND) records
- Surface Block Array in Surface Pattern (SFPT) records
- Surface Patterns arrays in Surface Tree (SFTR) records
The community investigation continues to slowly narrow down more affected sub-records and the results will be shared with Bethesda to help them should they not already be aware of these issues ahead of the Creation Kit release. Somewhat confusingly, some of these sub-records that mapped properly in Fallout 4, Fallout 76 or Skyrim now have the issue so it cannot be assumed that this problem only impacts new features added for Starfield.
This hasn't caused an issue for the base game as all official plugins that currently exist (including preorder bonuses) are in a static load order. However, this will become a problem even for Bethesda's own DLC plugins if they plan to release DLCs that don't depend on all previous official plugins that came before. This means that the upcoming "Shattered Space" DLC and a hypothetical second DLC (or any Creation Club content) would need to be loaded together in the order they were released or it may cause problems with the game.
I'm sure there are some of you out there yelling "Why can't we fix this with Starfield Script Extender?" at your monitor. In short, you probably could but it wouldn’t be a perfect fix. An SFSE plugin would have to intercept all places in the game where a sub-record is referenced without being mapped properly. While this isn't impossible, the key flaw is that Starfield Script Extender and its plugins work exclusively on the Steam PC version. Modding is something that is enjoyed by users across Steam, Xbox Game Pass (PC) and even Xbox consoles. Any fix for this problem should ideally be available to everyone as it's so fundamental to the modding experience.
The Light Plugins Problem
To give a bit of background for this issue. Creation Engine games have a hard limitation of 256 slots which can be used to load plugins into the game at any one time (in practice this is slightly less due to slots being reserved by the game). As any seasoned modder will attest, 256 plugins is a fairly big number, but it's not a lot.
In Skyrim Special Edition 1.5.3 and Fallout 4 Bethesda introduced a new modding concept known as "Light Plugins" - sometimes called ESLs. This allowed a single plugin slot in the load order (FE form ID prefix) to be shared between up to 4096 plugins, provided they only include a small number of new records. This change was celebrated as a fantastic addition - now your load order could be massive provided all small mods were flagged as light plugins.
This feature has been carried forward to Starfield (along with a new feature known as Overlay plugins) but the logic used to load light plugins has been changed from how it worked in previous games and unfortunately, this seems to have made it considerably more fragile.
The game engine appears to be treating light and regular plugins as two separate, distinct load orders when looking at the masters of a plugin rather than a single flat list as it had worked in Skyrim/Fallout 4. This means that if your plugin has another plugin as a master which is marked as light, that plugin will be loaded into the "light" load order. Then, if a new version of the master plugin is released without the light flag, the plugin will now be loaded into the "regular" load order. As the plugin no longer exists in the load order it is expected to be in, the game will be unable to resolve any data from your plugin that references the master and the entire plugin will effectively be corrupted.
The image below gives a very bare-bones example of this. In the top situation, the Mod.esm plugin was created while MasterMod.esm is marked as light, so all the references line up correctly. In the second example, the same Mod.esm is shown alongside a MasterMod.esm which has had the "light" flag removed. As Mod.esm hasn't been updated the game won't be able to properly resolve data from the master anymore and will cause errors.
Elminster of xEdit gave a few recommendations on how this could be resolved ahead of the Creation Kit release:
- Restore the single load order - The safest option. This would involve changing the game engine to use a single load order list as it did in previous titles. Making this change would not break any of the current official DLC content and would solve this problem for mods/DLCs. This may also involve updates to the current Creation Kit or other internal tools used by Bethesda to account for the change.
- Update the plugin format to have split masters - If the split master approach is the way forward, then the plugins could be updated to have both a light and regular master list (to match what the game sees). This change would require some fundamental assumptions in existing modding tools to be updated. It would also add complexity to tools that check if all masters are present and correct for a given plugin.
- Enforce that all light plugins use ESL - Every light plugin could be made to use the file extension .esl and anything that wasn't light used .esm. This isn't a fix for the problem, but it does mean that if a light plugin ever lost its light flag it would have a different file name and therefore wouldn't be recognised as a master on any patches. This is the least likely fix and would require buy-in from the entire community (including all brand-new mod authors) to work out.
Ultimately it's up to Bethesda to decide if this is even a problem they feel needs to be fixed, but with the current implementation it will be very difficult for community-created modding tools to support the full range of data formats Starfield offers.
What does all this mean?
TL:DR - Based on community research, it appears that Starfield has problems accessing sub-records from the load order in certain situations. The engine also now treats light plugins and regular plugins differently so this may cause problems with load ordering as we currently understand it.
No need to dust off the pitchforks yet, this isn't the mod-pocalypse! Problems like this may very well be the reason plugin modding is effectively disabled in the current release of Starfield. Bethesda may already have a roadmap of things that need to change before handing us the Creation Kit. We've reached out to Bethesda for comment on these issues but they have declined to comment on anything modding-related at this time.
A working version of xEdit (known as SF1Edit for Starfield) will be coming to Nexus Mods in the not-too-distant future with warnings and restrictions to prevent users from doing things that would compromise the integrity of their load order.
SF1Edit will only allow plugins to be saved out as regular (non-light) ESM plugins and will prevent any known sub-record that is not mapped correctly from being set to anything other than a reference to Starfield.esm. If Bethesda does continue to use the two load order approach then it would require a significant rewrite of xEdit that could take months or even years before it's ready for use.
- ElminsterAU
It is strongly advised that users exercise caution when using any mods that include plugins made outside of SF1Edit as these could cause more harm than good in your game. Any plugins marked as "light" or "overlay" should be avoided until we have the Creation Kit and documentation from Bethesda.
For now, we also advise users to shy away from loading plugins with the "sTestFile" method in the Starfield INI files. This approach was never intended to be used outside of internal testing for the game. It can do wild things like forcing new plugins to load between Starfield.esm and BlueprintShips-Starfield.esm which can lead to further load order issues. If you're keen to use plugins you can use Nukem's Plugins.txt Enabler which requires Starfield Script Extender on Steam and an ASI Loader on Xbox Game Pass (PC). Keep in mind that every time the game gets updated these plugins may break, which would switch off this feature again and could break your saved game.
118 comments
Comments locked
A moderator has closed this comment topic for the time beingHaving this knowledge base at hand and then creating Starfield without the following options is inexcusable.
This is a small list...obviously there's much more
So you have to wonder how Bethesda didn't manage to do this themselves before release, i.e. simply put a decoration panel in all the habs with a disclaimer not to edit the ship or it'll disappear.
As the other guy says, I still like the game, but it's pretty clear BGS got hyper-focused on a handful of features and neglected others, ignoring any data about what players actually spent their time doing in previous Bethesda games.
Not saying it cannot be done; MMO's do this all the time to varying degrees of success, but MMO's also don't have as strict of release windows and production timelines as a published AAA game does. The release was already pushed back on this once. At some point as the management of a AAA development team you have to stop and just accept that this game is "good enough" and do your best to polish up what you do have in order to meet your required release deadline. Above all else, it is a business which is sad that that has to take precedence, but you have to understand that it always does and always will.`
You really think someone in the main team really does look up more than the top 20 mods? They have families and a live in general ;)
...it only takes a few seconds to click "page 2" on the popular mods section...so, yes.
Having said that, I agree that the notion that Bethesda was banking on mods is silly (after all, Starfield is very much intended for consoles, where modding is basically not a thing), and I think corner-cutting isn't the root of the game's biggest problems. I strongly suspect that "Overdesigned" is a thinly veiled retelling of the game's development process, as the game's a muddled mess that can't decide what it wants to be. Making a cost-effective, family-friendly, luxury cargo-hauler for deep-space exploration and bounty-hunting might work out all right in the game, but IRL, such an approach is foolhardy in the extreme, no matter how big the development budget.
right now all we can do is wait and see
Also you
That said, I would recommend you copy it elsewhere and try it. Load up your save and play it for a while, making sure you don't overwrite the save. In other words, test it before you permanently delete the old mod.
~ There; fuckin' happy that you have an answer from someone within the community now?
...for f*#@ sakes. >_>
I've maintained for years, that Bethesda does not support modders, they tolerate modding because they can exploit it. It helps that it doesn't require a whole lot of work on their part, and they can reap a lot of positive PR from the phenomena.
Despite all their claims, I don't think modding is a big deal to the beancounters at Beth, and now M-soft. I don't think they realize how valuable it is to their games, and how it keeps them alive for years and years after release. How the constant presence of the title in the public zeitgeist preps people to buy the inevitable remaster. Or remasters as the case tends to be...
It's pretty clear that their focus is on releasing the safest and blandest triple-A titles for the widest possible audience, with little regard given to it being held together with glue, tape, and prayers to Godd Howard. Any issues relating to modding are problems they happily leave for the modders to sort out.
If Bethesda really was interested in supporting the modding scene, they wouldn't routinely break everything and muck things up consistently. They would pay more attention to making modding as painless and accessible as possible. They'd offer a true and robust sandbox with actual depth and complexity, with systems and mechanics in place on which to build our own custom content and to truly do whatever we want within the game world. You know, like they keep telling us in their marketing material, instead of releasing half-baked worlds where everything is a facade exactly as deep as required by the game's narrative, and the only thing they bother to polish is the looter-shooter cycle since that has the largest customer base.
It pains me to hear, that with every title they release, they seem to pay less and less attention to all the hurdles that people need to jump through to mod their games. I long for the day that some developer finally decides to challenge Bethesda at their "own game", and releases a title that was designed with modding in mind from the ground up.
But in the meantime... I'm sure the modding community will figure out a way to work around all the hoops Bethesda throws at us. Not like there is much of a choice on the matter, Bethesda games are still pretty much the only games in town when it comes to modding.
- EDIT - Except maybe Sims. But even so, you can turn a Beth game into a crappy Sims game, but you can't really turn a Sims game into a Beth game. And I doubt anyone wants Bethesda to start emulating Sims as far as game publishing and monetization goes...
Now, unintentionally, I totally agree with, but I highly doubt they would screw around with the main selling point of their games on purpose.
btw, The creation kit for fallout 4 and skyrim both released about the same time they're planning to release this one (after the game released I mean). So they aren't really doing anything different in that regard.
My feeling is that they have something planned for the CK. Maybe the (smarter) merge function we have been asking for.
Have you heard about Creation Club? Because that is exactly why they made it.
I think sometimes people confuse what support means from a technical sense with what it means as in "I personally support you doing this."
Basically, you are free to mod the game, but they won't offer any technical support if you run into issues with the game because of it. That's technical support 101.
Five years from now, I am sure it will be an outstanding game if properly modded!
The xEdit and Creation Kit are just a façade that the user sees. Everything its does in game is provided by engine code. Launched once during the start of the game (or some event, for example the start of a quest), it creates addresses for itself. Some things are updated at runtime, some are not, it all depends on the functions in the game engine hardcoded, which ensure functionality for the façade.
And if you changed the indexes during the process, in some cases it can be compared as if you sent a parcel, and the recipient at that moment moved without leaving a new address.
Doesn't matter at all if you are using light plugins or not. You just need to take into account that the order of light plugins and the order of regular plugins are different, it is actually two orders existing in the same indexed space.
Actually i don't think it is a trouble or bug - it is just a feature that needs to be taken into account when modifying the game.
He may even be correct that it is a new feature, and when the Creation Kit is released that will become apparent. If only Bethesda was a little more forthcoming. Oh well.
"No need to dust off the pitchforks yet"
lol them pitchforks never getting dusty up in this piece. The revolution is eternal.