Formids for PlayersEdit
In Oblivion, all objects (a book, a race, a spawn point, a spawned npc) are identified by formids. Formids are eight digit hexadecimal numbers (e.g. 0A012C43), where the first two digits represent the source mod and the following six digits are the object index.
While playing, you can usually find the formid of any visible object by opening the console and clicking the object. The object's formid will display at the top of the screen.
Note that there is a difference between the object definition and a placed instance of that object. For example the definition ("base object") of the NPC Palonirya (proprietress of "Divine Elegance" in the IC Market District) is 00015ea8, while her placed instance ("reference") is 0002c164. When you click on an object in the game, what you'll see is the formid of the placed instance (e.g. 0002c164 for Palonirya).
Construction Set vs. In-Game FormidEdit
In the construction set (CS), you'll find the formid in the second column of the grid display of most windows. Note that this column is usually collapsed -- i.e. you'll need to widen the column to actually see the formid. For placed references, the easiest way to find the formid is to double click the reference in the cell view window -- the resulting dialog will list both the reference formid and the base object formid.
Note that the modindex may vary between CS and game. In both cases, the modindex represents the order of the source mod in the current context. E.g. the Boots of the Crusader from Knights of the Nine is 01000ecf in the Construction Set, but in game might be it 0A000ecf, if KOTN is the 10th mod loaded after Oblivion.esm.
Note too that objects that specifically belong to the savegame and not to any mod are given the modindex FF. You'll actually find these quite commonly: all spawned npcs and creatures, plus all items initially acquired out of inventories and containers, plus all items created in game (spells, potions, enchanted armor and weapons) will all have modindex FF.
CS Formid to In-Game FormidEdit
If you know the CS formid and need to know the in-game formid, then you need to replace the CS modindex with the in-game modindex. In other words, you just need to find the modindex of the source mod (e.g. Knights.esp), while you're playing. Here's how:
- Find an object that you know was placed by the source mod. E.g. for KOTN, both the prophet and the Priory of the Nine are placed by the mod, so if you console-click on either of them, then the first two digits of their formid is the modindex.
- If you're running Oblivion Mod Manager, the modindex will be shown when you mouse-over the mod in the main mod listing. (Mistakenly labeled as "formid" in the popup info box.)
- If you're running Wrye Bash, the modindex for all active mods is listed in the second column of the Mods tab.
- Oblivion.esm is always first (has modindex 00) in both the CS and in-game. No conversion is necessary.
- If a mod has multiple masters (e.g. Oblivion.esm, Cobl Main.esm), then objects coming from the mod itself will have their modindex shifted upwards in the CS, however the techniques above will still work with no change. (This complexity is something that only toolmakers and advanced modders need to worry about.)
- This mod can be used to determine in-game FormID for items, object, NPCs.
For folks who don't know what a hexadecimal number is... Okay, decimal numbers go like this: 0 1 2 3 4 5 6 7 8 9 10 11..., while hexadecimal numbers go like this: 0 1 2 3 4 5 6 7 8 9 A B C D E F 10 11 .. 19 1A 1B ... etc. Hex 'A' equals decimal 10, hex 'B' equals decimal 11, ... hex 'F' equals decimal 15. Since hexadecimal is base 16 ('hex' = six +'deci' = ten), they "roll over" at 'F' (= 15 decimal), the same way that decimal numbers roll over at 9.
Formids for ModdersEdit
This section is intended for modders only. It provides a bit more detail than the players section and addresses some other advanced topics.
ModIndex and ObjectIndexEdit
Formids have two components: the first two digits are the modindex, and the following six digits are the objectindex. The objectindex for any data object in your mod is unique and fixed within the mod -- i.e., once it's assigned to the object, it will not change no matter what you do to the object.
The modindex represents the load position of the source mod for the data object, and it will change depending on context. Typically in CS4 the modindex for any data object that you create will be '01', since your mod is typically the second to load (after Oblivion.esm, which has modindex '00' because it loads first).
In-game, the modindex will reflect the load position of your mod. E.g., if your mod loads fifth, then the modindex will be '04'. (Oblivion.esm loads first, and the modindex numbering is zero based (0, 1, 2,...), so Oblivion's modindex will remain '00'.)
Note: The modindex of a data object in CS4 is the native modindex. The modindex of that same data object in-game is the in-game modindex.
CS4: If, while editing your mod, you change one of Oblivion's data objects rather than creating a new one, then no new formid will be created. Instead, the formid recorded in your mod file will be the same as Oblivion.esm's formid. This is how the game knows that your data object is replacing the data object from Oblivion.
In-Game: If you pick up an already existing object while in-game, that picked up object will retain its original formid. And if you later drop it and click on it, you'll continue to see the original formid.
If a new object is created in game, then it will be assigned modindex FF (i.e., 255, i.e. the last 'slot' available). New objects are created if you buy an item from a merchant or pull an item out a container.
Formids vs. EditorIdsEdit
EditorIds are the plain text ids of data objects (e.g., 'BearPelt01'). While these are what you'll usually think of and be concerned with while editing, they're really just aliases (nicknames) for formIds, which are the true identifiers of data objects.
For example, if you change the 'BearPelt01' to 'BearPeltO1x' (without creating a new formid), you're just changing the alias -- and only so far as your mod is concerned -- as far as other mods are concerned, the alias is still 'BearPelt01'.
Note that although you can change the editor id of a data object, you cannot change the formid. And changing the EditorId has very little effect on the mod, since internally, references to data objects are stored as formids. Again, note that changing the editor id in your mod, does not effect the editor id in other mods.
Scripts provide a nice illustration of EditorId vs. formid: If a script says something like "player.additem BearPelt01 1", then the compiled script will actually add item '000228E3' which is the formid corresponding to 'BearPelt01'. (In fact, you can write the script using the formid directly instead of the editorid.) In game, script commands will generally not accept EditorIds -- instead you must enter the formid itself.
Reference vs. Base FormidsEdit
For objects placed into the game world there are two formids: the reference formid or RefID (associated with that particular placed object), and the base formid or BaseID (used for all versions of that same object).
The BaseID provides the information that is common to all instances of that object. For example, every copy of the book On Oblivion has the same BaseID (
0002457E); that BaseID record contains information such as the weight, value, appearance, and text of the book. The specific type of record used for the BaseID depends upon the type of item. For example BOOK, WEAP, NPC_, and CREA are all records used exclusively for BaseIDs. In the Construction Set, all of the formids listed in the "Object Window" are BaseIDs. Most formids provided on this site are BaseIDs.
The RefID provides access to information such as the object's location. There are only three types of records used for RefIDs; the specific type of record depends upon the object:
- For NPCs, a ACHR record is used.
- For creatures, a ACRE record is used.
- For all items, a REFR record is used.
In game, when you console-click on a placed object, the formid that you will see is the RefID, not the BaseID. In the CS, when you look at objects in the "Cell View", the IDs are all RefIDs; if you edit the object, the BaseID is provided under "Base Object" (and "Edit Base" allows you to edit it). When RefIDs are provided on this site, they are explicitly identified as RefIDs.
Mod Conflict and IsolationEdit
Formids were introduced for several reasons, but a main reason was to do away with the mod conflicts that plagued the Morrowind community -- mods conflict has been removed by almost completely isolating mods from each other.
Unfortunately, this isolation makes it difficult to intentionally make mods interact with each other. In fact, using CS by itself, it's impossible to make an esp directly reference (use) anything in any other esp! Fortunately, several tricks have been developed to deal with this. For more info, see Mod Integration.
Multiple Mods in CS4Edit
Note that CS4 does allow you to load non-master mods, but it does not allow your mod to become dependent on them. Again, see Mod Integration for more info. Despite this, the modindex of the formids belonging to your mod will not be '01', but rather will reflect the load position of your mod -- which is always last. E.g., if you load Oblivion plus 4 esps, then the modindex that you'll see in the formids for your data objects will be '04' (since your mod would be fifth in order and the order numbering starts at '00').
While you might suspect that this would cause problems if your mod is loaded later into CS4 without those other esps, or when it's loaded into the game, CS4 and the game engine seem to adjust for it. (However, any changes that you made to non-esm mods may raise errors.)
The fact that the modindex is represented by a byte (two hex digits) indicates that the maximum number of mods that can be used at once is 255. (One byte allows 256 different 'slots', and one of those ('FF') is used by the save game itself. Of course, we're counting Oblivion.esm as a 'mod', so it will use up one of the remaining 255 slots.)
Modindex zero ('00') is special, since the game engine itself defines certain default objects with modindex zero. You'll see these if you start the construction set without any mods (including Oblivion.esm) loaded. This suggests that Oblivion.esm should always be the first mod to load -- i.e. it should always be dated earlier than any other esm files.
Modindex zero is also used in a plugin (ESP) to indicate that the object is defined in one of the mod's masters (ESM files) and not in the plugin. This is needed because the plugin cannot predict in advance what the modindex will be for each of its masters. For example, if MyMod.esp has masters Oblivion.esm and MyMod.esm, and the player has also installed Foo.esm and Bar.esm, then MyMod.esm could be at index 01, 02, or 03 depending on where it is compared to Foo.esm and Bar.esm.
For details on exactly how to load and merge multiple mods see the FormID Fixup page.
- Suppose that you delete an object. Can the formid that was assigned to it be assigned to a newly created object?
- Yes. Base formids can be recycled, as long as there are never two objects with the same formid in a mod. In game, temporary formids (those starting with FF) are incremented by the game engine for each object created. When the counter reaches FFFFFFFF it is reset to FF000000, and formids which are no longer in use are recycled. (There were problems with this recycling not working correctly before patch 1.2.0416 - most notably the counter was incorrectly reset to 00000000 instead of FF000000.)
- What's up with GMSTs?
- Many GMSTs have formids == 0, yet it's possible to change the EditorId. If you try to change the value of a GMST that has formid == 0, a new formid will be assigned. I suspect that GMSTs are an exception -- i.e., that unlike every other data object, their formids are not used.