xEdit (SSEEdit)

xEdit - (often called TES5Edit or SSEEdit) is a tool used for many many things, including, but not limited to: cleaning plugins, conflict resolution and patch creation, applying scripts, modifying plugins, and the list goes on. Seriously, learn how to use this in its most basic form and you will be further down the road to a more stable game.

YouTube Videos

xEdit || Installation & Setup - video by GamerPoets
xEdit || How to Clean Mods & DLC - video by GamerPoets
xEdit || Load Order Space Save - video by GamerPoets

Other Helpful Links

Tutorials

Janquel’s A Brief Walkthrough of Conflict Resolution and 3D Space Patching
Mnikjom’s Basic Tools
xEdit Manual Cleaning Guides
u/f22nickell’s Guide to Outfit Leveled Lists
Lively’s Conflicts: Learning How To Read xEdit
Lively’s Keywords - What They Are and Why You Should Care
Lively’s How To Remove a Master Requirement From a Plugin
Lively’s Flagging Plugins as ESL: How-To, Pros, and Cons
Lively’s Constructible Object Records
(and pretty much every other awesome lesson included on the Learning to Mod page)

xEdit Scripts

There are a number of scripts you can use to make patching or creating mods easier. I’m sure there are way more out there that I did not include simply because I don’t know of their existence. These are just the ones that I know of. I have used a lot, but not all of these, and they really have saved me so much time. For any script, all you need to do is download, extract, and copy it to the folder called “scripts” in your xEdit folder location.

Color and Formatting Reference

Thank you to STEP Modifications for this great reference sheet.

Note: These will change depending on the xEdit theme you select, i.e. if you use dark mode, they will be dark backgrounds, etc.

Record Types (helpful knowledge for xEdit)

(copied with permission from this post by Reddit user u/Averagejoe9123)

First off you need to know the three primary columns: FormID, EditorID, and Name. FormId is the actual basic ID of record, the numerical code the engine recognizes it as. Always an 8 digit number. The EditorID is a name meant for sorting/finding via editors or scripts. Name is generally the actual name of what it appears as in game (if it is interactable in game).

Every single record has a unique FormID which helps you find it. There are numerous databases and wikis for searching for base skyrim/dlc forms, but the formID is also determined by Load Order (meaning you don’t need unique form ids between plugins). That’s what the first two digits are: the place in the load order. Hence why Skyrim.esm FormIds are always 00xxxxxx.

You will also interact with two kinds of Form IDs: Base IDs and reference IDs. Base records are the “original” record in the back end, think the actual determining nature of an NPC or the base iron sword. A reference ID is the actual placed base object in the world - if you wanted to spawn a new iron sword, you use the base ID. If you want to move to an iron sword in someone’s house, you need the reference ID.

Now as for the types of records, here are the important ones you are most likely going to interact with:

Ingestible: Consumables, like food and potions
Ingredients: Alchemy ingredients, tho confusingly any kind of item can technically be used to make other items via constructible object recipes.
Ammunition: Arrows
Armor Addon/Armor: how armor and clothes (and even NPC bodies in some cases) are created is via two types of records: The Armor Record is the actual piece that is worn by NPCs, while the Armor Addon is the record of first person/third person meshes for the armor, potential armor swaps, etc.
Book: Books and notes.
Cell: Interior locations. If you go in a building, you are in a cell.
Worldspace: I’ll put this here to put it near cell, this is exterior locations. Tamriel is the primary worldspace that you walk around in. Cities with loading screens have their own world spaces (Whiterun, Solitude, etc). Some other limited areas have their own worldspaces.
Constructible Object: Recipes. All types of recipes are here; what kind they are is determined by the BNAM - Workbench Keyword record of the entry (Tempering is at the Armor table or sharpening wheel, most crafting of metal armors is at the forge, etc).
Container: Boxes you can find in the world, like chests or other statics (like burnt corpses). one weird idiosyncrasy of Bethesda games is that merchant inventories are also stored in Chests, generally with an editor ID related to the store.
Dialog Topic/Branch: These are the building blocks of dialogue trees. While they can be edited in xEdit, it’s a bit confusing in how they are displayed.
Object Effect: essentially enchantments. Applied to Weapons, Armor, etc. Can be used for other things as well.
Faction: more important than you’d think. Factions are used not to just set “teams” of npcs (like Imperials or Stormcloaks) but also what NPCs can do. These are attached to NPC records based on their jobs, positions, etc. There is genericized dialogue that is tied to NPC faction types for instance, or you might set a house to be owned by a family faction and assign all members to that faction so they all “own” the house.
Flora: Many things that you can harvest, like mushrooms or birds nests. ot everything though.
Tree: actual trees and plants, but also the rest of the harvestables like flowers. Not sure why its split from Flora.
Leveled Item: Leveled lists of items. This is a big one. This is where somewhat randomized lists are pulled for NPCs or containers. This is the biggest one for patching typically, as many mods add items (and need to be added to the same lists if you want them organically implemented). There are lots of weird rules to the records of these, like one leveled list chain can’t have more than 255 item calls or it crashes the game.
Leveled NPC: Leveled lists of npcs. Usually a dummy npc record is placed, and the leveled lists are used to somewhat randomize what you see. This can include showing different npcs at higher levels with different equipment for greater gameplay variety or just be for calling unique faces. This heavily utilizes NPC records and Template flags.
Magic effect: Effects for various things in game. These are things that are done instead of stat changes, like shooting fire
Misc Items: pretty much everything you find on the misc tab in game. items without a specific purpose, such as wearable armor or ingestible materials. Includes ingots.
Music Type/Track: These are the most intuitive of anything in the engine. Music types are playlists of music attached to various conditions. MUSCombat is the most important Music Type, as it’s used for 90% of combat music in the game. Ambient music types are typically either tied to a Region record, an actual worldspace cell or interior, or a Location record. When more than one music playlist is valid for any given circumstance, the one that plays is the one with the lowest number Priority (a line in each record). Combat is priority 2 and plays over almost all other music types when it is valid (during combat). Actual conditions can be set in greater detail for each individual track - e.g. you can set times of days songs can play etc. Sorry if this is too much info I love music modding.
Non-Player Character (Actor): Another big one. This is the base reference of all npcs: where faces are set, inventories established (or pointed to leveled lists), skills set, etc. One of the most important ones by far. When someone refers to an NPC baseID as opposed to a reference ID, this is what they are talking about.
Outfit: Outfits for npcs. Often point to leveled items.
Package: AI packages, determine what npcs do. These are placed in Non Player character records.
Quest: Quests, also used to fire scripted scenarios you wouldn’t think use quests. Most everything uses quests to implement scripts.
Race: NPC “types”, like an Ice Wolf or NordRace. Made more confusing as there are backend race types to allow you to bulk change certain kinds of NPCs - e.g. the Afflicted are in Lore Bretons, but they have their own race in so that they can have their attack data/skin and such standardized. In cases like this, NPC records can have an “Attack Race” defined which is what for lore/balance reasons like perks or enchantments they are considered as.
Relationship: Relationships between npcs, I think also for factions. Used to set what type of relationship people have (Master Apprentice, Father Son) but also their opinion rank with each other. An interesting tidbit on this is the Nexus version of 3dnpc (Interesting NPCs) has a Relationship record between Carlotta from Whiterun and the player character so that she’s automatically your max relationship value (4, Lover). Odd mistake.
Shout: Shouts!
Spells: Spells! This is what you “Learn” when you eat a spell book, but also covers also spell like things done in game.
Scroll: Scrolls!
Static: Things that don’t move that aren’t terrain. Most everything you look at in game that you don’t directly interact with is a static. Also weapons for some reason use a static record for their models instead of something like and Armor addon.
VoiceType: voice types for npcs! “Human” npcs in Skyrim largely use genericized voice types, as they all share dialogue for certain interactions for cleanliniess’ sake (Is someone there!??!). Dialogue lines are often conditioned based on voice type. Attached to npc records (if no voice type, no voice for npc :()
Weapon: Weapons! Refers to statics for parts of the model (1st person iirc), can have attached object effects.
Weather: Weather!

Most everything else you won’t really mess with in xEdit. let me know if you have more questions on any of these. Most conflicts that need resolution are in:

Leveled Items
Leveled NPCs
Worldspace/Cells
Non Player Characters

Mac’s Conflict Resolution 101

So, you installed multiple mods that edit the same thing? We have all been there (and continue to return time and time again). The best tool you can learn how to use to help with these situations is xEdit (aka SSEEdit). Below you will find the briefest introduction to conflict resolution via xEdit (at least the briefest I could manage):

I use Mod Organizer 2, so these instructions will be specific to that program.

Refer to this video on how to install xEdit in MO2: xEdit || Installation & Setup

Once you have installed xEdit, make sure that the plugins you want to do some conflict resolution for are active in both the left and right panes (you can have other plugins active, even your whole modlist, but I figured it would be easiest to show with a limited number of plugins):

In this case, I have the two patches I want to do CR for, as well as all of their masters.

Run xEdit from the executable:

Let it load in (you will have to hit OK at least once):

Now, you can find the records yourself by opening the trees in the left pane, but the easier way to find conflicts is to select the plugins you want to do CR for and choose “Apply filter to show Conflicts (selected files only)” (or you can do it for all plugins if you would rather):

When it finishes filtering, you will be left with something like this (this is a very small example, and often when doing CR, you will have MANY things show up here):

As many veteran modders will tell you, RED doesn’t always mean bad, it just means that there is a conflict. In this case, it is telling us that the MacAlternatePerspective-Campfire plugin is “losing” to the MacAlternatePerspective-Sunhelm plugin in regards to that specific container. If you select either of the containers in the left pane, you will be able to get more information about the container and the conflict in the right pane (before hiding no conflict and empty rows):

(and after hiding no conflict and empty rows):

As it stands now, if we loaded into the game as is, we would only get the Empty Waterskin in the container. If we rearranged the plugins so that the Campfire one was higher priority than (i.e. loaded after) the Sunhelm patch, then only the campfire items would show up in the container. In order to have all of the items from both plugins appear in the container, we will need to make a patch for them. To do that, we start with right-clicking the heading of either plugin in the right pane, and selecting the “copy as override into” option (it doesn’t matter much which plugin you select, but I always pick the one that has the most “stuff” that would need to be moved to the patch; in this case the Campfire plugin):

A big scary window will pop up asking if you are sure; you are! (this can feel scary the first few times, but remember a couple of things: 1) you are going to be creating a patch, so not editing an existing plugin, 2) if you do accidentally edit an existing plugin, and don’t mean to, you can always exit out of xEdit without saving, and 3) if you do accidentally save a plugin with changes you made and didn’t want to, as long as the “Backup Plugins” option is checked, you will have a backup, and 4) you can usually just re-download a mod if you really screw things up!)

Another window will pop up after, asking which plugin you want to add the overriding record info into, and also giving you an option to create a new plugin for the record information. In this case (and in the case of most patches you will create), we are going to select the third option, which is an ESP plugin that is flagged as ESL. We choose this because the ESP functionality will allow us to put it nearly anywhere in our load order and the ESL functionality will prevent it from using a plugin slot:

Name your plugin something (I usually use something that has a prefix I can use to easily find my created plugins as well as general info about what the new plugin will be doing); in this case, I chose Mac (my chosen prefix) AlternatePerspective (the original mod these plugins are for) CampfireSunhelm (the two specific patches my new patch is patching (patchCEPTION!) and Patch just in case I’m not sure what this plugin is doing (lol):

You can really name it whatever you want, but remember that you want to name it something helpful for future reference.

Hit OK.

You aren’t done yet, because all you really did was make sure that the plugin you chose for the override “wins” (which in some cases is exactly what you want for a patch, but not in this case). We are still not getting the empty waterskin:

It is generally not advised to edit plugins for mods that you download. This is because of a few reasons, one of the most important being that if the original mod updates, you will lose that work you did changing it if you choose to download/install the update. Creating patches instead of directly editing others’ plugins is generally considered a better modding practice. Since this newly created patch is our baby, we can edit it however we want! We could change the quantities of items in the container or add/remove items, or in this case, just carry over the poor Empty Waterskin so that it doesn’t get left out. To do that, all you have to do is drag it from the original plugin to the empty spot in our patch:

In most cases, it will ask if you want to add a master (or multiple) to your new patch. You will select yes.

To save the plugin, you can manually save (usually done if you have more to do in xEdit) or just leave the program, making sure to hit OK on the window that pops up prompting you to save the edited plugins. (I always check to make sure that only the plugins I intended on editing are listed. This is also where you can uncheck any that you didn’t mean to change, or that you changed your mind about):

When you are back in Mod Organizer 2, you will see your plugin at the bottom of your right pane, but you will still need to add it to a “mod” in the left pane. To do that, go to the little wrench/screwdriver/spanner/whatever and select “create Empty Mod”:

You can call this whatever you want, but I usually choose something similar to what the patch is called. Once you have the empty mod, right click on it and select “Open in Explorer”:

In the right pane of MO2, right click the plugin you created and select “Open Origin in Explorer” (the plugin will be found in whatever folder you designated as your xEdit output; if you didn’t designate any, the default is “Overwrite”):

Drag the plugin from the output folder into the new mod folder:

To make sure it is working, make sure both the mod in the left pane and the plugin in the right pane are active (and where they should be in the load order). Load into the game and you should have all of the items in the container!

This is obviously a very rudimentary example of conflict resolution in xEdit, but the principle applies to many situations and can be expanded upon to make your own patches for all kinds of things.

One final note, anytime I make a plugin, whether it is an original or a patch (or a patch of a patch….etc), I do run the “Check for errors” option on the plugin in xEdit. This just makes sure that I didn’t do anything unexpected or miss any steps. For simple patches, it rarely brings up anything, but I like to be thorough.

Hope this helps and please, as always, let me know if you have any questions or if I can help in any way!