Mods using self named asset folders and merging.

[Dubbyk]

OK so mod's that have folder set ups like this: X:\SteamLibrary\steamapps\common\Fallout 4\Data\Sound\Voice\MODNAMEHERE

 

If you rename or merge a plug in do you need to change the folder path? Seems to effect VOICE and ANIMATION files the most, Meshes and Textures seem to almost always work when I merge plugins but then again I am normally building a custom BA2 file for the new merged plug in.

 

Will I get the voice files working again if I folder path to something like this: X:\SteamLibrary\steamapps\common\Fallout 4\Data\Sound\Voice\MERGEDMODNAMEHERE ?

 

Or is this folder path some how hard coded into the .ESP when it's made, and I would need to go into the .ESP and change the file path for each file?

 

 

 

*edit I've also been keeping voice files out of my BA2 because I have heard the compression of BA2 files messes them up. Not sure if that extra info helps.

Edited September 8, 2018 by Dubbyk

[MissingMeshTV]

 

Or is this folder path some how hard coded into the .ESP when it's made, and I would need to go into the .ESP and change the file path for each file?

 

Short answer: Yes.

 

You would need to open each .esp and look at all of the actual assets of the mod(s) involved. If a voice file, mesh, texture, material file or any other asset is referenced using a file path different than the “vanilla” path then you would need to change the paths of all the affected assets. If you just move the assets to another folder the game is still going to look for them in the original location because the file paths defined in the .esp tells it to. If a mesh is defined in the .esp to be read from Meshes/SetDressing/MODNAME/NewCookingPot.nif and you move that mesh someplace else without changing the path in the .esp, the game can't read it. This applies to all such assets, including any material swaps defined in the mod if they reference a "custom" file path.

 

Not sure what you’re hoping to gain as it seems more trouble than it’s worth if you’re only looking to save a load order slot or two. If you’re determined to merge these mods, why not take the path of least resistance and go the other way around: merge mods with the vanilla file path structure into one with a custom structure? That way you don’t need to muck around with changing file paths. Otherwise it seems to be a whole lot of hassle for minimal benefits, but that’s just me.

 

Sound files can not be put into compressed archives as they will not play. That’s why the vanilla game has it’s own separate Sounds archive. You should be able to create an uncompressed Sounds archive for the mod and give it the proper naming to match the .esp: MyMod – Sounds.BA2.

 

If you’re not already using the Archive2 tool that’s bundled with the Creation Kit, I’d suggest switching over to it. It’s the best tool for this sort of work.

[Dubbyk]

Yes I use the BA2 tool quite a lot. I Tested my theory last night on my ArmorMerge2.esp file, within this merge is "Eli's Armour Compendium", that mod contains custom voice acting for her shop NPC. The voice files are in a self named folder like I describe above. Without changing the folder name the NPC was mute and the conversation is glitchy. So I went and renamed the file path from:

 

X:\SteamLibrary\steamapps\common\Fallout 4\Data\Sound\Voice\Eli_Armour_Compendium.esp

 

to

X:\SteamLibrary\steamapps\common\Fallout 4\Data\Sound\Voice\Armormerge2.esp and it worked. The NPC is now fully voice acted again. I will need to test more to see if this fixes the issues with animations that are in self named folders as well.

 

This leads me to a new question now: If you use the self named folder system, and it's so easily broken by merging or ESL conversion, why use it? Why not just have your files load like this:

 

X:\SteamLibrary\steamapps\common\Fallout 4\Data\Sound\Voice

 

and leave out the .ESP specific folder altogether? I've seen bunches of other mods that use loose file just place their assets into the main folders and they merge / ESL convert no issues. So is their some advantage to using .ESP specific folder names I am missing?

 

 

*edit oh and in regard to your question about why I am going through all this effort monkeying with file paths ect, it's not just to save a FEW .ESP slots, it's to save a great many. Using my ArmorMege2.esp for example. I have over 50 armor and power armor related mods merged saving me upwards of 70ish .ESP slots. And about 5-6 of them off the top of my head have some sort of folder specific files, seemly mostly voice files. Using the renaming tactic I talked about above I was also able to get the ambient music and radio transmissions from several of the power armor mods to play again.

[MissingMeshTV]

 

This leads me to a new question now: If you use the self named folder system, and it's so easily broken by merging or ESL conversion, why use it?

 

Mod authors who create loads (ie: dozens or hundreds) of custom assets (myself included) find file management easier by keeping assets in custom directories for development, especially if those assets are used across multiple mods.

 

One use case would be: if you use assets from other people and put the assets of each author into custom folders, it makes it easier to keep track of whose assets you're using and who you need to give credit to.

 

Custom file paths also eliminate the potential for conflicts if by chance a file has the same filename as a vanilla asset or something from another mod. That's why I don't think adding custom assets into the vanilla file structure is a good idea, unless that asset is replacing something vanilla such as a texture replacer.

 

And to be honest, having the files paths "broken" by someone wanting to merge mods isn't really something that gets taken into account in development. Things only get "broken" if someone tries to "fix" them. :wink:

 

In the case of your voice file path example you posted (thanks for that...clears up another question I was going to ask), my guess as to why it has the specific folder named for the mod is because that's how the Creation Kit generates them. It does the same thing with FaceGenData if you create a new NPC or if you generate precombine and previs data for a cell. Anything that is part of a custom cell (or actor in your case) gets put into it's own folder named for the mod. In the case of precombines/previs, new data for vanilla worldspace locations gets put into a folder named for the appropriate master file (base game, DLC). Data for a custom created cells gets put into a folder named for the .esp. The author has no choice in the matter.

 

The game is probably hard coded for this as the mod author has no option for saving when generating any of this data. Vanilla assets have a similar structure except the folders are named for the master file (plus separate folder for each DLC)...it's just how it works. I'm actually glad it does this because again, it comes down to good file management that makes it easier to track things down during mod development.

 

Lastly, ESL conversion doesn't touch file paths, it only compresses the number of records in the file. If a mod gets broken by .esl conversion, any custom file paths the mod has aren't going to be the cause.