Understanding the theory of load orders

[dieangel68]

Hello everyone, first i would like to say thank you for all the peoples here who made those truly awesome mods for Fallout3, i probably wouldn't be still playing this game without you.

 

I would like to expose my current understanding of load orders, in an attempt to clarify things, feel free peoples to correct me.

First and foremost i would like to post my current load order, wich might make you understand why i'm trying to understand all this.

 

Most of this load order is FOMM generated so i have no merit.

 

------------------------------------------------------------------------

Fallout3.esm

PointLookout.esm

Anchorage.esm

ThePitt.esm

BrokenSteel.esm

Zeta.esm

HairPack.esm

RI_Core.esm

CRAFT.esm

CALIBR.esm

Mart's Mutant Mod.esm

Enhanced Weather - Rain and Snow.esm

Globaltravelsystem.esm

GTSEssentials.esm

COMM.esm

FEM.esm

Shojo Race.esm

DCInteriors_ComboEdition.esm

FNNCQ.esm

EZCompanion.esm

GTSCOMM.esp

GTSPointLookOut.esp

GTSThePitt.esp

MiniVaultWithScav.esp

DarNifiedUIF3.esp

Alternate Start - Roleplayers.esp

eyes_hairpack_en.esp

hair_add_npc.esp

FEM - BABE enabler.esp

FEM - DIMON enabler.esp

FEM - EXNEM enabler.esp

FEM - MALOS enabler.esp

TalkToAnybody.esp

CRAFT - Activation Perk.esp

CALIBRxMerchant.esp

GalaxyNewsRadio100[M].esp

UPP - Pack 1.esp

UPP - Pack 2.esp

UPP - Experience Perks.esp

Enhanced Weather - Rain and Snow in Fallout.esp

Enhanced Weather - Radioactive Rain and Snow Plugin.esp

Enhanced Weather - Weather Sounds in Interiors.esp

Enhanced Weather - Sneak Bonus during Storms.esp

PortableMattress.esp

The Prisoners.esp

Tailor Maid.esp

Binoculars and Scopes.esp

FF_PortableLabInfirmary.esp

FF_WonderMeatMaker.esp

RZW_PortableBearTraps.esp

RZW_PortableFans.esp

RZW_PortableLamps.esp

Tailor Maid Anchorage.esp

Tailor Maid Black Retex.esp

Tailor Maid PITT.esp

Tailor Maid Brokensteel.esp

Tailor Maid ZETA.esp

WeaponModKits.esp

WeaponModKits - OperationAnchorage.esp

WeaponModKits - ThePitt.esp

WeaponModKits - BrokenSteel.esp

WeaponModKits - PointLookout.esp

WeaponModKits - Zeta.esp

CALIBR Ammo Schematics - CRAFT.esp

TinCanCRAFTing.esp

Stealthboy Recon Armor - CRAFT.esp

RobCo Certified.esp

Mart's Mutant Mod.esp

Mart's Mutant Mod - DLC Anchorage.esp

Mart's Mutant Mod - DLC The Pitt.esp

Mart's Mutant Mod - DLC Broken Steel.esp

Mart's Mutant Mod - DLC Point Lookout.esp

Mart's Mutant Mod - DLC Zeta.esp

Mart's Mutant Mod - Hunting & Looting.esp

Mart's Mutant Mod - Natural Selection.esp

Mart's Mutant Mod - Tougher Traders.esp

Mart's Mutant Mod - Zones Respawn.esp

RI_Base3.esp

RI_CrippledEffects.esp

RI_PNeeds2S.esp

RI_Alcohol.esp

RI_LootTablePN.esp

RI_PNAnchorage.esp

RI_PNMMM.esp

ASU.esp

RI_LootTableRI.esp

nightvisiongogglesft.esp

Sprint Mod.esp

AutoAim_6000_v1.0.esp

K2_PlayWearClub_FEM.esp

1PipboyPDA.esp

CRBSOR.esp

EZ_MoreVoices.esp

EZ_TempleOfCant.esp

 

Total active plugins: 94

Total plugins: 128

------------------------------------------------------------------------

 

Basically i used to be a fervent user of Fallout Wanderer edition, but i kinda realised that this mod really isn't for me, there where a lot of things in it i liked, but a lot of things that are simply overkill/too hard for someone like me. On the other side, the vanilla fallout mechanics tend to be a bit too simplistic for my personal vision of wasteland survival.

So instead of loading a single monolythic mod and deal with the parts i'm not interested in, i'm doing the opposite and loading many small mods.

From my understanding, a large mod has a small chance to create a major conflict with any other loaded mod, while many smaller mods have a large change of creating only minor conflcits.

 

According to the G.E.C.K site, one has to see the elements of a mod like a card game where each mod lay it's own cards over 1 or more cards already present on the play field.

 

So from this definition i can assume:

-Mods loaded first have less chances to conflict but have more chance to get their functionalities overrided by another mod.

-Mods lodaded last have more chances to perform as designed but risk to break more things.

 

What the documentation doesn't say ( however i have never actually used the GECK so maybe i'm wrong ) is if the different entries of a mod are overrided at an unit level, or at an entry level, or what can be simply stacked aside of the original functionality for instance.

Example:

 

I use a simple mod that mark DogMeat as an essential NPC, obviously this mod goes into the NC definition of dogmeat and replace/change it's characteristic sheet, now if i where to use another mod that changes DogMeat's name to Lassie, will the two mods be able to work in conjunction with eachothers? if yes, will the order they are loaded in be important?

 

Some mods demand to be loaded first aparently, the reason, i guess is that instead of modifying certain objects, they REPLACE a core object with their own version, wich means that if another mod tries to modify the same object's behavior, i assume it won't have any effect because it will be modifying the inactive "branch".

This completely invert the load order rule i guesstimated before, making it critical for important mods to load FIRST to be sure they can replace the objects they need as early as possible.

 

I also have the feeling that ,for mods like DCInteriors, the load order has no relevance because those mods do not "modify" any content but create new interiors and doors to access them so, in theory they can't conflict with any existing content...

 

I think i'm lost LOL!

[aerialz]

Very thoughtful post :thumbsup:

 

So instead of loading a single monolythic mod and deal with the parts i'm not interested in, i'm doing the opposite and loading many small mods.

From my understanding, a large mod has a small chance to create a major conflict with any other loaded mod, while many smaller mods have a large change of creating only minor conflcits.

It generally depends on the content of the mod (scripts, textures, meshes etc.) may it be large or small, even a tiny mod of 5 kb size can cause tremendous conflicts if loaded in conjunction with a mod that changes or affects the same content.

 

I use a simple mod that mark DogMeat as an essential NPC, obviously this mod goes into the NC definition of dogmeat and replace/change it's characteristic sheet, now if i where to use another mod that changes DogMeat's name to Lassie, will the two mods be able to work in conjunction with eachothers? if yes, will the order they are loaded in be important?

To answer you question, those two mods will work in conjunction with each other flawlessly, and it does not matter which one is loaded first, as they don't override each others content. Note though, if you would use another mod that changes DogMeats name to Sparky, there will be conflicts if they are both activated. You mentioned you have never used the Geck before, so you can't know how incredibly easy it is to make these changes. Making a character essential just involves a tick in a box. Actually to make things more comfortable, you could just as well create a mod that makes DogMeat essential and renames it to Lassie.

[dieangel68]

Well i have no interest in renaming dogmeat, what i was wondering is that, from my understanding, the package system work like some kind of "diff" tool, where each new mod tells what it adds and what it changes, all the mods being somehow "applied" on runtime, what i do not know is how granular it is, is it down to the "field" level where i can have a tiny mod that just says "updated npc name is ..." and doesn't actually "replace" the datablock of said npc.

 

Obviously i don't thing it's granular to the point of allowing to modify a script on the fly, but for instance, if some object has a script tied to it's "on use" function and an addon "add" a new script to the same function, will it replace the old function or run alongside of it?

 

I know there are tools to detect conflicts in a load order, what i would like to know is ... myself basically how i can devise wich addon should be before/after what addon to maximise their compatibility.

 

From what i understand, stuffs like hair packs shouldn't matter in wich order their are loaded as it's creating new assets and modifying none (in theory), the same for most new locations, provided they are loaded after any package they may depend from.

 

 

Also, is there some kind of "crashlog" when fallout 3 becomes suddently unresponsive or simply crash to desktop? What exactly can cause the game engine to crash (in addons) that aparently isn't dealt with by the error handling system (missing models/textures do not cause catastrophic failures, for example).

[amcclell]

Well i have no interest in renaming dogmeat, what i was wondering is that, from my understanding, the package system work like some kind of "diff" tool, where each new mod tells what it adds and what it changes, all the mods being somehow "applied" on runtime, what i do not know is how granular it is, is it down to the "field" level where i can have a tiny mod that just says "updated npc name is ..." and doesn't actually "replace" the datablock of said npc.

 

Obviously i don't thing it's granular to the point of allowing to modify a script on the fly, but for instance, if some object has a script tied to it's "on use" function and an addon "add" a new script to the same function, will it replace the old function or run alongside of it?

 

I know there are tools to detect conflicts in a load order, what i would like to know is ... myself basically how i can devise wich addon should be before/after what addon to maximise their compatibility.

 

From what i understand, stuffs like hair packs shouldn't matter in wich order their are loaded as it's creating new assets and modifying none (in theory), the same for most new locations, provided they are loaded after any package they may depend from.

 

 

Also, is there some kind of "crashlog" when fallout 3 becomes suddently unresponsive or simply crash to desktop? What exactly can cause the game engine to crash (in addons) that aparently isn't dealt with by the error handling system (missing models/textures do not cause catastrophic failures, for example).

 

If you really want to understand exactly how the load order works, download FO3Edit. The entire purpose of FO3Edit is to allow you to merge/modify mods to eliminate conflicts, and so it's naturally got a lot of features related to rooting out conflicts and has a simple colour-coding system for overrides.

 

As a general idea, here's how the mod loading works:

 

-Everything in the game has a "Form ID", which is an 8 digit hex number that uniquely identifies that object. The first two digits identify which mod the object is from originally, while the last 6 are the object's ID within the mod.

-The first two digits of the mod are dynamic and dictated by load order. Fallout3.esm is always going to be 00-XXXXXX, and everything after that goes up sequentially (So 01-XXXXXX, 02-XXXXXX, etc)

-Objects which have the exact same form ID will conflict. Now, "Conflict" doesn't always mean "Bad". Overriding an object from the basic Fallout3.esm is technically a "Conflict", but it's usually intended behaviour.

-If an object is created new within a mod, it will use that mod's ID. Meanwhile, if an object is meant to override another mod, it will use that mod's ID. So, for example, if you create a brand new "beer" object in your 3rd loaded mod, it will have an ID of say, 03-123456, and not conflict with the "beer" object in Fallout3.esm. If, however, you design your beer as a modification of the one in Fallout.esm, it will share the Form ID from the master file, 00-015197, but only the one from your mod will be in-game (Because it's loaded after).

-Long story short, this means that any time you MODIFY an object, it will cause a conflict and override something from a previously loaded mod. If you were to say, reverse your load order, then your modifications would be overridden by the original because it would be loaded in afterwards. Meanwhile, any objects which are entirely new assets will NOT cause a conflict - but depending on how they're placed in the game world, may conflict with other mods which try to use the exact same container (This is extremely unlikely, though).

-This means that it is NOT granular down to the "field" level - though it depends a lot on which kind of object you're dealing with. Several objects have fields which are themselves other objects with their own Form IDs, and thus you can modify those objects without creating any conflicts regarding the top-level object they're being referenced by. A simple example is scripts - if an object calls a script on use, you can change that script as much as you want (At the editor level - once you're in-game everything is locked in) and the original object will still be considered "Unmodified" by the game.

 

So to answer your first question, it depends on how you "add" the script. There are a few ways to do it, which will all work differently with regards to conflict resolution:

-A quick primer on how item script calls works - there's basically 3 separate objects in play here. Item -> Base Effect -> Script. Modifications to one will not affect the other two, unless you change the references being made.

 

-If you modify the basic object (Say, a stimpak) by adding a new base effect which runs your new script, then both scripts will run when the object is used - but because you've modified stimpaks, it will conflict with any other mod which modifies stimpaks.

-If you replace the code within the script with your own script, then only the new script will run as it will override the version of the script from the previous mod, but stimpaks themselves will be unmodified and thus won't conflict with any other mods (Unless those mods remove the script call entirely from the object).

-If you make a brand new script and change the base effect that the stimpak references to call the new script instead of the old one, then the stimpak will only call your new script when you use it, but the old script will remain available and function as normal on any other objects which might reference it. Since "Base Effects" have their own form IDs, stimpaks will also be considered unmodified by this method (So long as you only changed the Base Effect itself - if you made it reference a different base effect, then stimpaks would be considered modified and cause conflicts with other mods).

-If you modify the old script to include both your new code AND the old code, then both will run simultaneously, but this will also apply to any other objects which reference that script, and will conflict with any mods that make changes to that script.

[dieangel68]

So it also depend how 'smart' the mod maker is making his mod, i guess you can make your mod in such a way that it's possible impact on the base systems is minimal, and make it's scripts so they are broad enough to handle some unexpected behaviors in what they will affect right?