Levionte

Using the story manager is an option, but it's kind of a pain to setup just for an outfit swap. You could also give the follower/alias an AI Package that changes the outfit whenever it's activated via time condition or whatever. While that does work, I've found it's not very dependable as they won't reevaluate their AI Package very often unless it's triggered directly. I would probably recommending using a perk that de/activates during whatever conditions you want. I did a variation of this on my Ciri follower if you want an example, but she changes her headgear / hair depending on the weather. It's been a long time since I've worked on it, but I believe I had originally gone with the AI Package approach, and then used a perk to reevaluate the package more timely as opposed to handling the outfit swapping itself.

Could also try using the Lazy Voice Finder tool.

That's what happens when the vertices on the mesh don't line up with the instructions on the TRI file. Chances are, either the vertex changed or their order did. You have to be really careful with 3DS Max, as I've found it sometimes changes the vertex count on export.

The original mod will have a mesh (either as a loose file or packed inside a .bsa) in data\meshes\actors\character\facegendata\facegeom\"PuginName.esp"\. Since you've merged the plugin, the name has presumably changed from Toccata.esp or whatever it was originally. You need to put that nif inside your new face geometry folder with the correct folder and nif name. Since you apparently "regenerated the face data," it should have created a new folder and mesh for you. You need to replace that mesh with the one that originally came with the mod. You should also do the same thing with the textures, but the regenerated ones may work if they weren't customized. You'll just have to see.

I don't use blender for that, but there are some tools out there. Granted, most of them have a bit of a learning curve. That being said, hair only uses the .tri file for the weight-slider, so that it doesn't clip when the body and neckline change. That's why most hair mods don't even bother with it. Many meshes either don't need it, or it's otherwise just easier to move the vertices to give it some space.

I'm having a problem with a custom cell I've made. Sometimes, but not every time, the objects in the cell will disappear and (sometimes) reappear depending on what camera angle they're being viewed from. Video here: It's a pretty simple cell. Those are meshes I made myself but they're just blocks. It might be important to note that all the meshes except for one (floor of the house) have nif-animations that are triggered via script. I've tried creating room boundaries around the whole area, even though it's probably too small to warrant it. I've adjusted the textures, tweaked settings in the Nif and everything else I could think of. The problem is not consistent. More often than not, everything displays perfectly fine. But, occasionally, objects will randomly disappear like the video shows. Which objects do it seems completely random. Any insight would be greatly appreciated. My googled answers are littered with people duplicating existing cells and not changing the room boundaries, which doesn't apply to me.

Oh, that kind of script. I'm not sure there's a great way to do it. You can open up the marriage quest in the CK and check out their scenes, but it may be a bit chaotic to look at. There are tools like BML's lazy voice finder that might be able to do it, but I've never used it for that purpose.

So, dialogue is all based on conditions, right? You're going to put in a "hello" line for your follower, and if you don't have any conditions on it then every npc and their dog will try to say it (and most will fail). So you put conditions on it: only npcs that are female can say this line, only npcs with this specific voice type can say this line, only this one khajit npc can say this line, etc.. The conditions can be whatever you want, but you're going to add some to limit who can say your custom lines. You can then add additional conditions based on certain situations: don't say "hello" if you're sneaking because that will give us away, don't say "hello" when we're friends because I want you to say "hello, friend" instead, etc. etc.. So, marriage dialogue is just another condition. The vanilla game, specifically, uses a Marriage Faction as the condition they check for. When the npc is not in the marriage faction she'll say "hello." When the npc is in the marriage faction she'll say "hello, husband" or whatever. Adding marriage to an npc is simply a matter of having a second set of things like dialogue and behavior that take affect when the "married" condition you've set is fulfilled. To take that npc from a state of being unmarried to one of being married, all you need is a way to make that npc fill the requirement. In the case of the vanilla quest, you add the npc to the marriage faction. The only respectable way to change things like an npc's factions is through script. You can put that script on anything you want. You can make a spell that does it when you cast on her, or a book that does it when you read it, or whatever you want. Most commonly, though, people tend to make it a later stage of some sort of marriage quest. I don't know of any way to hijack the vanilla quest with a new voice type without compatibility repercussions, which means you'd likely have to create your own version of the quest. To learn how to do this, I would suggest watching tutorials on making a quest in general - specifically how to setup stages and scenes. The camera in the CK sucks and will always suck. I used to have some success rotating left and right or up and down and then adjusting the zoom to get different angles and close-ups on things. But it mostly just sucks. For npcs with custom faces, I'd personally recommend the Nifmerge method. Skyla does a pretty decent tutorial on how to set it up. Plus-side is you don't need to worry about what she looks like in the ck render window. As you've noted, you can set outfits in the Inventory tab of the Actor entry. Beneath that should be a window in which you can right click > new item or add item or whatever it is, and then you can pick specific items from a drop-down menu that are not a part of the outfit. Should note that she won't actually wear items that aren't in her outfit until she's told to re-evaluate what she's wearing (like adding or removing items from her inventory). You can create a new outfit pretty easily. But if she's assigned an outfit, she'll do that thing vanilla npcs do where they may not wear items you give them via trade depending on how they compare to the items in her selected outfit.

In my experience, that type of method works fine in the very beginning but quickly outgrows your folder. As soon as you make your second mod, then you're working around your first assets - which isn't so bad. But then you make a mod that requires the MCM, or script extender, or FNIS, or bodyslide, etc., and now you have to put those in there in order to test properly. Now you're working around those, and you need to test if you conflict with another mod, so you drop that in there, too. It very quickly grows into a mess unless you're extremely diligent in your organization, at which point you're wasting a lot of time screwing with your folders. You're probably better off just packing and unpacking your mod into a zip archive to install through your mod manager over and over, but that gets really old. When I tweak a texture, I need to see it in action to know if I like it. It's not uncommon to tweak it 10-20 times in a couple minutes, which is a lot of packing and unpacking. Honestly, while the MO vs Nexus mod-manager debate has been argued ad nauseam and largely comes down to personal preference, I've found the benefits of having your assets isolated in their own folder, which you can test directly without having to pack it into any kind of archive, invaluable when it comes to mod creation. This is especially true when you start making more complicated mods that require files to be in separate folders all over the data folder. Before I switched to MO, trying to find all my mod assets to package them was something I actually dreaded, and almost always forgot something like a random texture I put in a different place, or one of the scripts which just go in a folder with every single script you have installed. I'm not saying an MO setup is perfect either. You have to jump through some hoops to get your scripts to compile, generate .lip files, broken preview in Nifskope, etc.. There are definitely some glaring issues. But once you get a system for working around those problems, I find the drawbacks to be less burdensome than the alternatives.

Ignoring for a moment how rude it is to try to hijack someone's project, you know you're not allowed to uploaded ported content without permission, right? I can't imagine the original creator of that mesh would ever screen shot it, much less upload it, with diffuse texture in the wrong format, and no normal, specular, environmental map, etc. to speak of. To be brutally honest, if I was the original creator of that mesh, I'd be more upset by the quality of the port than the breach of copyright.

I think the method you've described is probably the easiest to do. Put an OnEquipped script so that it equips the axe "spell" to the offhand, so that you can hit things with the right or throw with the left. Then you setup the magic effect as a simple destruction spell replacing the casting art, projectile, and probably the sound, plus any other magical effects you want. Getting it to return would be a little tougher. My first thought is maybe add a script to the magic effect to perform the spell in reverse after a second or two, sending it back to the player (obviously mitigating the damage). You might need to place an xMarker or static model of the axe at the firing spot to cast the spell if it doesn't hit anything or if the enemy dies or something. If you wanted to be clever, maybe put it on a second "recall" spell, that the player can trigger if that's a thing. I don't have a PS4, so I'm unfamiliar with the original mechanic. Cool axe, by the way.

Sorry this response is so delayed, but maybe it'll still be of some help. BSA is an archive. It's a collection of assets locked inside a digital safe that the game can read. Loose files, such as .dds, .nif, .pex, etc., take priority over those placed inside BSA archives. So, if texture.dds is packed within the Skyrim textures BSA, and a mod adds a loose "texture.dds" file into your game folder, the game will choose to load the loose file over the BSA. But that doesn't mean the archive isn't still there, and if you remove the mod and the loose file, the game will once again load from it. Moreover, a big part of why most modders recommend the use of a mod manager is that it won't permanently remove files, even if two mods try to add the same loose file. Mods can also pack their assets in a BSA, in which case the plugin with the highest priority (loaded last) will be loaded. I should also note, Mod Organizer can bend many of these rules if you tell it to. To answer your quest, yes it's usually safe to add and remove mesh and texture replacers. I'm not sure "dynamic" is the right word, but I think you get the general idea. Whether or not a mod is "script heavy" tends to be something noted by modders. You can write scripts to run repeatedly, and in the right circumstances that can be a volatile problem. That's pretty well-emphasized in most scripting discussions, and most people try to put in safeguards to keep bad things from happening if not avoid that type of script entirely. But it is something to be aware of. However, I would say the large majority of scripts run once when they're told to, change a state or a variable, and then don't do anything until they're called again. And if the mod is uninstalled then they simply don't get called again. The "dynamic" part is the fact that scripts are able to change game variables, and if you uninstall them then they may not get an opportunity to change the variables back. For example, if Lydia was a mod and I recruited her as a follower, if I uninstalled that mod before dismissing her then the game would think I still have a follower. So, until that variable gets reset, I won't be able to recruit anyone else. But, again, it's really a case-by-case circumstance. Many mods are completely self-contained and don't affect vanilla variables. Those are the file types. You could break it down further if you wanted to. Wav files work, but for bigger files like music you probably want to convert it to xwm for efficiency, or .fuz if it containts lip-sync data like speech. There are different types of dds formats depending on what you want or need from the texture (they're still labeled .dds). In addition to nifs, you can also have things like .TRI files that handle vertex manipulation. Etc. But you mentioned the big ones. This is another one of those things where it just depends on the circumstance. A lot of the time you can safely replace meshes and textures without even closing the game - just changing cells so the game reloads it. If the mod adds a player home, or a dungeon, or a cell that didn't exist in the vanilla game, you obviously don't want to uninstall the mod while you're in that cell or the game won't know where to put you. The game's cells do reset after a certain amount of time, but obviously not while you're in them. There are a few mods that take advantage of this feature in the uninstall process. It's always a good idea to understand why you're doing what you're doing, but most of the time you should be safe following the instructions. I suppose it should be a consideration whenever you uninstall a mod. However, while I know the people who developed those tools tried to make it as intuitive and user-friendly as possible, you can absolutely cause damage to your save if you use those tools the wrong way. That's why most of them make a backup of your save. Save bloating was a bigger deal back before we had so many tools to deal with it. If you run the game with SKSE, for example, it will automatically "debloat" your save to some extent as you're playing. If I were you, I'd just run it whenever I have a problem or find a reason to. Patches are usually a good candidate to merge. They're often relatively simple plugins. As you've noted, any updates or changes or removal of a mod you're patching will require you to redo it. That's why I mentioned weapons and outfits as they don't tend to get updated over time, and if they do it's often a change in the mesh or texture and not always the plugin. As you can tell, I don't like making generalities like "all weapons can be merged," since every mod is different. But, if it's a simple mod that just sticks a sword in a chest outside breezehome or makes you craft it, then yeah, you can probably merge it. Wryebash can also be used as a mod manager. I've never personally used it for that, but some do. NMM served me just fine as a mod user and I'm sure Vortex will be more of the same. I use Mod Organizer because the way it isolates individual mods is a tremendous help in mod development - which is mostly how I interact with the game. As a mod user, it's a little more powerful, but not as user friendly and can't achieve any results you couldn't also achieve in a different type of setup. When it comes to those three, it's mostly a personal preference. Those overlap by nature of "competing" with each other. Most tools have a specific purpose in mind. FNIS makes animation mods work. Tes5Edit is a tool to modify plugins. Bodyslide generates meshes. Etc. Leveled lists.... So, the reason for patches in general is that the game will only read an entry once. If Mod A gives Lydia fluffy ears and a tail and Mod B changes her name to "Fluffy," only one of those mods is going to take effect. The game will either read one entry or the other, and whichever one is loaded last (bottom of your load order) will "win" the conflict and take effect. A patch would be created to do both of those things in the same plugin, often setting both of those plugins as Masters so that they're always loaded first, or otherwise set up to "win" the conflict and add both effects at the same time. Leveled lists follow the same criteria, except waaaay more mods want to use them. It's such a compatibility nightmare that most mod authors tend to avoid adding things to leveled lists in general just to avoid it. Even if you wanted to make patches for it, to account for every possible combination of weapon, armor, ingredient or whatever type of mod you're talking about would be impossible. The bashed patch was designed to alleviate this problem in the same way a compatibility patch does, except you run it yourself and it generates a patch specific to your load order. You can also add, remove, and reset leveled lists via script, which a bashed patch does not account for and I'm not going to get into because almost nobody does it... because they don't like train wrecks. As I said, most mod authors simply don't add things to the leveled list just to avoid the whole thing. If you are determined to add mods that make changes to your leveled lists, the bashed patch is probably your best chance at getting things to work how you want, and most mod authors are well-aware of this and will try to make things work as well as they can. Just know, it is a fragile system that can be broken rather easily.

Well, there are exceptions to this but basically a esm is a master plugin and esp is a slave plugin that modifies or adds to master plugins. So, if I created a voice type that was recruitable and marriageable and had a bunch of different conversations, I could save it as a ESP and it would work fine. Then I could give Lydia (who I can see because my plugin is a slave to the Skyrim.esm) that voice type and it'd be great. But, if you created a character on your own plugin and wanted to use my voice type, you could not assign it because the voice type doesn't exist in your plugin. So, the way to get around that is to make the first plugin a ESM, then assign it as a master to the second plugin; that way it can find the voice type. Unless you're creating mods, the distinction isn't really important except when it comes to load order, in which esm always come first regardless of your load order. The only way a mesh or texture mod doesn't need a esp is when they straight-up replace an existing mesh or texture. The game is looking for a certain texture in a very specific folder with a very specific name. So, if you replace that texture exactly, then the game will find the new one instead. If you want the game to look in a different place or add a new item or anything like that, you need a plugin to tell it that. Your original, vanilla meshes and textures are still there. They're packed inside BSA archives. There's no mod that replaces the entire vanilla BSA archives, that would be ridiculous. They just add their own files that take priority. If you delete them, the original ones will load unless you have a plugin telling the game to look somewhere else for them. Scripts are no more dangerous to your game than meshes or textures. Every single thing you do in the game, from moving the camera to opening doors is done via script. Broken scripts can cause problems, just like broken meshes and textures. The difference is meshes and textures make it very obvious when they're broken, while scripts exist in the background and can take a lot longer to indicate something is wrong. Then, by the time you realize it, your save may be worse for ware. There's no reason to avoid scripted mods unless you have reason to believe they may be problematic. You can't tell if they're problematic by looking at the script folder. I could make a mod with 1000 scripts that have no performance impact whatsoever, and I could make a mod with one single script that could systematically delete your saves one by one, make your PC give you the finger, and then crash your game. You just can't tell any of that without opening the scripts and seeing what they do. And if you're not comfortable with that just read the comment/bug report section of the mod. If there's a problem then chances are people have noticed. What you've described is called a "clean save." Basically, you load the game with the plugin removed and save the game again. Then you reactivate the plugin and load from your "clean save" so that it can start fresh. If a mod requires a clean save to upgrade, the procedure is always the same unless specified otherwise. Not all mods benefit from one during the upgrade process. It's mostly for when you change what a mod is doing, then you might need a fresh start for the changes to take effect. But a lot of the time, the new version is going to do it the same way so there's no point in stopping and starting it again. You'll just have to trust the mod author's instructions. If you care about the long-term health of your save, it is typically recommended to change your load order as little as possible. The adding and removal of mods in the middle of a play-through can have adverse effects both immediately and over time. This is not specific to scripted mods, but does include them. That's not to say your save won't last 1000 hours while you change your load order every other day, because it could. But it could also... not. Finally, I haven't merged many plugins except for my own. I don't know that there are really any general rules that apply to all mods in regards to what can be merged or not. It really depends on how each one is setup. To avoid merging scripted mods might be a good first step, as some scripts can be setup to look for a specific plugin with the help of SKSE, although not all of them do. Things like face geometry for actors and sound files for voices are structured in a way specific to their plugin, so if the name of the plugin changes then they need to be adjusted. If I were you, I'd just merge really simple mods like armors, weapons, texture replacers, that kind of thing.

I'm all for people being self-sufficient and porting mods over for their own use, or even for others with permission. And for some that may be good enough, but there are definitely benefits to it being done by people who are more qualified and familiar with the mod. Even in a texture replacer - which is about as simple as mods get, you may benefit from resaving the textures in the new DDS formats SE supports. And some might prefer to increase the quality of the textures for the same impact as opposed to using the same quality with a reduced impact. In which case, it would be extremely beneficial to have the source files before they were reduced and compressed for the package that came with the mod.

It looks like a bone-weighting issue, likely an incompatibility between the mesh and the skeleton. If that's a vanilla outfit, then I would lean towards the skeleton part - probably related a breast-bouncing given the distortion. I would try reinstalling your skeleton mod, and then doing some tests on any "physics" related mods that may be affecting it. If the follower uses their own skeleton as opposed to pointing to the generic one, then you need to account for that one as well.