0 of 0
Teamwork makes the dream work.
This modders' resource is to help us institute a temporary, less than ideal workaround to a very serious engine level bug that can only be fixed by Bethesda.
To start, what is the bug?
The bug is that new OMOD records (weapon/armor modification records) get stripped off of the weapon or armor they are on when stored in a container with a FormID starting in 00. This effects things such as static placed containers (like the Lodge safe), companions' inventory, the cargo holds of ships that haven't been modified yet, NPCs' inventory.
The OMODs get stripped off when you save and then load a game. They're there when you save, gone when you load.
Obviously, this is a serious drag for any mod that requires OMODs to function properly. As not only will those mods be gone, Starfield has the extra new weird behavior not seen in past games. The slots those mods were in will no longer even appear in a modding bench for that item because Starfield will only show mod slots that already have a mod from that mod slot attached. So not only do you lose the mod, you also lose access to that mod slot on that item, so you can't even fix the item.
I have reported the issue to Cartogriffi with details of how the bug happens, for him to share with Bethesda's QA team. I was told it should be fixed when Bethesda officially supports modding. Not ideal considering the bug even effects the official DLC color swap OMODs, but it is what it is.
I didn't want to wait that long, so I implemented a workaround in my mods and others.
What's up with the workaround?
First off, doing this is not a good idea. The potential for record conflict is a strong likelihood. Those conflicts could do anything from making a mod work incorrectly up to CTDs.
I would have preferred talking to authors in private to help them institute this temporary fix to shield their mods from the OMOD bug. That would have made the process of avoiding record conflicts easier.
But there has been talk about how to implement the workaround in a written public forum, so it's only a matter of time until it becomes common knowledge amongst mod authors.
So that's why I've created this modders' resource. So we'd have a way to organize our efforts for the benefit of all of us. I believe that through co-operation we can succeed in avoiding a conflict shitshow for the months until Bethesda fixes the OMOD bug.
What is the workaround?
The workaround is to take the new OMOD records and give them FormIDs in Starfield.esm starting with 00.
So you might think, we could just call dibs on certain ranges. That was my first instinct in looking for the best way to implement this less than ideal fix.
So I tried that, and unfortunately using a block of FormIDs (starting with 00911000), far from the ranges used by Bethesda, and the temporary fix didn't work and the OMODs were effected by the OMOD bug. Only FormIDs mixed in inside the range used by Bethesda have not been susceptible to the OMOD bug. Hopefully that doesn't mean the OMOD bug is the OMOD feature.
So being limited by what 00 FormIDs work in regards to working around the bug, the likelihood of possible record conflicts grew more.
Which brings us to this modders' resource. What is it?
Well I made a plugin and created 99,999 empty OMOD records.
Their EditorIDs are Injected_OMOD_Placeholder_0000001 to Injected_OMOD_Placeholder_0099999.
Then I injected all these records into Starfield.esm.
The idea of the plugin is to create a shared frame of reference to allocate blocks of FormIDs to various mods, so that as a community we can avoiding breaking each others work, while we all wait for Bethesda to fix this serious bug.
So if you're a mod author that has # many OMODs in your mod and you want to implement the workaround, you could tell me in the comments here, or in Discord, that I need # OMOD records. And I'd respond, ok, the next available block of FormIDs is Injected_OMOD_Placeholder_# through Injected_OMOD_Placeholder_#.
You could load your mod with this one to be able to see what 00 FormIDs to give to your OMODs. That would be real easy if you don't have a lot. If you do have a lot of OMOD records to do, or even you just aren't sure of what you're doing, you could send me your plugin and I could do it for you. For me it would be easy because having all the plugins utilizing this I can automate the process and do it quickly.
And after your records are added, then I update the modders resource plugin OMOD name entries to document your use of those records, like I have in the picture above.
If we are organized as a community then we can safely use this less than ideal fix to get our mods working properly, shielded from the OMOD bug.
This modders' resource is to help us institute a temporary, less than ideal workaround to a very serious engine level bug that can only be fixed by Bethesda.
To start, what is the bug?
The bug is that new OMOD records (weapon/armor modification records) get stripped off of the weapon or armor they are on when stored in a container with a FormID starting in 00. This effects things such as static placed containers (like the Lodge safe), companions' inventory, the cargo holds of ships that haven't been modified yet, NPCs' inventory.
The OMODs get stripped off when you save and then load a game. They're there when you save, gone when you load.
Obviously, this is a serious drag for any mod that requires OMODs to function properly. As not only will those mods be gone, Starfield has the extra new weird behavior not seen in past games. The slots those mods were in will no longer even appear in a modding bench for that item because Starfield will only show mod slots that already have a mod from that mod slot attached. So not only do you lose the mod, you also lose access to that mod slot on that item, so you can't even fix the item.
I have reported the issue to Cartogriffi with details of how the bug happens, for him to share with Bethesda's QA team. I was told it should be fixed when Bethesda officially supports modding. Not ideal considering the bug even effects the official DLC color swap OMODs, but it is what it is.
I didn't want to wait that long, so I implemented a workaround in my mods and others.
What's up with the workaround?
First off, doing this is not a good idea. The potential for record conflict is a strong likelihood. Those conflicts could do anything from making a mod work incorrectly up to CTDs.
I would have preferred talking to authors in private to help them institute this temporary fix to shield their mods from the OMOD bug. That would have made the process of avoiding record conflicts easier.
But there has been talk about how to implement the workaround in a written public forum, so it's only a matter of time until it becomes common knowledge amongst mod authors.
So that's why I've created this modders' resource. So we'd have a way to organize our efforts for the benefit of all of us. I believe that through co-operation we can succeed in avoiding a conflict shitshow for the months until Bethesda fixes the OMOD bug.
What is the workaround?
The workaround is to take the new OMOD records and give them FormIDs in Starfield.esm starting with 00.
So you might think, we could just call dibs on certain ranges. That was my first instinct in looking for the best way to implement this less than ideal fix.
So I tried that, and unfortunately using a block of FormIDs (starting with 00911000), far from the ranges used by Bethesda, and the temporary fix didn't work and the OMODs were effected by the OMOD bug. Only FormIDs mixed in inside the range used by Bethesda have not been susceptible to the OMOD bug. Hopefully that doesn't mean the OMOD bug is the OMOD feature.
So being limited by what 00 FormIDs work in regards to working around the bug, the likelihood of possible record conflicts grew more.
Which brings us to this modders' resource. What is it?
Well I made a plugin and created 99,999 empty OMOD records.
Their EditorIDs are Injected_OMOD_Placeholder_0000001 to Injected_OMOD_Placeholder_0099999.
Then I injected all these records into Starfield.esm.
The idea of the plugin is to create a shared frame of reference to allocate blocks of FormIDs to various mods, so that as a community we can avoiding breaking each others work, while we all wait for Bethesda to fix this serious bug.
So if you're a mod author that has # many OMODs in your mod and you want to implement the workaround, you could tell me in the comments here, or in Discord, that I need # OMOD records. And I'd respond, ok, the next available block of FormIDs is Injected_OMOD_Placeholder_# through Injected_OMOD_Placeholder_#.
You could load your mod with this one to be able to see what 00 FormIDs to give to your OMODs. That would be real easy if you don't have a lot. If you do have a lot of OMOD records to do, or even you just aren't sure of what you're doing, you could send me your plugin and I could do it for you. For me it would be easy because having all the plugins utilizing this I can automate the process and do it quickly.
And after your records are added, then I update the modders resource plugin OMOD name entries to document your use of those records, like I have in the picture above.
If we are organized as a community then we can safely use this less than ideal fix to get our mods working properly, shielded from the OMOD bug.