ruddy88

I see people ask about this all the time, and since I'm sick of typing out explanations each time I figured I'd type up a bit of a informative guide on what blackface is and how to fix it, hopefully in a relatively easy to understand way. I'm sure we've all come across it, but for those who haven't, blackface is when you you load in to game only to find a bunch of your NPCs have dark skin textures. Before we continue, we should address how NPCs faces are actually handled in game. When we start a new game, we are taken to the character creation screen where we alter a bunch of sliders to create our players face. These sliders can represent what type of headparts are used (hair, brows, beards etc), as well as represent a morph value for the shape of these parts (nose length, eye height, chin width etc). NPCs are technically created the same way, theyre head is just the result of a bunch of sliders that were created by the developers. the difference, is that NPCs heads arent generated dynamically in game based off the slider data, but are instead pre-generated and exported as a standalone mesh and texture, we call this FaceGen and FaceTint respectively. This is, to my knowledge, because loading a pre-generated mesh is much less taxing than having to generate a mesh dynamically based of slider data. So, what causes blackface? Basically, a NPCs facegen mesh (.NIF) consists of multiple mesh shapes (TriShapes). These shapes each correspond to the various headpart's that makes up the complete head. Headparts are the individual head building blocks that make up a face (head, eyes, hair, brows, beards etc), each of these have an individual headpart record stored in the game plugins. The Facegen's TriShapes are labelled with a string (text) that matches the name of the headparts in the game plugin. With me so far? An NPC will also have an NPC record inside a plugin (ESP/ESM), and in this NPC record it will list all the headparts that the NPC uses. It will also list any other slider data used to "morph" those headparts, as well as tint data for any overlays (scars, warpaints, complexion etc) and colors (makeup, skin tint etc). Blackface occurs, when the headpart labels in the facegen mesh dont match the headparts listed in the actual NPC form in the plugin. If the NPC form says that the actor has a hair headpart named LongHair002 but the facegen mesh has a string labelled HairShort001, then the game will get confused and the result will be a blackface NPC. Thats the basics of it anyway. The basic fix, by the way, is to make sure that the winning NPC record and the winning facegen assets match. But we will go in to more detail in a moment. First lets discuss a few scenarios. This mismatch in data can happen for a few reasons, and I'll cover the ones that I can think of. Scenario 1: Load order vs Asset order. Mod organisers like MO2 and Vortex allow independent managing of both assets (meshes, textues, scripts etc) and plugins (esp, esm, esl) independently of each other. This is an important concept to comprehend. Let's say you have two mods that modify NPC looks. They both handle multiple NPCs, but unfortunately they overlap and both edit Lydia. You install MOD A first, by default it gets added to the bottom of your load order. Now you install MOD B, which is now the new last loaded mod. You realise that you prefer MOD A's visuals, so you move the plugin for MOD A down to the bottom. BUT, you havent moved the actual mod folder down to match it (Vortex can use rules to handle this but I am a MO2 user and not too familiar with it). What this means, is that the GAME RECORDS are expecting all the visual changes from MOD A, but the actual assets being loaded are going to be coming from MOD B as the folder order wasnt adjusted when you moved the plugins around. Simple fix for this is to just move MOD A's asset folder back below MOD B. Done. Scenario 2: BSA's. Another important concept to understand is how asset loading works in Skyrim. Skyrim can use BSA's to archive and compress assets in to a single file (basically a Bethesda version of a .rar/.zip file). This is great for loading times, but can cause issues at runtime. Why? Because loose files will ALWAYS take priority over files in a BSA, no matter what the order is. So, using the same scenario as above, we have MOD A and MOD B both affecting Lydia. This time however, you make sure that both the assets and the plugins from MOD A gets loaded last. The problem, is that MOD A uses a BSA, and MOD B uses loose assets. This means, that even though MOD A is loaded last, the loose assers of MOD B will still take priority over anythign in MOD A. Which is bad for us, because it means we will still be getting Facegen from MOD B while trying to load NPC data from the plugin in MOD A. The solution? again, manage your load order correctly first, then extract all the files from MOD A's BSA so that it is instead using loose files. Bethesda Archive Extractor on Nexus can handle this for you. Just run the program, navigate to your mod managers installed mods folder, extract the BSA in the same location then delete the BSAs after to free up space. Done. Scenario 3: Unexpected mods. This is another common cause of blackface and one that catches a lot of people out. Unexpected mods that load later which may also affect NPC records. We spoke about NPC records before and discussed how they contain a lot of data about how the NPC looks, but they also have a lot more data on them, things like raw stats, names, inventory, spells, ai packages and classes. There's quite a lot of data in an NPC record and its quite likely that other mods will need to make changes to various non visual changes to NPCs. An obvious example would be mods like "AI Overhaul". This mod alters NPC packages, which requires making changes to NPC records to add those packages to them. The problem with this, is that these are the same NPC records that contain all those visual changes needed for your NPC visual ovrhauls to work. So, again, we have our MOD A and MOD B, both affecting Lydia. We want MOD A's changes to win so we've managed our load order so that MOD A loads after MOD B, we've adjusted our assets order the same way and we've ensured we've extracted the BSA's for these mods where necessary. Everythings working, then we install a few mods, and suddenly Lydia has black face again. We do some digging and we find that MOD C is trying to change Lydia's default armor and inventory items, but all the visual data from MOD C is still the same as vanilla. As such, MOD C also doesnt have any facegen data, because on its own it wouldnt need it. But this means we now have Facegen From MOD A, and visual data that matches the vanilla NPC face. Mismatch = Blackface. This time though, we can't just move MOD A below it again, or we will lose the changes the MOD C brings about. I mean, it IS an option, if you come across a mod conflict that doesn't do anything major and you can live without then you can just move your load order around, but if you want the changes for both there's only two options. Option 1, is look for a patch. AI Overhaul for example, has gotten a lot of traction, and many of the big NPC overhauls will come with an AI-O patch that you can use. But if no patch exists, then you're only other option is to patch it yourself using XEdit (collective name for TESVEdit, SSEEdit, FO4Edit etc). Now, I won't be explaining how to use XEdit, there is other guides out there and it's far too confusing to type in an article that is already long winded. But, Once you have gotten the hang of basic XEdit functionality here is what you can do to make a quick patch of an NPC, in our case Lydia. First, navigate to the plugin of the mod that has the visual changes you want, expand it, then expand NPC group. Find the actor, in our case Lydia, right click the form and choose copy as override. Scroll down to the bottom and choose to copy it to a NEW ESP. Name your new plugin (LydiaPatch.esp for example). Now, select Lydia again. You will see on the right window that all versions of the Lydia record are displayed with the plugin name at the top of the window thats making that versions changes. To the far right there will be your freshly copied patch version, which currently is just a duplicate of our MOD A (the one with the visual changes). You will however, also see a bunch of colored highlighting, this all representes various states of conflict. Green background means its all gravy, there is no conflict, but the other colors (yellow and red mostly) indicate that there is some sort of conflict. This makes it easy to see what fields have changes in earlier versions of the record that may not be present in the winning override. Now, conflicts are not the end of the world, they are often unnavoidable. The goal isnt to make the whole column green, it is instead to make sure that you've inspected each colored conflict to confirm it is using the changes you want. In our case, we will see that there is conflicting data on the "Default Outfit" field, as well as on the "Items" field, as this is the two fields that were modified by MOD C. We can safely drag data from MOD C over to our patch as we see fit. Our main concern here is to make sure that we do not make any changes to any of the visual fields, these all need to remain the same as they were in MOD A because we will still be using the Facegen from MOD A. Once we're done, we can close XEdit and save our patch, now all we need to do is make sure our patch is active and loaded after MOD A and MOD C. Note, if you are still adding more mods then it's entirely possible another mod will come along and make more edits to Lydia, just keep an eye out and if you run in to problems then just fire up XEdit and add further changes to yoru Lydia Patch, or make a new patch. Ok, so those are the three most common scenarios that I can think of. Let's talk about other possible solutions, and the issues that can come with them. Export Facegen! I see this answer a lot, and honestly, it's just asking for problems. Basically, a lot of people will say to fire up the creation kit and re-export facegen for that character, that way the facegen and the plugin data will match. And, yes, that is correct. But the problem with this is that there is limitations to what the CK can export. See, most NPC visual overhaul mods arent actually made in the Creation Kit, but are instead made in Racemenu or ECE or an alternative. These mods unlock morphs and slider ranges that are well and truly extended past vanilla ranges. But the creation kit doesn't know about these ranges, it only knows about vanilla morphs ranges. Lets say a modder makes a face, Eye height is at the minimum, but due to Bethesda's often terrible headparts, the eyes still seem too high. So, with the help of racemenu they use one of the secondary racemenu eye sliders to reduce the height further. They then adjust features of the nose to thin the bridge, flare the nose wings, minimise the nose tip and point it up a tad. Getting there, but we need some work on the mouth, lets add some mouth corner depth and a hint of a cheeky smile, bring the teeth forward. Now lets add some weight to the lower cheeks, round out the jawline... pretty good! All of those changes were made using racemenu only sliders. None of them other than the first eye height slider actually exist in the vanilla game. But we're not done yet, lets take it in to racemenu sculpt and really fine tune it! 7 hours later the modder is done, theyve got a face they like, and they export it using racemenus built in export functions. To make the mod an NPC they now also have to go through a bunch of workarounds to merge that exported data in to a CK exported facegen (its a pain in the ass to do). Finally hey have a functioning facegen for their NPC character, they upload it as a mod, we download it, aaaaand because of our other mod conflicts we have blackface. Soooo we decide to head on in to Creation Kit so we can just re-export the facegen... And here's the rub, virtually all of those changes the mod author had made to perfect that face, have now disappeared. We are left with an NPC face that DOES have all the right headparts, but the vast majority of morphs and tweaks that were made to actually shape the head are now gone, only the basic handful of vanilla slider changes will be brought across. The result will be a horribly ugly potato shaped mess. Now, that's not to say you CAN'T export facegen, if its for an NPC that's only been modified with vanilla sliders then it will work just fine, it's just not very common to see that these days, and in most cases you'll end up with borked faces. I mean, they wont be blackface anymore but they'll sure be ugly. Anyway, this has already taken quite some time, I think I will leave it there for now and will add more if I think its necessary. Leave any comments if you see any mistakes, or suggestions, or if you have any questions and I'll try get to them when I can.

oh look, Necro'd post AND piracy... we have a double whammy here.

In response to post #60325966. #60326041 is also a reply to the same post. Will you see the actual listed percentage you are getting? or just a total amount? As mentioned in another comment, if I agree for someont to port a mod with the condition that I get 50% of DP, I would want to be able to confirm that I am not getting ripped off from someone only sharing 30%. If that makes sense.

In response to post #60322336. #60326136 is also a reply to the same post. It would be a case of the original mod author including a nominated percentage of DP in exchange for permission to port. I could release a mod, and in my permissions state that: "Permissions to port this mod, however All/90%/75%/10%/Whatever DP must be issued to myself. The only thing I am not sure about is whether or not users can SEE that the original mod author is receiving the relevant DP. If I give permission to port on the condition that I get 50% of DP, then I would have no way of actually checking that if the percentages werent public.

Just some advice on cleaning that script up a bit. First, You have already gotten a PlayerRef property, so there is no need to call Game.GetPlayer() in your script: if akActor == Game.GetPlayer() Can instead just use: if akActor == PlayerRef Secondly, when you are checking the return value of a boolean, you dont need to use == 1 if you are just checking it is true. So: if (PlayerREF.IsEquipped(EbonyBoots) == 1) && (PlayerREF.IsRunning() == True) Would be better written as: if (PlayerREF.IsEquipped(EbonyBoots)) && (PlayerREF.IsRunning()) ;I also don't think they need to be filly encapsulated in parenthesis but it doesn't hurt. Similarly, if you were checking that a boolean was false you can use the NOT operator, in Papyrus it is a ! so to check that the player IS NOT running: if !PlayerRef.IsRunning() That said, what was the issue and what was the solution? Just for curiosities sake?

Convert it the same as any other mod. HOWEVER, You will need to resave the textures for the eagle swords, they are saves in dxt3 compression which skyrim SE doesn't like and crashes. This is one of the extremely rare times that a texture woll cause a crash. You'll need GIMP or PHOTOSHOP and the DDS plugin. Just open the textures, immediately resave them as either DXT1 (if it's a solid texture) or DXT5 (if it has transparent areas).

Hey guys n gals. I am making a mod and looking for some help with assets. TL;DR: I need someone to help with creating animal skeleton meshes, preferably already weight painted to the animals skeleton.nif as it will have to be made in to an "armor" of sorts. I can do the weight painting myself if needed, but the skeletal mesh will need to line up with the vanilla animal mesh. Can use bone resources from Mihails Animal Bones mod. So, the mod. The mod is inspired by Hunterborn and Hunting in Skyrim. I am adding the ability to physically skin and gut animals and creatures when you take pelts or meat from their inventory after they are killed. I am doing it in a much more compatible and performance friendly way and will be adding some other features but the main idea is to keep things functional, but LITE. I already have a working proof of concept working using the skinned mesh/textures from Hunting in Skyrim, and I have messaged the author of that mod to ask if I can use the assets he has already made, but I will need more variations. So here's what I want to happen (mostly already working): When the player opens the inventory of a dead animal, the mod will detect if they take any Pelts/Skins/Hides, or if they take any Meat/Food/Parts specific to the animal. If the player HAS taken either of those items, the screen will quickly fade to black then back again (this fade can be toggled off for people who don't like the delay and just want to get on with it, but it means the animal skin will change in front of their eyes instantly). During the fade, if the player has taken pelts or hides and hasn't taken any meats, then the "Skinned" texture/mesh will be displayed on the carcass. If they take Meats (with or without skins), it will show a "Gutted" texture/mesh. If they take neither, and just take non-animal part items or nothing at all, then there is no fade to black, it just operates as a regular inventory menu and will trigger again if the animal is accessed again. A Skinned animal can still be Gutted if the player re accesses the inventory and takes the meat. A fully gutted animal will be treated as any other normal dead body, no further effects will play again. There are internal conditions in place to make sure this entire process does not even trigger unless you are activating a creature belonging to one of the included races, so animals with modded races, or animals that I haven't included will just use the regular inventory menu, but if they use the same vanilla races then they will still work. I will also look at making patches for popular animal mods where possible. During this entire process, the carcass will still be treated as an actor. It does not swap to a static or anything. The Skinned and Gutted effects are added as an armor to replace the existing creature skin. This also let me add keywords to the skinned armors to help with condition checking. I have ALL of this working (except I haven't added sound effects yet). Furthermore, the entire thing is executed from a single perk applied to the player, which calls a function stored in a quest that is only about 10 lines. It's all very quick, simple, there's no dialogue menu's to contend with. So far the ONLY issue is that the fade to black doesn't work with some ENBs (the mod works, you just wont see the fade effect, which is toggle-able anyway). BUT to implement it fully I need to create assets to use as the replacement meshes for the animals Skinned and Gutted versions. This means I will need: Skinned versions of each of the races to include (things like: Deer, Wolf, Troll, Chicken etc. Though I was planning on letting you skin and hunt people as well as other monsters). Gutted Versions (these can either be an animal skeleton with blood effects applied, or a skeleton with chunks of meat and organs still present, either will work fine). These HAVE to be rigged as an armor for the animal though. They cannot be statics. This is because I use a script function to equip the skinned/gutted armor to replace their default "worn armor" (SkinWolf for example), which lets me continue to treat the animal as an actor. Now, the skinned versions should be easy enough, I can probably do these myself just by opening up the vanilla nifs, stripping them back and applying bloody textures, then just copying the bone weights from the vanilla skins, much like Hunting in Skyrim has done. But the Gutted ones need more work that may be beyond my capabilities. I have an idea of how it could be done but it's not my forte and I was hoping someone more experienced with 3D could help out. My plan, was to use the animal bones resources from Mihails Animal Bones - https://www.nexusmods.com/skyrim/mods/89445 (He has already given permission). Load up the vanilla animal mesh in Blender/3DS, then create a "skeleton" using the bone resources from that mod, making sure the bones line up with the vanilla positioning of the animal mesh. Combine it as one object, export as OBJ, open it in OutfitStudio, then go through and weight paint it there. The weight painting SHOULD be easy enough, since they are bones they will be 100% rigid, so just have to paint each bone "section" and paint it so it is 100% fixed to the corresponding bones of the animals skeleton nodes. It also wouldn't have to be TOO precise, because for the most part the animal skeleton will just ragdoll on the ground, however it WILL be possible to re-animate these creatures even after they are skinned so some level of precision is needed. Anyway, That's my plan so far. I am really hoping that someone can help out here and join in on the progression of this mod. At bare minimum, I am hoping someone can just make the single object skeleton meshes lined up with the vanilla animal mesh and Ill do the weight painting. But ideally, if someone could volunteer to do both the models and the weight painting that would be very much appreciated. Or if someone wanted to go all out and do proper, field dressed meshes for all the animals that would be ridiculously amazing (I'm not holding my breath). If someone CAN help out with this, then while you are busy with that I will be looking into other functionality of the mod. I love the idea of trapping in Hunting in Skyrim and was thinking of re-implementing that sort of thing. Also, if anyone else is reading this and has further ideas on features to implement or just has general advice on the direction it's taken so far, feel free to comment and let me know your thoughts on it.

Just making sure, but did you create an empty .TBL file? The game has TBL files as well as XML files. TBL files are basically encrypted, we cant as of yet edit them very easily so we edit the XML files instead as these aren't encrypted. However, the game will try to use a TBL file first. So if you edit an XML file, you will also need to include a blank TBL file to force the game to use the XML file. Simply create a new notepad document, leave it empty, save it and type the filename.tbl and save as type "all files". Include this in your new PAK file with the XML file and the game will use your XML file instead of the TBL file.

G'day folks. Quite regularly I help people with modding problems on a facebook group I am in. Decided I'd start posting some of the stuff I help with as mini tutorials on the forums here if it's something I see asked a lot or that just may come in handy. Todays topic: Preventing a follower from entering a cell with you. NOTE: There is a vanilla script already that does this, however it does seem to have some flaws so I have modified it to be a bit more reliable. The problem with the vanilla script is that your follower still remains your follower, they just dont enter the door. If you enter combat while inside however, sometimes your follower auto teleports to you. This can also happen with modded followers that have a "catchup" script applied to them, since they just telkeport and never actually go through the door (which is what we use to block access). So my solution was to also add a dismiss feature to the script so that the follower actually leaves your service. The best part, is that we don't need to actually write that script, we can just utilise the vanilla follower script to do it. Lastly, this should work on both actual followers, as well as NPCs that are following you via an ai package (and arent actually added to the follower faction. the caveat with that is, if a follower is simply using an AI package, then they wont leave your service. They will instead remain a follower but will wait outside (as they cannot activate the door) and will go back to following you once you leave that cell/worldspace. So lets get to it: In the creation kit, double click on your door reference. This can be a physical door, or it can be an automatic door (such as with cave entrances) or it can even be an activator (like a port key that you activate to be teleported to a location). On the reference window, go to the scripts section, add a new papyrus script, name it whatever you want. Then right click the script, select EDIT SOURCE. You will have: Scriptname WhateverYouCalledYourScript extends ObjectReference All you have to do is paste the below script in: Faction Property CurrentFollowerFaction auto Faction Property DismissedFollowerFaction auto Quest Property pDialogueFollower Auto Event OnInit() BlockActivation() EndEvent Event OnActivate(ObjectReference akActionRef) if IsActivationBlocked() == False Debug.Trace("Door is currently unblocked") return endIf if IsActivationBlocked() == True if akActionRef == Game.GetPlayer() Activate(akActionRef, True) else Actor actorRef = akActionRef as Actor if !(actorRef.IsInFaction(DismissedFollowerFaction)) (pDialogueFollower as DialogueFollowerScript).DismissFollower(0, 0) actorRef.ModFactionRank(CurrentFollowerFaction, -2) actorRef.AddtoFaction(DismissedFollowerFaction) endIf endIf endif EndEvent Finally, from your reference window, click on properties, and Auto-Fill All. Thats it. Repeat this process for any other doors or activators that lead in to your cell. NOTE: This should work for cells as well as worldspaces. But be aware, if you create a "door" to another worldspace, the script will work fine. But if the player fast travels from the vanilla worldspace to a location in your new worldspace, then neither the player or any followers will end up activating the door so they will NOT be dismissed in this case. The only solution to this is to disable fast travel locations in your new worldspace. Unfortunately there is no vanilla script function to detect onFastTravel (at least none I am aware of) so there would be no easy way to prevent followers from following you to your worldspace if youre fast travelling there.

Lol, Just saw this in forums and was like "Hey I just did that exact same thing for someone like yesterday!!!" Then I saw your nexus name and realised You were the one I did it for haha. Thread closed I guess :D (Im assuming it all worked anyway?) If anyone else is reading: The solution was to create a ring, an enchantment and a magic effect. On the magic effect we went to the scripts and simply added the vanilla script: "MagicImodScript". We then went to properties and edited the value to point to the IMOD of choosing. This is the solution for effects that only have one IMOD. If you wanted to add one of transitional IMODs that have a START and END effect as well, then you would want to copy a different script (have a look at magic effects for poisoning). These scripts have 3 properties, a start, a loop, and an end, which you would then set to your 3 IMOD properties (you will see that some IMODs have a start and end version for transitional effects). Thats pretty much it, the rest of it is just adjusting things to your liking (casting sounds and whatnot)

Ive been trying to either reduce or increase the "decay" on both energy and exhaustion. <row rpg_param_key="DigestionSpeed" rpg_param_value="1" /> This one works, but not quite as intended. It doesnt make food drop by 1 per second, in fact it drops MUCH quicker. But it does work, and using very small decimals is able to reduce the hunger decay. That said, I am wondering if we can determine what the base value is? I was hoping to make it an exact half, and since it's already quite slow it can be difficult to test how effective the values are. Now, <row rpg_param_key="ExhaustionSpeed" rpg_param_value="1" /> This doesnt seem to work at all and I am not sure why. I have tried using very high numbers (100, 1000 etc) as well as vey low numbers in case it is inverted or something (0.0001) but nothing I do drops the energy levels any different to the regular values. Any ideas on what that would be? Thanks heaps for typing this all up. While I am here, I am curious why there is so many values that arent stored in the rpg_param.xml file. Are they stored globally somewhere else? or do they just have a default value somewhere in hard coding and therefore dont need to be defined? I had no idea there was so many varaibles we could tinker with, comparitively, the amount of values that are already in the rpg_param.xml is actually not much at all.

two problems can be happening. 1: the parent node needs to have the same name. When you click on the 0ninode or 0BSFadeNode, to rename it you need to click on the actual txt ICON in the block details window. If you click the space next to it you can only enter a number (which corresponds to an already existing string). Clicking the txt ICON let's you type in a new string. 2. If you are copying a block that references a specific node, such as a trishape for a glove that references the finger and hand bones in its included sub blocks, then those nodes have to be in the nif you ate copying to. Eg: you are copying a pair of gloves to a torso armor. The torso armor has all the torso bones/nodes but doesn't have the hand and finger bones/nodes. Solution: first make sure the root node (0NiNode or 0BSFadeNode) have the same name by following my instructions above. Then copy branch on EACH NiNode from the gloves nif that isn t already on the torso armor nif. Once all those nodes exist on the torso nif, you are free to now copy the Nitrishape of the gloves over to the torso nif. further notes: In my example, you would ALSO need to make some adjustments to your armor record to include the hands as a biped slot on the armor and armor add-on record of your esp. With armors, Trishapes will have an extra data block with an option for partitions (I think it was called something like NiSkinData, I can't remember the block name in LE but it is called a Bsdismemberskin block in SE). This partition section will have a biped slot allocated to it. IF that slot is not ticked in the armor and armor add-on record then that part of the mesh will be invisible in game. So you need to EITHER add that slot to your armor and armor add-on records, or change the slot in the partitions section of your trishapes in nifskope to reflect the biped slot you were already using. Keep in mind, If you changed the gloves trishape to instead use 32_body in the nif, same as the torso, then only ticked 32 slot on your armor and add-on record, then users will be free to equip your new armor with its gloves as part of it AS WELL as another set of gloves which will just clip through each other. so in the example I have it would be better to add the 33_Hands slot AND the 32_body slot to your armor and add-on records so that it replaces any currently equipped gloves or torso pieces.

You really shouldn't be updating ANY of the ini values without knowing what they do. And posts like these should not be made unless you EXPLAIN what the tweaks do. If you don't know, don't post, lest we get inundated with the already endless flood of broken game posts.

This started as a fair post simply sharing a frustration and very quickly turned into a post for users to demand things of mod authors... There's a number of reasons mods aren't inclusive of the required files. Updating is a major one and probably the most valid. There's also a lot of older mods where the authors are no longer active so seeking permission is impossible. In the end it doesn't matter, it's the authors choice to do what they do. You don't want to spend a feq.hours making patches or merging or just simply don't want to mess around with your load order? Well too bad... if you think that takes long, try making mods. I can guarantee the time invested in making even simple mods GREATLY exceeds the time it takes to clean up a mod list. We in no way owe you more of our time unnecessarily because you couldn't be bothered to learn to set up your own mod list. Most of us are nice enough and will go out of our way to help you should you encounter problems, but we won't help someone who won't help themselves. Dependencies are there for a reason, as are the mod description pages, so read them, follow them, and if you still have problems THEN come and ask for help. Don't throw tantrums on forums because you want it your way, especially when you have no clue about the sort of restrictions we already face with mod creation. * not directed at OP but to the follow on replies.