Jump to content

The Load Order Question


jamRwoo

Recommended Posts

Greetings,

 

I realize this has been asked before, and I have read the "Modding for Dummies" as well as a variety of other resources, but I have come across conflicting information and I am still unsure as to how exactly the game handles "load order." The well-written readme for Improved Atmosphere says one thing, x posts says another, and y posts says yet another. Also, the modding for dummies wiki page actually doesn't breathe a word about this issue.

 

For the sake of brevity and hopefully clarity, I'll keep this short:

 

>> Do mods load in alphanumeric order or reverse alphanumeric order? So, if I have 1. Cool Mod and 2. Good Mod which one loads first?

 

>> Folders are always given priorities over files? So, \Override\1. Cool Mod\ will load before any files directly in \Override\?

 

>> Does the game always use the first file it has found and ignore the rest or does it use the last file it has found? So, assuming it's alphanumeric order (so 1. Cool Mod loads first), if 2. Good Mod contains (some of) the same files, will it override the files in 1. Cool Mod or will they just be ignored? My understanding is it will always use the last file, but others have stated it does not work this way.

 

Any assistance is greatly appreciated!

Link to comment
Share on other sites

I think it loads alphabetical, random. Never tried numbering mod load folders.

 

I think it will load from the in-game erfs and 'toolsetexport' folders first , then the add-ins folder, then the data folder, then the override folder, alphabetically.

 

I know that when 'Arcane_Arts' stops working, I can get it back by putting a 'Z_' in front of the folder name so it will load last, and it will start working again. (Actually have that one twice, one in a exclamation point folder to load first and one in a 'ZZ_' folder to load last, along with 'Orgolove_Armageddon/Spellcasting,...I really like those mods).

 

I also know that marking a folder with a 'Z_' or even a 'ZZ_' is no guarantee for getting something to work, especially so with folders containing 'char_stage.are' files, but they will load last. Same with putting a ' ! ' in front of the folder name so it will load first. Actually, I've gotten some mods to work better by forcing them to load first in the override folder.

 

Trial and success or error.....

 

just my 2cents....

Edited by DwainDibley
Link to comment
Share on other sites

Ok, this gets a bit... complicated. So try to keep up boys and girls!

 

DwainDibley is correct that there are a few other "special" folders that get searched before it, (and the same basic process as described below applies to them as well) but for the most part players will be concerned with, and have control over, what's in their "\override" folder.

 

In simple terms, the Eclipse game engine is programmed to work like this:

 

 

1. Search for any needed files in the vanilla game installation folders. File Found? Great! Hold that path+filename in the "Use This" slot.

 

2. Search the game's installation path folders for one called "\override". (You noticed that there was such a folder under "\Program Folders\...\Dragon Age\..." right? No? No matter. Almost nothing ever uses that location anyway.) Is a needed file found there?

Great! Replace the one in the "Use This" slot with the new one.

 

3. Search in the player's profile folders for one called "\override". (Yeah, this is the one most mods are talking about.) Is a needed file found there?

Great! Replace the one in the "Use This" slot with the new one.

 

4. Search the first, (in alphanumeric order) first-level sub-folder of the "\override" folder. Is a needed file found there?

Great! Replace the one in the "Use This" slot with the new one.

 

5. Search any second-level sub-folders (in alphanumeric order) of that first-level sub-folder. Is a needed file found there?

Great! Replace the one in the "Use This" slot with the new one.

 

6. Rinse/Repeat for all sub-folders of that first-level sub-folder.

 

7. Search the NEXT (in alphanumeric order) first-level sub-folder of the "\override" folder. Is a needed file found there?

Great! Replace the one in the "Use This" slot with the new one.

 

8. Rinse/Repeat for as many sub-folders/levels as exist.

 

 

 

So you can see that if two or more mods have incorporated changes to the same files (ones with the exact same names, which isn't uncommon when changing the same elements of the game) which mod will be "active" depends on the specific folder/sub-folder naming employed BY THE PLAYER.

 

Since I place all the mods that go in my "\override" folder into their own sub-folders, (so I can easily keep track of what I installed and remove an entire mod at once if I want) and because I choose the names of those folders, I might have the exact same set of mods as someone else, but in my game some elements of some of them might not be the ones used in that other person's.

 

And "loading first" is the exact WRONG thing to do! a) Mods don't "load" (aren't read into memory to be used by the game) until the entire set has been processed; and b) It's the LAST one found with the needed filename that will be used!

 

SIDE NOTE: This is one of the reasons area transition times can get pretty long. All this searching/selecting/loading of files occurs at that point. The more mods, and the more complicated the folder structure, the longer it takes!

 

[sIDE NOTE 2: This is separate from the known issue with the memory leak that causes load times to creep upwards regardless, so that the longer you play the longer it takes! :pinch: ]

Link to comment
Share on other sites

Great info Faithful Kobold, now I get to fix all the errors I've created in my override folder! Thanks!

 

Just goes to show that, just because it works, doesn't necessarily mean it's right.

 

*Just wondering, I stripped all the UTCs from their respective mod folders and placed them all in one folder, deleting the duplicates, would that make it more efficient for the game or am I wasting my time doing that?

Edited by DwainDibley
Link to comment
Share on other sites

*Just wondering, I stripped all the UTCs from their respective mod folders and placed them all in one folder, deleting the duplicates, would that make it more efficient for the game or am I wasting my time doing that?

 

Sounds like it should be more efficient, but I don't know for sure.

 

I've never tried that approach since it would require me to keep a separate list of which files belong to which mods for when I want to remove one or more, (which happens frequently!)

Link to comment
Share on other sites

I also consolidated all the head morphs into folders for each race.

 

I figured that the *.utc,s and the *.mor,s were "On Call" items, if the game didn't need them for a specific area in the game, it didn't load them. Which would indicate that the actual mod that used them could be deleted, if need be, and the associated utc and mor files wouldn't be loaded.

 

Is that a wrong assumption?

 

I'm fixing to do all the *.uti,s that way also.

Link to comment
Share on other sites

I also consolidated all the head morphs into folders for each race.

 

I figured that the *.utc,s and the *.mor,s were "On Call" items, if the game didn't need them for a specific area in the game, it didn't load them. Which would indicate that the actual mod that used them could be deleted, if need be, and the associated utc and mor files wouldn't be loaded.

 

Is that a wrong assumption?

 

I'm fixing to do all the *.uti,s that way also.

 

The information in a UTC is 'baked' into the save the first time you enter the area where the NPC appears, and is resident in all further saves. Items (UTI files) work the same way, though to be honest I'm not sure whether they are locked in and always loaded when you initially enter the area or actually obtain them... MOR files, OTOH are (to use your terminology) 'on call', and not loaded unless required.

Link to comment
Share on other sites

 

I also consolidated all the head morphs into folders for each race.

 

I figured that the *.utc,s and the *.mor,s were "On Call" items, if the game didn't need them for a specific area in the game, it didn't load them. Which would indicate that the actual mod that used them could be deleted, if need be, and the associated utc and mor files wouldn't be loaded.

 

Is that a wrong assumption?

 

I'm fixing to do all the *.uti,s that way also.

 

The information in a UTC is 'baked' into the save the first time you enter the area where the NPC appears, and is resident in all further saves. Items (UTI files) work the same way, though to be honest I'm not sure whether they are locked in and always loaded when you initially enter the area or actually obtain them... MOR files, OTOH are (to use your terminology) 'on call', and not loaded unless required.

 

Yes well, I was under the impression that a NPC's UTC and UTI's were loaded when you entered an area only if there is a Call for the NPC, with its associated UTC and UTI's are required by either the game or the mod, does that mean that the associated UTCs and UTIs are resident in memory prior to the NPC's call into action, or are they loaded into memory when entering and unloaded from memory when exiting, letting the savegame keep them "On Call" for later use upon return? I know that you can delete NPCs from their respective areas within section 16001 of your savegame and they will not be there when you return to that area. This would indicate, to me anyway, that the NPC's and their associated UTCs and UTIs do not stay resident in memory and are loaded only when that are called by the game or the mod. I once deleted all the NPCs from the market district in one of my saved games and when I returned to the market, it was a ghost town, not an NPC to be found...

Edited by DwainDibley
Link to comment
Share on other sites

 

 

I also consolidated all the head morphs into folders for each race.

 

I figured that the *.utc,s and the *.mor,s were "On Call" items, if the game didn't need them for a specific area in the game, it didn't load them. Which would indicate that the actual mod that used them could be deleted, if need be, and the associated utc and mor files wouldn't be loaded.

 

Is that a wrong assumption?

 

I'm fixing to do all the *.uti,s that way also.

 

The information in a UTC is 'baked' into the save the first time you enter the area where the NPC appears, and is resident in all further saves. Items (UTI files) work the same way, though to be honest I'm not sure whether they are locked in and always loaded when you initially enter the area or actually obtain them... MOR files, OTOH are (to use your terminology) 'on call', and not loaded unless required.

 

Yes well, I was under the impression that a NPC's UTC and UTI's were loaded when you entered an area only if there is a Call for the NPC, with its associated UTC and UTI's are required by either the game or the mod, does that mean that the associated UTCs and UTIs are resident in memory prior to the NPC's call into action, or are they loaded into memory when entering and unloaded from memory when exiting, letting the savegame keep them "On Call" for later use upon return? I know that you can delete NPCs from their respective areas within section 16001 of your savegame and they will not be there when you return to that area. This would indicate, to me anyway, that the NPC's and their associated UTCs and UTIs do not stay resident in memory and are loaded only when that are called by the game or the mod. I once deleted all the NPCs from the market district in one of my saved games and when I returned to the market, it was a ghost town, not an NPC to be found...

 

 

You edited the save to remove them, so of course the information wasn't resident. On the other hand... don't touch the save? The game remembers the information that was added the first time you entered that area, even if you've replaced the UTC with a different one. *obvious thing is obvious*

Edited by theskymoves
Link to comment
Share on other sites

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...