Fantastic, and extremely useful. Thanks for the testing you've done here, and the plans for Wrye which will definitely help. I love your plans - can't wait to see them! Especially the first one - I'd rather have some extra processing power used in BAIN than all the conflicts and issues associated with the bsa's.

Sure, in the technical programmed aspect of it what you've said is correct - the game doesn't ACTUALLY load up each and every BSA, each and every file (just loading the Vanilla assets would take over 5GB). It's just easier to understand if you think of it they way I explained (at least in my opinion). When I realized how big of an issue this is, I decided to write it so hopefully anyone, even someone brand new to modding, can understand it.

OK -- just was wondering also when you did the testing on the map dds did you completely exit the game before each test -- I ask because if not it might distort your results as sometimes the texture from the previous test might still exist in RAM and the game would then use it instead of actually looking for the texture !

Yep, completely exited each time, to be sure.

Cool -- Thanks for taking the time to test all of this and for the results ! -- Does bring up some interesting things that will be causing even more headaches for the SW and the way it is set up as time passes and users begin using more and more mods -- can see now why they are limiting subscribing to only 50 mods instead of closer to the 253 mod limit as auto updating is really going to become a major thing if something isn't changed and the bandwidth required for keeping all of those BSA files updated each time a single file is changed inside them (ie. just like the first DLC and all the packing errors it has is going to mean every user will be redownloading 3+ GB of files with each fix released)

Personally I have always just unpacked all the BSA's so that I know what file is going to load since only the one I place into my install folder exists in the game install !

Thanks very much for the research and info !

However...
This puzzles me. Why do people want what they see to be separated from what changes to the game are made? Surely it's more likely to be the case that people will simply want to know which of their mods overrides which other, rather than which part of which of their mod overrides which part of which other?

Can you give an example of why decoupled Install and Load orders are desirable, so I can understand? Thanks.

Is there any way to create a .bsa outside of the CK's archive function? I get an error whenever I use the archive function and therefor cannot upload my mod to the SW.

For instance, you have a mod that adds new creatures and modifies the stats of existing ones. You have another mod that modifies the same creatures in visuals and stats but you only want the visuals of the last one but the stats of the first one. The way things are now, you'd have to pick one or the other. By breaking it up, you can change the visuals as much as you want without worrying about the actual effect it'll have on the game itself. With load order, you have control over which stuff is changed. This way, you can customize the game as much as you want without worrying about trying to hunt down multiple things and dealing with many duplicates and so forth.

Hope that makes sense.

Thanks for this awesome post.


For version changes isn't it usual to put a version string in the plugin description? I though BOSS look there for that.

Plenty of reasons actually. I'll give an real world example from Oblivion:
You install the Unofficial Oblivion Patch. It comes with:

• An ESP with fixes to quests, NPC AI's, etc
  
• A bunch of textures, meshes, etc - fixing glitches like stretched textures (UV mapping issues), clipping, and so forth.

Normally, you'd have the Install Order of the UOP be very low (installs first), so you get its fixes, but other things like texture packs and stuff will still override it (so you still get eye candy).

You also have, say WEPON installed, which provides a bunch of fixes for weapons among other things, some of which are in the form of fixed meshes and textures. WEPON also has an ESP that changes the stats on a bunch of weapons as well. The mod does a lot more, but this is just for the example.

You want the fixes from the UOP, because you don't like some of the changes that WEPON makes to the items. However, WEPON has better fixed meshes and textures (in this example), so you want to use those. If you make Install Order and Load Order coupled, you can only choose one OR the other. Keeping them decoupled allows the data files from WEPON to load last (higher Install Order), while the plugin changes from the UOP to also load last (higher Load Order).

It doesn't happen a lot, but it is definitely something you want to be able to control.

pseudo-edit:


BSAopt (or DDSopt, or NIFopt). All will do some extra processing as well to help you save space, and make the BSA more efficient.

Yes, that's the best practice - although with a new game, we get new modders, who don't know the best practices yet

Are those programs a part of Wrye Bash or are they located elsewhere? Sorry.

No, they're elsewhere. They're on the OBGE site, which I'm having issues loading right now...

So when I apply Occam's razor (no, not the member here), I do the simplest of all things: I manage my BSAs via the .ini in parallel with the ESPs (namely: inverse date-sorted). Doesn't sound too complex, wish the Bash would do that automatically for me though.

http://skyrim.nexusmods.com/downloads/file.php?id=5755, http://skyrim.nexusmods.com/downloads/file.php?id=247

Yeah - only problem is the 255 character limit on the INI entries - you run out of room fast. That's why I won't recommend that method.

Unless you do my trick with 1 letter file-names. (Just make sure you keep a list of what's what. )

Doesn't bother me because it still is less error-prone and has less issues than any other solution.

Edit: I just say it this way because we know it can not stay like this and bug-fixes will be done. If no bug-fixes happen the entire endavour of the SW is fruitless and they can stop everything right now before the real damage (of perception) happens. Saying this I don't worry about the situation in a month (it will be fixed), and meanwhile I help myself with the .ini.

Thanks for this LoJack ... let's just hope gamesas make the loose files override again - or have an ini option to enable same...

Another problem with renaming plugins: if the mod adds voice entries, they're referenced by the plugin name. In Skyrim, for example, you have
"sound/voice/skyrim.esm/maleuniqueesbern/mqpaarthur_mqpaarthurnaxa1_00042849_1.fuz"
If you change the plugin name, it'll look in the wrong directory and skip the voice files.

Excellent information. Perhaps you could add it to the CK wiki?

I notice that the CK wiki recommends that modders don't change original base objects.

I guess that's feasible (at least for those of us who are merely adding content like new worldspaces) ?

In the Dragon Age community, we set up a register on the wiki of unique name prefixes for each modder, to reduce the risk of name conflicts. Would something like that make sense for Skyrim?

Of course, I appreciate that global change mods (e.g. changing castle textures) can't operate that way - but how many players will need more than one of those?

Name conflicts are reasonably unlikely for everything except .pex files, thanks to the fact that everyone ought to be using a couple of subfolders to keep things organized.

Editor ID conflicts are impossible since the game only uses FormIDs anyway.

I've learned so much in this thread...thanks Lojack!!

Right, I see, thanks for the explanation . Personally, though, I think that any modder who wants that sort of fine control would be best off learning how to unpack archives into loose files, if they want to decouple them from the .esp. It's my belief that what Bethesda needs to do is provide the most sensible, straightforward system they can, so that people who never get into that level of mod use don't have to worry about the complications.

You have a point, but there is no increase in complexity for the average user: they'll be using a utility to manage their load order, which would also handle BSA load order as if they were linked, but then also allow those wanting more control to change them independently. It would only be a little more work for Beth (which they've got to do anyway, to fix the current system in some manner), but would translate into no more work into the average user, and no more work for programmers who would otherwise have to engineer some hack to get around a coupled system.

Eg. I proposed that BOSS would handle the BSA load order by giving BSAs the same date as the plugin they are linked to. This means that the average user can just run BOSS and sort both out at the same time, but then someone wanting more control could open up Wrye Bash and change the BSA load order there.

I'm still a little confused about the 255 character limite regarding the BSA loading... so for example... this is my bsa load order

[Archive]sResourceArchiveList=Skyrim - Misc.bsa, Skyrim - Shaders.bsa, Skyrim - Textures.bsa, HighResTexturePack01.bsa, HighResTexturePack02.bsa, Skyrim - Interface.bsa, Skyrim - Animations.bsa, Skyrim - Meshes.bsa, Skyrim - Sounds.bsasResourceArchiveList2=Skyrim - Voices.bsa, Skyrim - Voicesixtra.bsa

How do I actually count the characters? Only characters in their file names are added?
Is this BSA Load Order still good?

You have 205 characters in the first one, and 45 in the second one. You just count all characters after the =