So I'm working on the next forthcoming release of SDR (Sneaking Detection Recalibrated), and am trying to decide how to handle various elements. It's been almost a year since I've modded/played the game, so I'm really rusty and I am second guessing some of my decisions.

I don't want to go back and do things later, so I wanted to explain what I was thinking of doing and try and get a sense of the pros and cons.

Switching to a BSA format:

I don't have a lot of support files, per se. Certainly not at the same level as things like quests or other mods that add a lot of content. However, I have a total of around 162 files. 130 of which are shaders, 13 are textues, and the rest are .esps, .esms, OBSE .dlls and documentation. Although my recommendation is that people use Wrye Bash, or at the very least OBMM, I know there are folks that use the Nexus mod manager or manually install it. Uninstalling SDR can be a real pain. This is especially true when it comes to documenting how to do it because there are so many files. My thought was that this time around I should just put all the textures and shaders in a single BSA file. All of the files are unique to SDR, so unless someone specifically intends to overwrite one of the files, there shouldn't be any conflicts. From what I've read, it seems like Wrye Bash and OBMM should be able to handle the BSA fine, and anyone who is manually installing it needs to use Archive invalidation. Creating the archive might be a bit tricky, not sure.

I'm somewhat concerned about some of the things I've read though. For example, one thing I read was that BSAs can only be read by .esps. That implies that .esms can't, and my core file is an esm. It also talks about how BSA is recognized using certain naming conventions. If that is true I may have to rename my files accordingly, which is fine. But I want to make sure it's necessary.


Speaking of files:

Another thing I'm struggling with is building my .esm around certain OBSE .dlls. There are a number of features that are optional. Some of the needed .dlls are included with SDR's installation package. Others need to be download from elsewhere. Up until this last round of programming, anything that was used by a .dll was put in a sub-script that would get called if the OBSE plugin was installed. This meant I had to have all the OBSE plugins installed all the time (except for OBME) which would get really annoying if I forgot to install one and tried to recompile or if I had to swap things in/out for testing various installation combos.


So this time around I decided to extract those sub-scripts into separate .esps that just modify those scripts to use the plugin. The patches can be merged with Wrye Bash's bashed patch. However, they take up space for OBMM and manual installs. Although it's been very helpful for programming, I am debating how useful this set up is for actual modders. Would you prefer/recommend just having as much as possible in the main .esm and as little as possible in the patches, or is it okay to have all these one-off patches that can be merged into the bashed patch.

Looking forward to feedback.

I would suggest that you use separate ESPs which can be merged into the bash patch. Those who do not use Wrye Bash will still be able to use them, they just will have more active ESM/P files than necessary.

OBMM, Wrye Bash and NMM can all handle installing BSA archives, my personal preference is no BSAs at all (I extract every mod-added BSA and install the files loose) however that's just me, it would be wisest to use a BSA for simplicity.

A BSA will only be read by the game if there is an active ESP matching the filename (ESMs cannot be used to load BSAs in-game, only ESPs). So one ESP will be required in any installation of the mod - it can be a dummy ESP if you wish, containing no records. The BSA must have either exactly the same filename as the ESP, or it must begin with the ESP's filename then contain a dash and a suffix of your choice - for example:

SDR.esp

SDR.bsa

SDR - Textures.bsa

SDR - Sounds.bsa

I use http://www.nexusmods.com/oblivion/mods/41042/ to create BSAs and to extract them, and the modder consensus is to use maximum compression for optimal reading by the game.

We used to be able to load .bsa files via the Oblivion.ini. Is that not possible anymore?

If you're loading the mod anyway there's no reason to do that.

***

For ease of use I'd recommend a .bsa, unless the assets you're providing are small in number or you need to override vanilla assets.

The mod is an .esm. As I understand his opening post, he would like to avoid having to create a special .esp solely for the purposes of loading a .bsa. That is why I asked.

It's a fair point. But I think I have an idea that would work. I would just have to rename existing files and redo the installer package.

Currently I have

00 Core

01 Oblivion

01 Nehrim

00 Core has SDR.esm.

01 Oblivion has SDR_Oblivion.esp

01 Nehrim has SDR_Nehrim.esp

SDR_Oblivion.esp and SDR_Nehrim.esp can't be run at the same time. At the moment they are designed to be merge-able into the bashed patch, since they currently just override existing settings in Oblvion.esm/Nehrim.esm. But if I just rename them to sdr.esp, then the sdr.bsa would be loaded. However, I'm not sure if they could be merged into the bashed patch anymore.

The other option is to convert sdr.esm into sdr.esp. As "cool" as sdr.esm is conceptually, the reality is that it probably isn't necessary. There are very few mods that use it as a master or even look for it other than the ones I maintain. It might shake up the load order a bit, but it's very much a stand-alone kind of thing. If I did that, then the sdr.bsa would load, and SDR_Oblivion.esp and SDR_Nehrim.esp could be left as is and be merged into the bashed patch.

There is a way to load a mod via the Oblviion.ini and archive invalidation.

One thing I'm not sure about is whether or not other esps can see the files in the sdr.bsa. For example, if the custom spell icons are in the SDR.bsa, will the SDR_Custom_Spell_Icons.esp be able to see the files?

You never want to include that requirement in your installation instructions, too many people won't read the readme, won't edit the INI, and won't see any of the resource files in game, then will complain to saebel that the mod is broken (because they didn't read the readme).

If you rename the existing ESPs, then you will need to add the bash tag {{BASH:NoMerge}} to prevent merging, otherwise when creating the bash patch they will be merged and disabled, and thus will not be active for the game to read and find the BSA. I also found with Better Cities that Wrye Bash was not correctly identifying this bash tag and merging anyway (they may have fixed this since?) so to ensure the Better Cities ESP didn't get merged and disabled, I added a record into it which bashing cannot handle, thus preventing merging.

As long as an ESP is active to match the filename and load the BSA, then any other ESM/Ps in use which use the same resources will find and use the content of that BSA.

If the ESPs are dependent on the ESM, then if you convert the ESM to an ESP, you will also need to update the ESPs to change their master lists. This can be done using Wrye Bash or TES4Edit. After doing so, if you then need to edit the ESPs in the Construction Set, then make sure you are using Construction Set Extended by shadeMe otherwise the ESPs will break their master list (unless you first ESMify the master ESP using Wrye Bash or TES4Edit).

Personally, I'd prefer loose files. I already use a nighteye shader mod, so I'd have no use for yours (no offense) - a BSA would just take up unnecessary space for me. The beauty of loose files with a BAIN/OMOD/NMM format is that the user can install only those things (s)he wants, not the entire thing.

OTOH, people these days are stupid, and they tend to not read the documentation. A BSA would be easier to install, and those of use who have no use for all the extra files can just remove them and repack it.

One thing that has also been on my mind is the issue of the new magic spells. Every so often, when I do major upgrade, there is no choice but for folks to do a clean save without SDR installed and active. The BIG drawback to that is that anyone who was using any of SDR's spells will immediately lose them. Then there is the hassle of going through a special menu where in order to restore the spells or looking them up and manually adding them back to the character. Let alone all the NPCs who may, or may not, have been assigned spells. This also applies to tomes, magic items, etc.

So one thought I had was to split up the sdr.esm into an sdr.esm and a sdr.esp. The sdr.esm would be the core "fixed" structure. It would contain all the spells, magic items, etc. The sdr.esp would deal with all the game mechanics issues: tokens, custom actor values, calling the detection formula, etc. That way, if there is a major update to the sdr.esp, people could uninstall just that mod and save the game with sdr.esm still installed. Then they wouldn't lose any of their spells/loot. If I do that, then there would be an sdr.esp that could be assigned to the sdr.bsa that couldn't be merged.

That assumes I'm still going the .bsa route. Haven't decide yet on that one.

Yes, that would work well. With Better Cities when we release a new update it is rare that a clean save is needed, however when issues do arise which may be resolved with a clean save, users only need disable the BC ESPs, keeping the ESM active in the clean save, so that quest progress and acquired items, or stored gold in the bank is not lost, while the cities themselves all get a reset.

Well, I have partial success. I managed to separate out the SDR.esp from the SDR.esm. Seems to be working. Created a SDR.bsa from the textures and shaders, and the game recognized it. However, although the textures are showing up (such as for spell icons), the shaders aren't being implemented. So either scanti's plugin only looks for loose files, or I've overlooked something.

More to report later.

So here is what I have discovered:
1. I can't compress shaders into a .bsa. Scanti's plugin doesn't see them. They have to be loose files because the plugin is looking specifically for the shaders/nighteye path.
2. The shader files themselves take up very little space. Around 42.2 KB
3. The remaining texture files add up to 420 KB, but compress down to 160 KB when archived to a bsa file. There aren't very many texture files: 1 quest icon, 3 spell icons, and 9 detect life magic effect textures.

The detect life textures are standard and aren't optional in terms of installing the mod. Not unless I go the route of pulling it out of the main mod like I did with some of the others (hrrmmmm - is there a demand for that? Honestly, all anyone has to do is disable it if there is another mod that handles the same thing, but I suppose I would be open to splitting it out if I could be sure to find a way to make it mergeable - I'd have to create a version for Nehrim and Oblivion though, since I would have to override their default detect life shader. not looking forward to that. I can script it instead of overwriting it, but it's ugly.).

The quest icon isn't optional either because there are some weird issues with the bashed patch and missing quest icons.

That leaves the three custom spell icons. They would only be used under two conditions:
1. if you install the custom spell icons plugin and associated patch.
2. if you install the SDR OBME Additions add on.
Up until this version, I was always installing the custom spell icons as part of the default core package anyway, since I couldn't determine which way a user would go with their installation choices. So I could either create a .bsa that has the spell icons in them, or separate them out and include one copy in the custom spell icons installer and another in the SDR OBME Additions installer.

Creating a SDR.bsa will absolutely make uninstalling SDR manually a lot easier. Instead of having to look up the various folder paths of the icons, they would only have to delete the SDR.bsa. They would still have to manually remove the shader files, but those are fairly easy to find compared to the others.

It seems to me that since the overall file size of the SDR.bsa is small, I think that overall it will be more useful if I include it than not. The shader files will have to be installed separately, but that will make WalkerInShadows happy anyway.

Walker's like me, he'll probably extract the textures from the BSA before installing. Sounds like you don't really have enough resource files to bother with a BSA, but it's whatever suits you rather than anyone else.

I don't understand how another ESP could fail to use the content of the BSA if sdr.esp is active. As long as sdr.esp is active then the game will load the content of the BSA into memory, whether the content gets used by any mod or not.

I have decided on what my file/installation structure is going to be. (you can check it out in the SDR thread).

With all the variations, having a bsa doesn't make sense, so I've decided not to go that route.

Thanks for all of the advice! It's much appreciated, and I learned a lot about the BSA archiving process.