FO3Edit Critical Script Conflict: Unofficial Patch vs Fix

[bigEZchad]

I've encountered a Critical Conflict in FO3Edit between Fallout, UF3P and Civis Fixes. I've tried doing 2 fresh installs of Fallout 3 itself from Steam as well as completely deleting both mods plus archives and re downloading them from NexusMods. If this is a change I somehow made, I'm not entirely sure how to revert the changes or resolve it. My guess is that it occurred when I tried to correct the plugins of an outdated save file, but I'm at a loss.

The critical conflict is under Scripts - 0002060E MS15SydneyScript . The Compiled Sizes and Loot Variables are all different for the 3 sources of Fallout3.esm, UF3P.esm and Civis Fixes.esm. Normally I would prioritize Civis Fixes changes in this situation, but those settings are already the conflict winners in this case yet the critical conflict is still unresolved. This is the toughest FO3Edit scenario I've been challenged with yet and I'm not yet experienced enough to solve it confidently.

 

I also have a another similar critical conflict in Scripts - 04004E2E DLC04PungaPlantSCRIPT . Same .esm culprits, these also have 3 different Compiled sizes and scripts, but only vary below in SCVR Name. The references all match for the most part. This conflict looks a little easier to resolve, but without proper context I'm not much better off solving this one than the 1st.

 

Would someone be willing to help me out, please?

Screenshots SydneyScript: https://imgur.com/a/gKpTjP0

1st Image: Left FormID Window
2nd Image: Right Window pt 1 Compiled Size
3rd Image: Right Window pt 2 Loot Variables

 

Screenshots PungaPlant: https://imgur.com/a/AfBVba7

1st Image: Right Window pt 1 Compiled Size
2nd Image: Right Window pt 2 Loot Variables

[HadToRegister]

What you have is perfectly fine AS-IS

the Official Patch is red because it conflicts with the FIX patch that loads after it, but the FIX patch will win out.

You don't need to make everything GREEN,

Whatever loads LAST is the Winner, and from the size of the FIX patch, it definitely should load last, don't worry about the 'conflict', it's just that, a conflict

[bigEZchad]

Thank you. The fact that it was a conflict wasn't as concerning as the Pink background, which I understood to be a "Critical conflict". I found this on a thread from 10 years ago and got worried:

 

 

the pink background is documented. It represents a critical conflict as opposed to just a simple conflict. Prime example is if different versions of a script record have variables of different names under the same variable index.

This is a critical conflict because the save game only stores the variable values based on the variable index, not the variable name. So if you have an existing savegame and then add/remove a module which overrides that script record and the new winning record has different variables for the same variable indices you can end up with pretty bad crashes (e.g. because the safegame contains a float value in index 3, and the new script expects a formid in index 3, crash and burn!)

 

 

Maybe the conflict was always there and I didn't notice it, but it seemed to appear after some change was made. That's why I tried to get a "fresh" install of the mods, but that didn't change anything, so it seems like it was just my imagination. In any case, it is a script conflict with a pink label, and I was concerned if I didn't address it now, it would create crashes down the line, especially during those quests.

Edited March 30, 2020 by bigEZchad

[HadToRegister]

Thank you. The fact that it was a conflict wasn't as concerning as the Pink background, which I understood to be a "Critical conflict". I found this on a thread from 10 years ago and got worried:

 

 

the pink background is documented. It represents a critical conflict as opposed to just a simple conflict. Prime example is if different versions of a script record have variables of different names under the same variable index.

 

This is a critical conflict because the save game only stores the variable values based on the variable index, not the variable name. So if you have an existing savegame and then add/remove a module which overrides that script record and the new winning record has different variables for the same variable indices you can end up with pretty bad crashes (e.g. because the safegame contains a float value in index 3, and the new script expects a formid in index 3, crash and burn!)

 

 

Maybe the conflict was always there and I didn't notice it, but it seemed to appear after some change was made. That's why I tried to get a "fresh" install of the mods, but that didn't change anything, so it seems like it was just my imagination. In any case, it is a script conflict with a pink label, and I was concerned if I didn't address it now, it would create crashes down the line, especially during those quests.

 

 

The script/mod last in the load order wins the conflict.

 

The RED is just showing you that the FIX patch is pretty much cancelling out everything that the Unofficial Patch changed.

It's not a problem

[bigEZchad]

Thanks again. Figures I was worried over nothing. I left a post for CivisRomanus on the fix mod page (since I can't delete my original post outright) just in case it is something.

 

After learning a bit more about scripts and local variables (I called them loot variables earlier), I'm totally unqualified to make those level of changes without explicit instructions anyway. Nor did I modify anything from what was originally there (that I know of).

 

TOPIC CLOSED! My query has been answered.

[xardbazz]

its better to resolve all conflict, it will make the GAME LOAD FASTER AND RUN BETTER ...