Load Order questions.

[pmmurphy]

Ok i am brand new to modding. I downloaded some mods for fallout 3 and i am using them. I downloaded BOSS and it organized everything, i have programming expierence and i use NMM as my manager. I noticed that files that are reguarded as .esm or .esp files are particular restrictions in the load order in NMM. Most likely the programmers have very good reasons for this or else i wouldn't have issues there. I also don't need to understand the technical reasons and have no questions behind that.

 

Well basically i picked up on a few things. The plug-ins my guess is they bring your mods into the game itself using the files and so on and so forth. So the order of the plugins is obviously very important as some mods may alter things in conflicting ways. My guess is that if plugins have conflicting orders, it depends on which mod you want to overtake the other. (i might or might not be right here).

 

If you can enlighten me on that and correct me if im right or wrong i would like that.

 

Next, what is the difference between esm and esp files? Why are esm files at the top of the load order with esp files on the bottom. Why do some mods flag esm files as esp? When i switch the wrongfully modded files back to esm's i get errors, why? (i need to retest the errors i had other reasons for them too.)

 

If i rename a esp into an esm will that allow me to put an esp higher in the load order in NMM? Are there mods where i would need to do this?

 

If a mod only modifies creatures where another mod modifies perks why do i have to put the perk plug-in's before MMM in the load order? Does MMM give monsters the same perks as us?

 

If i make a mod myself what is a debugging process that is reliable for discovering a efficient load order?

 

Why do some mods only have esp files while other mods have esp and esm files. If a mod only has a esp file why does NMM STILL restrict the load order and not allow me to put it above esm's?

 

That is all my questions for now. I may have more.

 

 

[prensa]

pmmurphy - Hello!

 

I can answer some of those. :)

 

"The plug-ins my guess is they bring your mods into the game itself using the files and so on and so forth."

 

Yes, .esm's & ,esp's contain all the written data for mods, the scripts, messages, perks, navmesh, object & land placment, NPC's, etc. while the textures & meshes & sounds are the models & their skins & sound files.

 

"So the order of the plugins is obviously very important as some mods may alter things in conflicting ways. My guess is that if plugins have conflicting orders, it depends on which mod you want to overtake the other."

 

You got it, there's a simple general rule to follow - what loads last wins.

 

Added to that .esm's always load before .esp's.

 

Got two mods that add a modified Chinese pistol? The one that loads below the other will get it's version into the game.

 

"Next, what is the difference between esm and esp files? Why are esm files at the top of the load order with esp files on the bottom. Why do some mods flag esm files as esp?"

 

An .esm is a Master file & an .esp is a Plugin file.

 

The difference between them can often be very little but significant.

 

Generally an .esm is used to store all the core things in a mod. Other .esp's can call on things listed in an .esm & play with them.

 

When people want their mod to be useable some of their plugins or by others as a resource they make it an .esm because of this.

 

The .esm has some other advantages, there's a navmesh bug that means .esp's navmesh can be faulty whereas changing the mod to a .esm fixes the issue. Another bug means NPC's added by .esp's have mismatched color between heads & bodies.

 

The .esp is used to make changes to an .esm or manipulate it's assets.

 

For example, you make a mod that adds zombies & place all their data in an .esm.

 

You want to offer the player a choice of zombies, some with big afro's, so you provide an additional .esp that modifies the basic .esm zombies to have afros.

 

Tha AfroZombie.esp will load below the Zombie.esm & make that change.

 

Whether to use an .esm or .esp depends on what you need your mod to do & how that relates to the above mentioned capabilities & limitations of each.

 

Also all mods start off as .esp's as GECK only allows the editing of .esp's & not .ems's.

 

If you want to make a mod an .esm it needs to be converted once you're done editing in GECK.

 

There's a more detailed description of what I've discussed here:

 

http://geck.bethsoft.com/index.php/Category:Data_Files

 

"If i rename a esp into an esm will that allow me to put an esp higher in the load order in NMM?"

 

It would be a terrible idea, there's more of a difference between .esm's & .esp's than the extension. :)

 

A true .esm, as well as the different extension, has something called ONAM records that are override logs for it's added items. An .esp that's just flagged an .esm has no ONAM records & so really is not a Master file, it's only pretending to be one.

 

"Are there mods where i would need to do this?"

 

No, all properly made mods should ship as .esm's or .esp's as required.

 

Occasionally some mods may specify that they can be changed from one to the other but it's rare.

 

Having said that, back in the early days there where a few bugs that where unknown/not understood like NPC's having mismatched color heads & bodies that happens when added by .esp's instead of .esm's.

 

In those cases FO3Edit was used in special masterupdate function to "convert" the .esp's to .esm's, it's not a real conversion but allowed the affected mods to function properly.

 

Mod managers tend to display a Warning about the mod being flagged an .esm while having an .esp extension.

 

There's still a few older mods out there that need that trick but it should be used sparingly as changing .esp's to .esm's by just flagging them can cause problems.

 

"If i make a mod myself what is a debugging process that is reliable for discovering a efficient load order?"

 

FO3Edit is the handiest tool for checking how mods conflict/interact with each other:

 

http://fallout3.nexusmods.com/mods/637/?

 

With that great tool you can load up your mods & quickly see what changes they are making to the Fallout3.esm & other mods.

 

You can also make a Merged Patch with FO3Edit.

 

A merged patch is an attempt to combine the properties of several mods & allow them to work together rather then overwrite each other's changes.

 

It's quick & easy to do, you need the above mentioned FO3Edit.

 

1 - Run FO3 Edit, a list of all your mods will come up, make sure all mods that you use are ticked, click ok & wait 'till it's ready.

 

2 - Anywhere on the list of your Mods on the left, right click & select "Create Merged Patch".

FO3 Edit will ask you to name it, I recommend you call it:

 

Merged Patch

 

3 - Close FO3 Edit, it will ask you if you want to save the changes & list "Merged Patch". Click OK.

 

4 - Open your mod manager & tick Merged Patch, ensure it is at the very bottom of your load order.

 

Remember that every time you add a new mod you will have to delete your old Merged Patch & create a new one (That's why I always call it Merged Patch, Fallout 3 never thinks anything is missing that way).

 

The process only takes a few minutes & can really help make numerous mods play nice together.

 

"That is all my questions for now."

 

Phew!

 

" I may have more."

 

Blimey! :)

 

Hope this helps!

 

Prensa

Edited May 11, 2013 by prensa

[pmmurphy]

Ok thanks. I think im gonna give a merged patch a whirl after i do some other things. But i feel like creating a merged patch can create performance issues and possibly more errors. I may be wrong though.

 

Right now i am just toying with mods and testing to see how they work and so on and so forth. I still get crashes in my game but i am slowly improving the gameplay. I found another mod that might help with the crashes and i want to test it out before i attempt a merged patch.

[prensa]

pmmurphy - Hello!

 

"But i feel like creating a merged patch can create performance issues and possibly more errors."

 

No performance issues will result from a Merged patch.

 

It just takes information from one mod & combines it with the information of another that's changing the same item in an attempt to combine both changes (providing they don't change the exact same setting).

 

It is an automated process so it is not fool proof, on rare occasions a Merged Patch can combine something that you'd rather have left out.

 

In time, when you learn to use FO3Edit a bit, you can edit your Merged Patch & remove any unwanted data if such a conflict arises.

 

More often than not though a Merged Patch brings harmony to conflicting mods. :)

 

It's also easily deleted if you find it unhelpful.

 

Prensa

[pmmurphy]

This is all i needed to know about merged patches. I was afraid it might alter core elements of the game to the point i might have to reinstall.

 

pmmurphy - Hello!

 

 

 

It's also easily deleted if you find it unhelpful.

[pmmurphy]

Also i found a mod that extends the .ini file. But you have to use another (automated software) to convert all the mods to the new ini.

 

I want to use it but i am skeptical of if it is truly a better option or not. I forget the url for the mod but that is easily retrieveable.

 

It's just i don't like tinkering with something that already works unless the people who programmed it programmed my ability to tinker. So if i do edit something, i want to use the tools given and the same files as the creator. As they more than likely understand the technical issues better than outsiders since they debugged and created the source code themselves.

 

That is why i was skeptical about merged patches aswell.

 

I am certain the people who make these programs are brilliant. But not being able to see source code of know all the technical development issues there are highly limits what your capable of doing.

[prensa]

pmmurphy - Hello!

 

"Also i found a mod that extends the .ini file. But you have to use another (automated software) to convert all the mods to the new ini."

 

I've never used an .ini extension & so have no experience of using one.

 

I use the multi core bug fix in my .ini & a few other select tweaks & that's about it. I've found keeping the .ini close to vanilla is best for my set up.

 

There is a great guide for tweaking .ini's here:

 

http://www.tweakguides.com/Fallout3_1.html

 

Though my advice would be to only make tweaks if you feel something is not right in game, trying to push the .ini too far can result in more trouble than good.

 

"That is why i was skeptical about merged patches aswell."

 

Merged patches are very safe & pretty basic in what they do.

 

Imagine you have a mod that adds increased damage rating to the Radiation suit.

 

You also have a mod that adds a higher price to the Radiation suit.

 

Normally only the mod that loaded last would get it's changes in game, with a Merged Patch both damage & cost get combined into the merged patch allowing both mod's changes to work.

 

You can view exactly what the Merged patch contains after making it by viewing it as if it were any other mod in FO3Edit.

 

You can even chop & change what's contained in it if need be.

 

You often get patches for mods to work with other mods, think of a Merged Patch as a custom patch made specifically for your load order.

 

The Merged patch is a self contained file, no changes are made to any mods or vanilla files.

 

Untick & delete the Merged Patch & all returns to exactly as it was before.

 

Hope this helps!

 

Prensa