How to Make a Successful Mod

(or, at least, one that sucks a lot less)

A guide by

Headbomb

Version 1.7.0
15 February 2012
Table of Contents
TABLE OF CONTENTS......................................................................................................2
PREAMBLE....................................................................................................................3
WHAT IS A SUCCESSFUL MOD?..........................................................................................4
DO YOUR RESEARCH.......................................................................................................5
FOLLOW THE UNIX PHILOSOPHY.......................................................................................6
RECOGNIZE THAT OTHER MODS EXIST.................................................................................7
TAKE YOUR TIME, BE SYSTEMATIC.....................................................................................8
TEST YOUR MOD............................................................................................................9
IF IT DOES NOTHING, IT PROBABLY SHOULDN'T BE THERE.....................................................10
DON'T CHANGE THE .ESP FILE NAMES FOR NO REASON.........................................................11
COMPRESS YOUR TEXTURES AND MESHES PROPERLY...........................................................12
UNDERSTAND HOW .ESP AND HOW .BSA FILES WORK...........................................................13
KEEP UP WITH PATCHES (OFFICIAL OR NOT).......................................................................14
PENSEZ AUX FRANÇAIS / THINK OF THE FRENCH...............................................................15
MAKE USE OF THE NEXUS MOD MANAGER.....................................................................16
WTFM – WRITE THE "FINE" MANUAL...........................................................................18
MAKE YOUR MOD EASY TO FIND.....................................................................................20
NEXUS VS STEAM VS OTHER SITES................................................................................21
DON'T BE AFRAID TO ASK FOR HELP.................................................................................23
USEFUL STUFF.............................................................................................................24
CREDITS AND OTHER STUFF............................................................................................25
Preamble
First some background. I'm a new pretty modder on the Nexus scene. I have always modded my
games, way back to when I was playing Duke Nukem 3D, but I have never released my own mods
until very recently. While I'm no expert on the inner workings of everything, I'm also not a complete
idiot.

Some of my mods are quite popular, such as Better Sorting. Other not so much, such as Forksassin.
As of this version of the guide, I have a total of fives mods on the Nexus:

• Better Sorting
• Complete Crafting Overhaul
• Forksassin
• Smithing Perks Overhaul
• Weapons and Armor Fixes

I will be using those as an example throughout the guide because I am familiar with them, and I'll
mention a few others, but I'll try to keep criticism to my own mods (or hypothetical ones) so other
modders do not feel insulted. Bare in mind that my mods are by no means perfect, and some of
them do not even follow my own advice.

Most of what I write in this guide will be plain old common sense, and nothing should be
particularly surprising. But some things covered might be stuff you just never thought of, especially
if you are new to modding, never worked on large-scale projects, or never thought about the long
term future of your mod (e.g. what happens to your mod when you stop maintaining it).

The guide is written in the context of Skyrim modding, but it will be equally relevant to any TES or
Fallout games released since Morrowind, and the general principles outlined apply to pretty much
any game out there, from Diablo II to X3 to Unreal Tournament.

I welcome feedback and suggestions, and will try to update this guide to be as useful as possible.
What is a successful mod?
The definition of a successful mod is somewhat subjective, as it depends on your view of success.
For some, this is the number of downloads. For others, it is whether people who use it universally
like it. For the purpose of this guide, I will use the following definition:

A successful mod is a mod that

1) Has a well-defined scope, and does not stray outside of it

2) Does what it claims to do well
3) Does not conflict with other mods outside of its scope
4) Does not force the user into giving up other mods
5) Is well-documented enough to still be usable in 5 years
6) Keeps up with the latest version of the game and the latest unofficial patches

It does not matter if the mod tries to change how blocking works, or turn everyone naked.
Following those six principles as much as possible will make your mod more successful than if you
did not follow them. The words as much as possible are important here, because sometimes it will
just not be possible to make your mod compatible with everything. You must then decide what is
more important between two equally important things, doing what you want, and respecting users
freedom of choice.

The former is important, because it is your right as a modder to create mods that follow your
"artistic vision", for lack of a better term. The later, because it is their right as users to use other
mods. If you design mods without any concerns for compatibility, you will be seen as inconsiderate.
On the other hand, if you try to address every compatibility problem, you will be driven mad by the
workload.
Do your research
You have an idea? Great! But before spending hours creating you mod, check out what's out there
first. This is for two reasons.

First maybe someone else already did what you had in mind. If your mod idea is already out there,
it's not the end of the world, but you don't want to step on toes. You can do a similar mod, but
releasing a mod that does the exact same thing is just asking for trouble. People will think you are
an idea thief, and redundant mods creates confusion in the long term. Additionally, since the other
mod probably has an established user base already, it will be unlikely that yours will take off.

Second, there are pretty clever mods out there. Smart modders will always check other mods to see
what they do and how they do it. It lets them create better mods, and can save them lots of work.
Follow the Unix philosophy
... a.k.a. write mods that only do one thing and do it well

Points 1 & 2 of the What is a successful mod? section are collectively known as the Unix
philosophy. In a nutshell, the Unix philosophy says write mods that do one thing and do it well. In
other words, don't create a mod that both tries to fix Smithing perks and improve weapon textures.
Why? Because some people might not agree with your texture changes, while others might not
agree with your Smithing perks changes.

You might think "yeah well that's obvious", but there are nonetheless several of those mods out
there. And you might not realize how just how subtle doing one thing actually is. Say you want to
fix one of the most problematic areas in the Vanilla game: Smithing. If you want to fix everything
wrong with Smithing, you need to fix the following things

• Fix the Smithing perks to correctly improve weapon and armor materials
• Fix the creation and tempering recipes at the forge/grindstone/workbench
• Fix the weapons and armor material assignments themselves

You might think "well this is all smithing related, so it's cool if I fix them all!" or "But I don't want
users to have to download other stuff, that's annoying". But you're wrong here. You need to do three
separate fixes

• One for the Smithing perks

• One for the Smithing recipes
• One for the weapons and armor properties

The reason for this is that several other mods will

• Change the smithing perks, to alter the game balance

• Add, change or remove recipes, to alter the game balance or add/remove items
• Change weapons properties, to alter the game balance or fix bugs

If you make three mods (or alternatively, one mod containing three separate .esp files) then users
will be able to keep what they want from your mod, and use what they want from other mods. If
you bundle everything in one .esp file, then conflicts arise, and users must choose between your
mod, and another one.

If you follow the Unix philosophy, points 3 & 4 are pretty much guaranteed to be satisfied, which
will make other people's job (such as the BOSS and Wrye Bash developer teams) much easier. And
it will both greatly enhance the long-term compatibility of your mod, and the number of people that
will use it. It's not that you must follow the Unix philosophy, it's that not following it comes at great
cost for the community in general and for your user base.

Note that mod compilations (such as Tytanis - The Ultimate Mod) and total overhauls (such as
FCOM) are exempted from following the Unix philosophy. Compilations and total overhauls pretty
much assume that users are not interested in customizing every aspect of the game, and that the
users trust the compilation/total overhaul to have included everything they need.
Recognize that other mods exist
By this I don't mean that you need to thank everyone that did similar mods to you. What I mean is
don't try to reinvent the wheel.

It's okay to have dependencies on other mods, especially on bug fix mods and unofficial patches.
Just list them as "This mod is designed to be used along with the Foobar mod by this guy [link]."
This will not only save you work, it will save you headaches.

Additionally, try to anticipate conflicts. Even if you have been extra diligent about focusing on your
scope and nothing else, other mods exist and could very well conflict with yours. At the very least,
you should browse the top 100 mods on the Nexus, as well as do basic search for mods that have
similar scope to yours, and ask yourself "If I wanted to use this mod, would mine conflict with it?"

If conflicts exist, ask yourself if can it be prevented, perhaps by changing the load order or perhaps
by making your mod a bit different. If things can be prevented by changing the load order or by
some other means, mention it in your mod's description. If conflicts cannot be prevented, also
mention it in your mod's description.

If your mod conflicts with a highly popular mod, consider making a special version of your mod
that is compatible. For example, if Forksassin conflicted with Better Sorting, then it wouldn't be
silly for me to release a "Forksassin – BS version.esp". If your mod doesn't conflict with popular
mods, that's great! Mention it in your mod's description, and use it as a selling point.

Keep in mind that in the case of mod compilations (such as Tytanis - The Ultimate Mod) or total
overhauls (such as FCOM), your job it will be extra hard to ensure compatibility, and you may want
to defer that responsibility on whoever is maintaining the mod compilation/total overhaul.

And lastly, if a mod, guide, or tutorial gave you inspiration for your own work, or helped you figure
out something about something, mention it. You'll make someone happy, and it might even help
another modder who is currently struggling with the same issues you had.
Take your time, be systematic
The best way to save yourself time is to take it slow. Does that sound silly? Well suppose you're
making a potion mod. For example, there's nothing obviously wrong with the following

• [##FORMID] (EditorID) Item name Duration

• [10101012] (Flying02) Potion of Flying (30 seconds)
• [10101013] (Flying03) Draught of Flying (45 seconds)
• [10101011] (Flying1) Minor Potion of Flying (15 seconds)
• [10101014] (FlyingIV) Elixir of Flying (50 seconds)

But it has a few problems. First by not being consistent with your EditorIDs, you make your mod
harder to review for mistakes. If you were systematic about EditorIDs, you would be presented with
this instead

• [10101011] (Flying01) Minor Potion of Flying (15 seconds)

• [10101012] (Flying02) Potion of Flying (30 seconds)
• [10101013] (Flying03) Draught of Flying (45 seconds)
• [10101014] (Flying04) Elixir of Flying (50 seconds)

This highlights an issue you might otherwise have missed. In Vanilla, the named ranks for potions
with four levels of strength should be Potion/Draught/Philter/Elixir, not Minor
Potion/Potion/Draught/Elixir. The time increments should also be 15/30/45/60 seconds, not
15/30/45/50 seconds. That is, you should have this instead

• [10101011] (Flying01) Potion of Flying (15 seconds)

• [10101012] (Flying02) Draught of Flying (30 seconds)
• [10101013] (Flying03) Philter of Flying (45 seconds)
• [10101014] (Flying04) Elixir of Flying (60 seconds)

Now if you released the version at the top, then there's a good chance that people would complain
about how your potions work, or that the Philter of Flying is missing. But there's an even greater
chance that people would just go “well this is crap”, uninstall your mod, and never come back.

If you were systematic, but didn't pay attention (i.e. released the version in the middle), then you
would have a much better chance of figuring out what the issue is with your mod after someone said
a semi-informative “I like the idea but the potion strengths are all messed up.”

If you took your time, you would not have to spend time trying to figure out the problem, nor would
you have to spend time fixing the problem, because there would be no problem in the first place. It
also makes you confident about what your mod actually does, because you know you did it right. So
if someone came to you saying “I like the idea but the potion strengths are all messed up”, you'd
know you'd be dealing with a troll, and not a legitimate complaint.

This applies to every type of mod out there, textures, meshes, potions, weapons, crafting, etc... Take
your time, be systematic, and review things (including spelling and grammar). In the end, you'll
have much less testing to do, much fewer complaints to deal with, and much fewer problems to fix.
Test your mod
Testing your own mod is a pretty obvious thing to do. However, some common mistakes are made
during testing, and there are ways to ward yourself against those.

A good practice in general (whether writing code, or creating mods) is to have at least two distinct
versions of your mod. One is the development version (in say FoobarMod\Development) and one is
the release version (in say FoobarMod\Release).

What I personally do for my mods is develop everything in FoobarMod\Development. When I think

I'm ready for action, I create a release candidate, then load the release candidate into the game. If
the release candidate works fine, then I archive a copy it in FoobarMod\Release, and release my
mod online.

How exactly you do things is up to you, but the point is that you should always test the actual files
you will release, because otherwise you might release files you assumed were up-to-date but which
turn out to be some old or untested version. As you gain experience with modding, you will
recognize that certain type of updates don't need to be tested, but you do need to make sure that
what you release is actually what you mean to release.

If your mod deals with vanilla items, or some type of crafting (alchemy, smithing, etc.), there is a
very useful location to test things in the game.

Bring up the console with ~ , and type

coc qasmoke

This is the a test room used by the Bethesda QA team, and contains chests with every item in the
game, as well as every crafting station (smelter, workbench, grindstone, alchemy table, ...).

Always create a hard save before going into the test room, because you might end there for a while,
and accidentally overwrite your quick save slot, run out of autosave slots, or have some kind of save
game mishaps.

For more on console commands, see the list of Skyrim console commands from the Unofficial Elder
Scrolls Pages.
If it does nothing, it probably shouldn't be there
As you work on your mod, you might put some stuff in, only to not need it later on. It's always a
good idea to review your .esp files with tools such as TESVSnip to make sure you didn't package
stuff you didn't mean to, especially if you used early versions of third-party tools like SkyEdit.

For example, upon inspecting one of my old attempts at a crafting mod, I noticed a GRUP tree with
no sub-entries. In TESVSnip, it looks a bit like this:

The GRUP (SPEL) at the bottom has no sub-entry.

The GRUP (SPEL) tree is empty. So why is it there in the first place? I don't know. Maybe I tried to
modify the Transmute Ore spell, only to change my mind later on. Maybe whatever tool I used had
a bug in it, and didn't properly cleanup after itself. Whatever the reason, empty trees shouldn't be
there. If you see one, get rid of it.

At this point, I would also ask myself questions such as “Did I actually change the RecipeIronIngot
entry? Or is it just there because I thought I might need it, but didn't actually modify it?” While
there are sometimes good reasons to include an unmodified Vanilla entry in a mod, 95% of the time
they will be useless leftovers from development, and will create conflicts for no reason.
Don't change the .esp file names for no reason
New modders will often change the .esp file names because they didn't like the old names, or want
the name of the .esp file to reflect the version of the mod. So over time, you can have something
like

• Nuclear Arrows.esp
• Bob's Mod – Nuclear Arrows.esp
• Bob's Mod – Nuclear Arrows version 2.esp
• Bob's Mod – Nuclear Arrows v3.0.esp
• Bob's Mod – Nuclear Arrows v3.1 [fixed Nuclear Orcish Arrows].esp

Bob is thinking this will make things clearer for people, as the version will be explicit.

PLEASE DON'T DO THIS

Keeping the same name for the .esp files will make the job of the BOSS and Wrye Bash developer
teams much easier. BOSS and Wrye Bash are utility programs that will arrange the loading order for
mods, so that the chance of conflicts is reduced (which in turn means you have fewer compatibility
questions to answer). Every time you change the name of an .esp file, the BOSS and Wrye Bash
teams need to update their .esp file compendium. You might not think this is very important, but
consider that BOSS and Wrye Bash have respectively been downloaded over 600,000 and 700,000
times on TES Nexus alone (which more or less represent Oblivion-related downloads).

This does not mean you should never change the names of your .esp files, but if you do change
them you should have a better reason than just “it's a different version, so I'll change the name”. The
best way to track the version of your mod is by updating the “version” field of your mod on the
Nexus. If you do that, tools like the Nexus Mod Manager will automatically let people know if their
version is out of date, and the BOSS and Wrye Bash teams will have a much easier job. Which in
turn will make your own job easier.

So before you release a mod, take some time to think of a good .esp file name, and pay attention to
spelling, spacing and capitalization. This is especially important if you have a mod with
multiple .esp files, or a series of mods designed to work with each other. If this is the case try to use
a common base name for them.

Good Bad
Bob's Mod – Nuclear Arrows.esp Bob's Nuclear Arrows.esp
Bob's Mod – Nuclear Armors.esp Nuclear Armors by Bob.esp
Bob's Mod – Nuclear Weapons.esp Nuke Weapons.esp

Changing .esp file names because you want to create a naming convention for your files is okay.
Just don't change the convention every week. Let the BOSS and Wrye Bash teams know about
your .esp file name changes, and your mod will not be left in the dust. All you need to do is leave
them a comment with the old and new .esp file names names, and they'll take care of the rest.
Compress your textures and meshes properly
Now, I know just about nothing about texturing and modelling. But I do know one thing, many
mods out there do not make good use of texture compression and mipmaps, and will have meshes
that have way too many nodes for no real reason.

It might run it just fine on your computer. But remember that it's not everyone that has a top-of-the-
line PC, and that after a while all the little things start to add up, and will tax even the most
powerful of systems.

Because I know next-to-nothing on textures, I will defer to Martigen's excellent thread on the issue

[!] If you've released a texture mod, or plan to, please read – Martigen (8 January 2012)

It contains detailed explanations of texture compression algorithms, explanations on the use of

normal maps, and several links to useful resources for texture artists.

As for mesh artists, there is a little tooled called PyFII which contains several algorithms to
automatically optimize .nif files and meshes. I'm again no expert on the situation, but presumably
this stuff would make sense to you (it was easy to use in Oblivion, how well it works on Skyrim).
There is also some tutorials on the Bethesda wiki

Category:Graphics

But those might be outdated.

If someone has additional advice for texture/model artists, feel free to mention it the comment
thread, and I'll incorporate it as best I can (with credits, of course).
Understand how .esp and how .bsa files work
Since someone else already made a guide on .bsa and how they work, I'll save myself the trouble
and give you the link instead of trying to re-invent the wheel.

• BSAs and You by Lojack

It really is detailed and thorough, and you should at least read it once.
Keep up with patches (official or not)
As time progresses, Bethesda will update the game to include bug fixes and other tweaks. You
should try to keep up with these updates as much as possible. For example, here's a fictitious time
line for the Greater Ward spell, involving an Official Update from Bethesda, and Better Sorting
[who's only purpose is to rename the spell so it sorts better].

• 2012 January 20 – Vanilla Skyrim

• [0211F0] – Greater Ward [Cost 43]
• WardConcSelf50 [Mag 80, Area 0, Dur 0, Cond 0]
• ShieldConcSelf [Mag 80, Area 0, Dur 0, Cond 0]

• 2012 January 20 - Better Sorting v 2.04 is released

• [0211F0] – Ward. II
• WardConcSelf50 [Mag 80, Area 0, Dur 0, Cond 0]
• ShieldConcSelf [Mag 80, Area 0, Dur 0, Cond 0]

• 2012 February 28 – Vanilla Skyrim updates

• [0211F0] – Greater Ward [Cost 43]
• WardConcSelf50 [Mag 50, Area 0, Dur 0, Cond 0]
• ShieldConcSelf [Mag 50, Area 0, Dur 0, Cond 0]

• 2012 January 28 - Better Sorting v 2.04 [not yet updated]

• [0211F0] – Ward. II
• WardConcSelf50 [Mag 80, Area 0, Dur 0, Cond 0]
• ShieldConcSelf [Mag 80, Area 0, Dur 0, Cond 0]

If I don't keep track of the Vanilla game's update, using my mod will undo the bug fix from
Bethesda, because I based it on a prior version of Skyrim.

So whenever Skyrim gets an official update, it's a good idea to read the patch's changelog and
inspect Update.esm to see if it affects anything your mod touches. If it does, you should update your
mod accordingly.

On top of the official patches, there are a few other bug fixes you should keep track of. The most
important one being the Unofficial Skyrim Patch (USP) whenever it will be released [I'll update the
guide with a link when it's out], which will be relevant to nearly all modders. People dealing with
weapons or armors mods [including crafting mods] should keep an eye on Weapons and Armor
Fixes [this stuff should eventually end up in the Unofficial Skyrim Patch however].

Lastly, the bug fixes category on the Nexus contains a few other bug fixes which might be relevant
to you. It's not a very active category, and it will become mostly irrelevant as bugs get squashed by
either Bethesda or the Unofficial Skyrim Patch team, but you should check it out at least once to see
what's in there.
Pensez aux Français / Think of the French
... or the Germans, or the Russians, or ...

There are ways to make your mod localization-friendly. Unfortunately, at this point, I'm completely
unfamiliar with them. All I know is that the Skyrim String Localizer tool is supposed to help with
that. The Creation Kit probably has localization options, but I have not yet investigated them.

I'll update this guide with more information on localization in the future. Alternatively, if someone
wants to write this section for me, I'd be more than glad to incorporate it in the guide (with credits,
of course).
Make use of the Nexus Mod Manager
The Nexus Mod Manager (NMM) is really an amazing thing for both newbies and experts modders
alike. It lets people manage mods, it keep tracks of mod updates, it automatically creates backups of
files, keeps track which mods owns which files, and a lot more stuff. There's no real reason to not
take advantage of it, and it shows incredibly poor consideration to make NMM-incompatible mods,
especially for the simpler mods.

The simplest, most standard, and least error-prone way to take advantage of NMM is to build your
archive so that everything gets put into the correct place if you extract stuff directly in the ...\
Skyrim\Data folder. That is, package your mod so the files are located in, e.g.

FoobarMod.rar (Meshes\Actors\Character\Animations\foobar.hkx)
FoobarMod.rar (Meshes\Actors\Character\Animations\barfoo.hkx)
FoobarMod.rar (Textures\cubemaps\foobar_e.dds)
FoobarMod.rar (Textures\cubemaps\barfoo_e.dds)
FoobarMod.rar (FoobarMod.esp)

Another way to do things, but which is more error prone, is to build your archive so that everything
gets put into the correct place if you extract stuff directly in the ...\Skyrim folder.

FoobarMod.rar (Data\Meshes\Actors\Character\Animations\foobar.hkx)
FoobarMod.rar (Data\Meshes\Actors\Character\Animations\barfoo.hkx)
FoobarMod.rar (Data\Textures\cubemaps\foobar_e.dds)
FoobarMod.rar (Data\Textures\cubemaps\barfoo_e.dds)
FoobarMod.rar (Data\FoobarMod.esp)

However, this second method is not as reliable, and will only work for the \Data folder. That is, if
you use this method and build your archive as follow

FoobarMod.rar (Data\Meshes\Actors\Character\Animations\barfoo.hkx)
FoobarMod.rar (Data\Textures\cubemaps\foobar_e.dds)
FoobarMod.rar (Data\FoobarMod.esp)
FoobarMod.rar (injFX_Shaders\sepia.h)

the sepia.h file will be extracted to ...\Skyrim\Data\injFX_Shaders and not to ...\Skyrim\

injFX_Shaders as you would expect.

If your mod is not compatible with both extract-and-forget methods mentioned above, you can
always disable the option to download/install the mod with NMM on the Nexus, and force people to
install things manually. But remember that if you do this, you will need to make your installations
instructions extra clear, people will not be notified of new versions, and you will get a lot more
questions (especially from Aunt Jenny).

However, not all is lost for those who still wish to make their mod as user-friendly as possible.
NMM supports installation scripts written in XML (like Better Sorting) or C# (like SkyUI). These
scripts let you control every aspect of the installation, and will let you put files wherever you want,
including in the ...\Skyrim folder itself. It also means that Aunt Jenny will much less likely to bother
you.
XML scripts are easy to write, even for those with little-to-no programming experience, and will be
sufficient for all but the most complex of mods. Just follow the excellent Guide to FOMOD
Scripting by nyrb. If you are familiar with C#, then you hardly need a guide on this. Although if you
really want one, there is always FOMM and FOMODS for Dummies by Zumbs.

If you need a simple example to help you understand things, you can inspect my own Forksassin. If
you want something a bit more complex, but still simple enough to be understood with a little
patience, try Better Sorting.

Also, while we're on the topic of packaging, here's some additional remarks.

If you include a readme, avoid naming it README.txt or ReadMe.txt or some variant. Many many
other mods will also name their readme this way, which means that your readme will likely
overwrite another readme, or be overwritten by one. Instead, name your readme something like
Readme – FoobarMod.txt.

It's also a good idea to have the readme extract to a ...\Skyrim\Data\Readmes folder, in order to
reduce clutter in the ...\Skyrim\Data folder. Likewise if you include screenshots, you can also make
those extract to a ...\Skyrim\Data\Screenshots folder. If you'd rather have all non-essential files be in
their own dedicated folder, that's fine too. I suggest using something like ...\Skyrim\Data\
FoobarMod Extras.
WTFM – Write the "fine" manual
... 'cause people can't RTFM if you didn't WTFM

Sooner or later, you will run into people who aren't telepaths and will not be able to magically read
your mind and figure out some of the stuff you think is obvious. This is why you need to document
your mod. No one ever lost time writing a comprehensive manual. Every minute you spend writing
the manual is ten minute less you need to spend answering questions. So if you are lazy, it's in your
own best interest to spend time on the documentation.

Good documentation

• Gives a description of what the mod does

• Gives a list of required and/or recommended mods
• Gives a list of instructions on how to install/uninstall it (both via the Nexus Mod Manager
and manually)
• Mentions mods that will (or likely will) conflict with your mod
• Has a list of mirrors
• Has a change log

Remember, the more details you put in the description/instructions/etc... the less questions you'll
get. And remember, once you move on (either because you got killed by ninjas, or just stopped
caring about your mod), the only thing people will be able to rely on is your documentation. So
make it good.

Great documentation goes a step further, and also give

• Reminds people to RTFM before asking questions

• You want this as close the top of the description as possible
• Gives a description of what the mod does not do
• Gives a list of mods that aren't required and/or recommended
• Mentions mods that will not (or likely will not) conflict with your mod
• Gives answers to questions that tend to show up the comments
• Thinks of Aunt Jenny (more on this below)

Many people forget this second part, and consequently get flooded with comments and private
messages about whether their mod is compatible with some other mod, or about questions already
answered in the documentation. Especially questions from Aunt Jenny. You might be telling
yourself that no aunt of yours is named Jenny, so why should you care about her? Well I'll tell you
why.

First you have an Aunt Jenny. Every modder, programmer, or even the person doing tech support for
eating bananas has an Aunt Jenny. Aunt Jenny is the person that comes to you and complains her
toaster is broken and won't toast her toasts. She will assure your she tried everything, and that she
even called her nephew who is a certified toaster technician and he couldn't figure things out. Aunt
Jenny's problem is also fixed by telling her to make sure her toaster is plugged in before she tries it.
But if Uncle Steve isn't around, she might not know how to plug it in correctly, and will come back
to you saying the toaster's plug doesn't fit in the wall outlet. This might be because Aunt Jenny is
just plain stupid, but it might also be that your mod just sounded so awesome that she decided to
step into the modding world for the first time, and is a complete newbie.

What this mean in practical terms is if you say "Installation with the NMM is recommended", don't
assume that Aunt Jenny knows what NMM is. Writing "Installation with the Nexus Mod Manager is
recommended" is better. But if you just did that, you forgot that Aunt Jenny doesn't know how to
use the search bar. Find the Nexus Mod Manager yourself, and give a link. "Installation with the
Nexus Mod Manager (which you can download here) is recommended." Aunt Jenny also doesn't
know how to enable her mods. So tell her how, or alternatively, link to a video tutorial on YouTube
(of which there are plenty by now).

Just as no one ever lost time writing a comprehensive manual, no one ever lost time assuming users
were completely ignorant and/or stupid. You will never be able to make documentation that is
completely idiot-proof, of course, but you can make it so that it will take a master idiot to screw up.
And, if you're lucky, natural selection will have kicked in before they figure out how to send you a
message.
Make your mod easy to find
If people can't find your mod, then it's obvious that they won't be able to enjoy it. There's a few
things you can do to make sure that people find your mod.

Pick a good name for your mod. A good name should be short and to the point. If people can't figure
out what your mod is about in 5 seconds, they'll shrug it off as just another random mod.

• Bad name: Headbomb's Mod (or similar)

• Okay name: Headbomb's Inventory Cleaner
• Good name: Better Sorting / Inventory Organizer / Inventory Sorting

Pick a good mod category on the Nexus and use tags. This lets people browse things by the mod's
topic.

• Categories can be selected by editing the mod description. There is a drop-down menu for
categories somewhere in there.
• Tags can be added via the tags tab of your mod [illustrated below]

The tags tab

Also consider advertising your mod in a few places on the Internet. It's really not a isn't a silly thing
to do. Popular places to do so include

• Bethesda modding forums – Do not spam them however. Create one thread, and do not
bump it more than once per major update.
• Friends – If your friends play Skyrim, why not mention your mod to them? Frequent an
Internet forum, why not mention it there?
• Social Media – Twitter, Facebook, forum signatures... The world is your oyster.
• YouTube – Why not make a video showcasing your mod?
Nexus vs Steam vs Other Sites
Now that the Creation Kit has been released, and I've had some familiarity with it, I can offer some
opinion on the strengths and weakness of these various hosts.

By far the best place for modders to upload their mods is the Nexus (skyrim.nexusmods.com). So
whatever you do, I implore you, please upload your mod on the Nexus. Here are the big reasons
why (on top of those mentioned in the BSAs and You thread by Lojack).

The first is that people can use the Nexus Mod Manager. It's importance really cannot be under-
emphasized. Not only does NMM notify you of updates, but unlike Steam/Steam Workshop, it does
not shove them down people's throats, which can cause conflicts that could be avoided by sticking
to an older version. As sexy as an install-and-forget may sound for newcomers, IT IS NOT A
GOOD THING when it comes to mods.

For example, NMM will manage several types of conflicts. When two mods modify the same file
[for example in a re-texturing mod], it will ask people which mod they want to win. Meaning if
someone wants your mod, but it conflicts with another mod they like, they will be able to pick and
chose which part of both mods they like best. The alternative will often be 'yeah screw it I'll just
keep using what I have installed', and instead of enjoy 85% of your mod, they will enjoy 0% of it.

You can also customized the load order with NMM, meaning that if your mod needs to be loaded
after another mod for it to work properly, this is possible to achieve. As far as I can tell [people are
welcomed to correct me if I'm wrong], Steam loads mods either alphabetically, or by time of
download, both of which are just terrifyingly abysmal methods that are pretty much guaranteed to
make any game implode after 5-6 mods are installed.

Another thing to consider is that on the Nexus, you can package files how you want and how they
should be. Mods that do not requires .esp files (e.g. texture mods) can be free of .esp files. This is
especially important since [as of writing] Steam will only lets people subscribe to 50 mods. While it
may sound like a lot, it really is a small number. I don't consider myself to have a heavily modded
game, and I have about 60 installed. Back in Oblivion, I easily had over 300. The game can
normally only handle 255 .esp files, and while most people will not reach that limit, many do, so it's
pretty important that people don't create .esp files for mods that don't require them.

Additionally, Steam only lets you upload one .esp at a time. On the Nexus, you can bundle
several .esp files into one download. As of writing, Better Sorting has 15 .esp files, of which up to 8
should be installed. On Steam, I'd have to manage 15 different uploads, with 15 different feedback
threads, instead of have it centralized in one place. People would have to browse 15 different mods,
and figure out which of the 15 they'd want installed. That's not very mod-author friendly, nor is it
user-friendly.

Also, when you 'unsubscribe' from a mod on Steam, it does not uninstall the mod. All it does is de-
activate the .esp and will not automatically update the mod from now on. The files remain there,
even thought most people would expect it to uninstall the mod. Which makes it pretty hard to
determine if you just told the game to not load the .esp, or unsubscribed from the mod.

What this means is that people who aren't intimately familiar with mods will be able to install them
properly on the Nexus, but will likely run into problems on Steam. And if you tell them “my mod
should be loaded after this other mod”, people will be able to use both. You might think “I want my
mod to be as simple to install as possible, Steam offers a one-click install, so that's the best place to
put it, no?” Well, thhe thing is, you can already have one-click installs. That's what the Nexus Mod
Manager does. And unlike Steam, NMM it does it right, without sacrificing customization or user
freedom, and does not force you into packaging a mod into a one-size-badly-fits-all format. Plus the
Nexus lets people install their mods manually if they so choose, or repackage them according to
their taste (and many expert modders will prefer to do it this way).

Now I'm not telling you to not put your mod on Steam. But if you make your mod a Steam-
exclusive, be aware that several people will not use your mod because they know Steam will not let
them mod their game the right way (as explained in the previous paragraphs). And several gamers
have a general hatred of Steam [I'm one of them, I only use Steam because I have to]. But what I
said above it not tainted by bias. Those are indisputable facts. I want to put my mods on Steam,
because many people do like Steam. But Steam doesn't let me do it properly. So I probably won't
upload most of them, if any.

So what are the appeals of Steam, if any? Well simply put, Steam has the Aunt Jenny crowd and lots
of visibility. Everyone playing Skyrim, legitimately at least, has Steam installed. Not everyone goes
to the Nexus. This means by sheer numbers, Steam has more people.

However consider the fact that The Elder Scrolls series is so successful on PC because of mods.
TES is an old and established franchise, and the only ones who don't know that TES is synonymous
with mods are Aunt Jennies (newbies, recent console converts, people who think modding Skyrim is
like modding Team Fortress, etc.. which is not a crime, we all have to start somewhere). Aunt Jenny
wants Steam, because that's what she's been spoon-fed by the gaming press. And Steam sounds
good. But Steam doesn't do things right, so what Aunt Jenny actually needs is the Nexus (and the
Nexus Mod Manager, which [again] you should mention at the top of your mod's description, with a
link). The millions of already-existing mod users know that the Nexus does things right, and that
will be their go-to places (it has over 3 million registered users!), and once the hype about TES
modding is over, the hardcore modders will remain active on the Nexus, while the Steam-using
casual modders will have moved on, and your Steam exclusive will be forgotten.

If you upload a mod to Steam, I would suggest using a different .esp name for it, such as 'Foobar
Mod – SW version.esp' to prevent problems from happening.

Now I haven't talked much about the other sites like TES Alliance or Planet Elder Scrolls or
whatever, but that's mostly because I don't use them (or at least haven't used them in years). I have
no idea if they are good or bad, but as they are more traditional hosting sites, it will at least be
possible to package things right, offer customization options, etc... You will not get the benefits of
the Nexus Mod Manager, but you will also not have any of the drawbacks of Steam either. You
should at least consider them as mirrors, and it's always a good idea to host mods in more than one
place. This way if your host goes down, people can still get your mod.
Don't be afraid to ask for help
Some people are afraid to ask for help for some reason (pride usually). And those people really
ought to! If you're stuck and don't know where to go or what to do, just ask for help. Maybe the
answer won't help you, maybe no one will answer. But maybe you'll save yourself hours if not days
of frustrations by stepping over your pride.

There are several places that modders can ask questions, particularly in the Skyrim Mod
Troubleshooting forum, and there's a few other links in the Useful stuff section on the next page.

You can also try to contact mod authors directly to ask how they did something, or if they have
suggestions for you. Most will try to help, but if they don't reply or don't know the answer to your
problem, just ask someone else. Whatever you, DO NOT harass mod authors constantly with
messages like "I sent you a message but you didn't reply!" or similar. People have lives to live, and
they might not be around. Or maybe they just don't care about solving your problem, and that's
entirely within their rights.

In case you are wondering, I'm including myself in the category of "people not interested in being
your personal information centre". I'm not saying this to be rude, but consider that you aren't the
only person to come across this guide. See the number of unique downloads for a good estimate of
how many people read this guide. Now imagine if even one-in-twenty people had questions, and
they all thought I could answer them because I wrote the guide.

I will update this section with additional links based on other people's suggestion.
Useful stuff
Nexus Mod Manager
• Nexus Mod Manager

Guides
• Advice on Texturing by Martigen
• BSAs and You by Lojack
• Developping Succesful Mods by LHammonds
• FOMM and FOMODS for Dummies by Zumbs.
• Guide to FOMOD Scripting by nyrb
• How to Make a Successful Mod by Headbomb
• Comment thread

Tools
• PyFII
• SkyEdit
• Skyrim String Localizer
• String Maker
• TESVSnip

Other Resources & Tutorials

• Creation Kit wiki

• Creation Kit forums
• The Elder Scrolls Construction Set Wiki
• Category:Graphics
• Files > Skyrim > Modder Resources & Tutorials
• Files > Oblivion > Modder Resources & Tutorials
• Unofficial Elder Scolls Pages
• Skyrim:Console
• Tes5Mod:Tes5Mod
Credits and other stuff
• Everything in this guide was written and edited by Headbomb
• You can find the most up-to-date version of How to Make a Successful Mod on the Nexus.
• If you can't click on the link, try copy-pasting
http://www.skyrimnexus.com/downloads/file.php?id=6882
in your web browser
• I always welcome feedback and suggestions