TES Files

Esms and Esps

Esm and Esp files ("TES files" or "mods" for short) are the core data files of Tes4 (Oblivion). A TES file is basically a database of all of the data for the world, including object data, dialogue, gameplay settings, object placements, AI settings, landscape, script commands, cells, etc. Basically everything that goes into the construction set (CS or TESCS) is stored in TES files.

(However, not all game data files are TES files. Textures, meshes, sounds, videos, etc. are all part of the full game. More about these files elsewhere.)

The two types of TES files (esm or "master" files and esp or "plugin" files) are largely identical in format, but have some important disctinctions in practice. The main practical difference is that TESCS will not create esm files. Nor will it allow esp files to modify other esp files. However, both of these limitations can be overcome by using outside tools, and both user made esms and esp-mastering are common in today's mods. (For more info, see Esp vs. Esm.) In practice, esp files are easier for modders to create and are usually the preferred format for released mods.

Masters

Both TES files ("mods" from here on) and savegames have masters. The masters of a given mod or savegame is simply the list of "parent" mods that the mod or savegame depends on. The masters of a mod can be seen in the TESCS details view, while the masters of a savegame can be seen in the details view for each save in Wrye Bash and OBMM. There is little distinction between mods and savegames in this manner, except that mods will usually not have other mods as masters.

Masters lists are important because they help identify where objects in a mod or a savegame come from. I.e. when a savegame remembers an object, it essentially remembers it as something like "the 2,034th object defined in my fourth master". If the master list were somehow to be erased, then the savegame would lose the ability to match the object in the player's inventory with original object defined in the mod.

In regular gameplay, it's not really necessary to know about masters, but modders need to understand them, since gameplay debugging often requires working with formids, and formids are the way the game encodes information like "the 2,034th object defined by my fourth master". (For more info, see Formids.)

Records and Overrides

As mentioned before, a mod file is basically a database of all the objects in the gameworld. To be more specific, the mod file is a collection of records. The records in a given mod are mixture of 1) new records, and 2) modifications of existing records (i.e. of records defined by the mod's masters). E.g. "Wicked Swords.esp" might introduce three new swords, as well as modify two existing swords defined by Oblivion.esm. Each of these swords is represented by a single weapon record (so 3+2 = 5 records in total).

The important thing about records is that each record is a single indivisable object as far as TESCS and the game engine are concerned. Thinks of the game world as a table with stacks of playing cards. You can add a new card, or you can override an existing card by putting a new card on top of it. So, in the example above, the three new swords form three new stacks, and the two modified swords go on top of existing stacks overriding the original cards/swords/records

Now, suppose that there's a second mod "Beautiful Swords" which adds two new swords and redefines four swords from oblivion to be more "beautiful". Suppose that of these four overridden swords, one conflicts with an override done by "Wicked Swords" -- i.e. they both try to change the same sword.

Again, this is just like the card game. The two new swords form two new stacks, and the four redefined swords go on top of existing cards, overriding them. But in this case, one of those cards goes on top of the card added by Wicked Swords -- thus overriding its changes as well as as original Oblivion.esm sword/card. Note in particular, that they changes are not merged. Each newly added card/record completely replaces the card/record under it.

Load Order

The card game above is why load order is important. Load order determines the order in which mods lay their cards down on the table. Oblivion goes first, then the next mod in load order, up to the last mod. Whenever two mods conflict, the later loading mod will win.

And as for the order, its fairly simple: Esms always load before esps. Then within both groups (esms and esps), files are ordered by modified date. I.e. esps always trump esms, newer esps trump older esps, and newer esms trump older esms.

So if you want to change load order, you just need to change the modified date of the mod. Unfortunately, you can't do this directly in Windows, but tools like OBMM (Oblivion Mod Manager) and Wrye Bash will do it for you. (Note: You cannot set load order with the Oblivion Launcher -- in fact the Oblivion Launcher does not (usually) show load order -- rather it usually shows mods in alphabetical order.)

Records Merging

Of course for complicated records (e.g. leveled lists, race records and many more), the "last card dealt wins the stack" rule is pretty annoying. Hence, a number of tools and techniques have been developed to get the best of both worlds -- i.e. to have swords that are both Wicked and Beautiful. The primary tool for this is Wrye Bash's Bashed Patch, which automatically merges a number of types of changes to records. In addition, manually created patch mods (built using Bash, Tes4Gecko and Tes4Edit) are available for many complex mods. (E.g. FCOM is essentially a massive patch mod that merges changes from the four major patch mods (plus many more smaller mods)).

Summary

This has been a fairly complicated introduction, but just remember the the game engine is effectively playing a game of stacked cards. And when you create a mod, you're simply creating a hand of cards that will be played in that game. From that ending table, with its various stacks of cards, arises the gameworld that the player enters and lives in.