MODDING BASICS

THE ROOT FOLDER

steamapps\common\Skyrim Special Edition

After installing Skyrim SE through Steam, the installation folder will have a size of about 13GB. This folder is referred to as the root folder and contains (among other files) the game’s executables, SkyrimSE.exe, and SkyrimSELauncher.exe.

Any mods that must be installed into the root folder cannot be installed with a mod manager and must be moved into the root folder manually. Examples of mods that belong in the root folder are SKSE, ENBSeries, and CK Fixes.

THE DATA FOLDER

steamapps\common\Skyrim Special Edition\Data

The root folder also contains another important directory: the data folder. This is where the vast majority of mods belong, and mod managers are typically used to manage its contents. Confusing the root and data folders will lead to mods not working, as they need to be in the correct directory, so be sure to remember the difference while following the guide.

Inside the data folder you can find the “skeleton” of vanilla Skyrim: its five master plugins and associated archives. All game files are stored here in these two file formats. These are the five master plugins (or official master files):

  • Skyrim.esm
  • Update.esm
  • Dawnguard.esm
  • HearthFires.esm
  • Dragonborn.esm

The first is the original game’s plugin and the largest of them all. The second one contains all additions and fixes that were patched in post-launch and for the Special Edition re-release. The remaining three plugins belong to the DLC as the names indicate.

THE INI FOLDER

C:\Users\{USERNAME}\Documents\My Games\Skyrim Special Edition

After running the game for the first time, the INI folder, containing the game’s configuration files, will be generated. Besides the Skyrim.ini and SkyrimPrefs.ini (which store the game’s settings), the INI folder also contains the Saves folder with your save files.

There will be several more folders added automatically later on where certain mods store their LOG files.

ELDER SCROLLS PLUGINS

Plugins are files with the extensions ESP, ESL, or ESM. They edit Skyrim’s master files or add new records.

The most common plugin is the Elder Scrolls Plugin (ESP), and it is used for the majority of mods. ESPs can be created using the official modding tool, the Creation Kit, or the modding community’s tool, SSEEdit, and they can contain all kinds of data for cells, worldspaces, NPCs, their behaviour and appearance, game rules, quests with their different stages, dialogue, and so on. Vanilla Skyrim does not have any ESPs.

Elder Scrolls Master plugins (ESM) are always loaded on top of your load order, before your ESPs. An ESP always requires at least one ESM which is usually Skyrim.esm. However, ESPs may also require other ESPs. These dependencies are not mere suggestions; they are hard requirements, and missing a plugin’s required master will result in errors and crashes.

It is possible to flag ESPs as ESM in SSEEdit. This will cause them to load near the top of your load order and above the regular ESPs.

PLUGIN LIMIT AND ESL PLUGINS

You can load a maximum of 255 ESPs / ESMs (including the five master files) into the game. If you exceed that limit, Skyrim SE will crash on launch.

Elder Scrolls Light plugins (ESL) are, however, the exception here. They are smaller – they have a lower formID budget, meaning that they can store less data, which is why they are often used for smaller mods, patches, or dummy plugins. ESLs are loaded in their own plugin space, and they will always be moved below your ESMs and above your ESPs in your load order. You can load about 4096 ESL plugins, but the exact number varies as it depends on the amount of data each ESL stores.

The final plugin type is a hybrid of either ESM or ESP with an added ESL flag. By flagging an ESM or ESP as ESL, you may force it to load in ESL space and prevent it from counting toward the 255 ESM+ESP limit. Additionally, you will be able to manipulate its load order instead of being forced to load it between ESMs and ESPs. An “ESL-ified” master plugin – ESM-ESL – will load at the top of your load order with the other ESMs, while an “ESL-ified” regular plugin – ESP-Lite – will load with all other ESPs.

You can flag any plugin as ESL using SSEEdit so long as it does not exceed the maximum amount of FormIDs. If the plugin adds new FormIDs (that are not part of a master plugin such as the official master files), you will also have to compact FormIDs (more on that later).

In order to convert an ESP to ESL, you will have to flag it as ESL and rename the file extension from ESP to ESL. Any ESL can be converted to an ESP-Lite by simply changing the file extension from ESL to ESP.

EXAMPLE LOAD ORDER

We already established that ESMs load at the top of your load order, followed by your ESLs and eventually your ESPs. The load order is essentially a list of all your plugins. Since they overwrite each other, it is important to sort them correctly. Here is what your load order with different types of plugins may look like:

Bold – indicates an ESM
Cursive – indicates an ESL

  • Skyrim.esm
  • Update.esm
  • Dawnguard.esm
  • HearthFires.esm
  • Dragonborn.esm
  • Unofficial Skyrim Special Edition Patch.esp  <<< an ESM-ified ESP
  • DwemerGatesNoRelock.esl  <<< an ESM-ified ESL
  • Lanterns of Skyrim.esm  <<< a regular ESM
  • Disarming Traps Is Dangerous.esl  <<< a regular ESL
  • SkyUI.esp  <<< a regular ESP
  • Modern Brawl Bug Fix.esp  <<< an ESL-ified ESP

THE RULE OF ONE

The data inside those plugins is saved and sorted in the form of records. Each record has its own unique formID which is used to identify and link to it. These records function like layers, and only the one on the top can be read – it covers up all those below. If one of the layers below the one on top edits the same record, a conflict arises. This is also called The Rule of One.

To elaborate, here is a simplified example:

  • Plugin A.esp
    • Record 1
    • Record 2
  • Plugin B.esp
    • Record 2
    • Record 3

Our two example plugins both edit two records, and both of them touch Record 2. This is a conflict! Since Plugin B is lower in the load order, it will overwrite Plugin A and its version of Record 2 will be loaded in the game.

CONFLICT RESOLUTION

How such a conflict is solved depends entirely on the nature of the conflicting edits. In some cases, conflicting plugins should both have their edits forwarded. Assuming Plugin A gives Faendal a new bow and Plugin B changes his hairstyle, we would want to retain both these changes. To that end, we will create a new layer – a new plugin. This new Plugin C.esp will contain Record 2 with the edits from Plugin A and Plugin B. It must be loaded after both Plugin A and Plugin B to take effect.

  • Plugin A.esp
    • Record 1
    • Record 2
  • Plugin B.esp
    • Record 2
    • Record 3
  • Plugin C.esp
    • Record 2

This is how conflict resolution patches work.

LOAD ORDER ADJUSTMENTS

Occasionally, a patch is not necessary to properly resolve a conflict.

Let’s assume Plugin A adds a bow to Faendal like in our example above and Plugin B contains a minor fix for Faendal’s AI package. After checking in SSEEdit, you discover that Plugin A already contains the fix from Plugin B. In this case, you can resolve the conflict by simply switching their load order.

  • Plugin B.esp
    • Record 2
    • Record 3
  • Plugin A.esp
    • Record 1
    • Record 2

Now Record 2 from Plugin A (containing the new bow and the AI fix) overwrites Plugin B‘s Record 2, and both changes will appear in-game.

ANOTHER EXAMPLE: THE USSEP

Remember that ESM files are always loaded at the top of your load order (the bottom of your “stack of layers”). The USSEP’s plugin is an ESM-ified ESP, so you can place it directly below the five official master files. In your load order, it looks like this:

000 Skyrim.esm
001 Update.esm
002 Dawnguard.esm
003 HearthFires.esm
004 Dragonborn.esm
005 Unofficial Skyrim Special Edition Patch.esp

This is your base – all the game’s data with some specific layers fixed by the USSEP. Any mod you install must be placed below the USSEP here which means it overwrites your base layers.

If we open up only the five official ESMs in SSEEdit and take a look at the individual records, we won’t have to search long before we find a conflict. As you can see below, there are three layers – Skyrim.esm, Update.esm, and Dawnguard.esm – that all edit the “Flame Cloak” magic effect record.

The first of the three (the one loaded at the top) is Skyrim.esm, and it adds two keywords in its own layer. Next comes Update.esm with a new layer, and it includes both Skyrim.esm keywords but adds a third one. And finally, Dawnguard.esm has its own layer in which only one of the two original keywords is included, and it also did not incorporate the new keyword added by Update.esm.

So how do we fix that conflict? By creating a new layer.

The entire record gets copied into a new plugin that is placed “on top of the stack”, meaning it is loaded below/after the five official master files. This new plugin now adds the new layer into which we can drag (copy) all relevant edits to resolve the conflict.

Fortunately for us, the Unofficial Skyrim Special Edition Patch already did this as we can see when we open it in SSEEdit:

LOAD ORDER AND PATCHES

We established that there are two ways to address a conflict: by creating a new layer (a patch) or by adjusting the load order.

Most people are discouraged by the complexity of plugins and SSEEdit, so they prefer to rely on the mod author’s instructions on compatibility and load order and patches made by others. There’s nothing wrong with that! It’s the “casual” approach and requires the least amount of time and effort, so long as you read the mod descriptions and keep your mod list short, otherwise you will break your game or produce countless bugs and issues with no idea how to fix them.

When that happens, people usually ask for support in one of the modding forums. They will then be told to use LOOT – the Load Order Optimization Tool. Technically, there is nothing wrong with that either – LOOT accesses a master list with priority rules (determining where specific plugins should be placed) and is also capable of analysing your plugins themselves.

After running LOOT, you will likely be advised to create a Merged Patch with SSEEdit which automatically merges all conflicting records together. And finally, you “should” use Wrye Bash (yet another mod manager) to create something called a Bashed Patch to merge the levelled lists.

TO LOOT OR NOT TO LOOT

LOOT is not perfect. It doesn’t have rules for every plugin available, and it does make mistakes. To ensure that a long load order does not contain any critical conflicts, you would still need to go through all your plugins by hand – even after running LOOT – in order to create your custom conflict resolution patch.

The SSEEdit Merged Patch is also semi-useful for a long plugin list because it is automated and (1) doesn’t catch all conflicts or (2) doesn’t always resolve them the way it should. The same goes for the Bashed Patch which additionally relies on some tags (RELEV, DELEV, etc) which are not always pre-added by the author.

If you let the Merged Patch handle conflict resolution, you will still have to go through it, fix some things, and resolve leftover conflicts in your other plugins. Same thing goes for the Bashed Patch – while it is fairly reliable, you’re still going to want to adjust it by hand for a long and complicated mod list. Often, it merges levelled lists together in such a way that, for example, causes NPCs to have the wrong or too many items in their inventory.

In short, LOOT, Merged Patch, and Bashed Patch won’t fix everything by themselves.

Eventually, you’ll probably invest just as much time in adjusting your load order and creating patches by hand as you would if you never used any of these tools. This is why I don’t even bother anymore with installing LOOT and Wrye Bash but instead optimise my load order by hand and do the conflict resolution myself.

TL;DR: For a relatively short load order with around 40-50 plugins or less, LOOT and the two automated patchers will most likely do the trick, but anything larger requires more time and effort.

ASSETS AND FILE TYPES

Keeping in spirit with the metaphor of plugins as the “skeleton” of Skyrim, imagine assets as the matter used to fill it out. “Assets” is the general term for all kinds of loose files, such as textures, meshes, and sounds. All vanilla assets are stored within 18 Bethesda Softworks Archives (or BSAs) which in turn are located inside your data folder. These BSAs work much like ZIP or RAR archives – they contain loose files, compressed to save space, and require special software to un- or re-pack them.

These are the most popular filetypes:

  • Textures – DDS
  • Meshes – NIF
  • Scripts – PEX
  • Script Source – PSC only required if you want to edit and recompile scripts; otherwise, they can be ignored
  • Interface – SWF
  • Sounds, Music – XWM / WAV
  • Voices – FUZ
  • (SKSE) Plugins – DLL
  • Animations, Skeleton – HKX
  • Configuration Files – INI / XML / JSON

BETHESDA SOFTWORKS ARCHIVES

As mentioned, BSAs are used to store and compress loose files. Every BSA must be attached to a plugin with the same name; for instance, Example.bsa would be loaded by Example.esp. Without an active plugin to load it, a BSA will not be recognised and used by the game. The plugin can be a “dummy”: an empty plugin that contains no records. Files can be packed into BSAs using a tool that is included in the Creation Kit installation and extracted with community-made tools such as Bethesda Archive Extractor (more on that later).

Occasionally, you may come across ESP+BSA combinations with one Example.bsa and one Example – textures.bsa. The second archive contains, as the name suggests, only textures (DDS files), and it will be loaded as usual by Example.esp. There is also an uncompressed variant of BSAs, which is used to store sound and music files.

Regular BSAs for Skyrim SE must be 2GB or smaller, while Example – textures.bsa versions may be a little larger. This is why the assets of larger mods (and Skyrim SE itself) are split up into multiple archives.

MOD ORDER

Assets in your mod order overwrite each other just like records from plugins do in your load order, although it is a bit more straightforward here. If, for instance, Mod A contains one version of the texture Example.dds and Mod B contains a different version, the mod that is loaded lower will overwrite.

  • Mod A
    • Example.dds
  • Mod B
    • Example.dds

Things get more complicated once BSAs are added to the mix. Packed assets are by default overwritten by loose assets regardless of mod order. Let’s assume Mod C also contains Example.dds. However, it is packed in a BSA. In this case, Mod B would still overwrite:

  • Mod A
    • Example.dds
  • Mod B
    • Example.dds
  • Mod C
    • Example.bsa {Example.dds}

Assets packed within BSAs overwrite based on the load order of their plugins.

  • Plugin A.esp
    • Plugin A.bsa {Example.dds}
  • Plugin B.esp
    • Plugin B.bsa {Example.dds}

This should sufficiently demonstrate the importance of a correct mod order as well as give you a good understanding of why sometimes files are packed in archives and other times distributed loosely.

PORTING LE MODS TO SE

The vast majority of mods created for Skyrim LE (the 2011 version) can easily be ported to Skyrim SE (2016 remaster). Many of them do not in fact need any additional steps and can immediately be installed for SE.

  • Plugins must be re-saved in the Creation Kit, a procedure that may seem daunting at first but can be completed within a minute.
  • Archives must be extracted and potentially repacked. Attempting to run Skyrim SE with an active LE BSA will result in a crash on launch.
  • Textures are usually fine and can be used in SE, although some may benefit from a different type of compression.
  • Meshes can cause all kinds of issues up to and including crashes. They must be run through Cathedral Assets Optimizer.
  • Animations are usually fine but may also be run through Cathedral Assets Optimizer.
  • SKSE Plugins can be ported by people capable of recompiling and updating them in Visual Studio if the original source code is publicly available.
  • ENBSeries presets cannot be ported to SE as both the game’s as well as SE ENB shaders have changed.

All other file types, such as scripts, sounds, and interface (shockwave files) are generally safe to be used in SE.