Difference between revisions of "Data file"
Fixed spelling mistake
imported>David Brasher m (→Changing the Order of Master Files in the Master File List for a Plugin: Capitalization, misordered sentence.) |
(Fixed spelling mistake) |
||
| (4 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
This article is an introduction to mod files: their uses, differences, and importance both to using and making mods. Understanding how plugin files work is fundamentally important to understanding how to mod the game. | |||
The new Light Master (*.esl) files which are introduced in the Skyrim Special Edition version 1.5.3 are being documented on the [//www.creationkit.com/fallout4/index.php?title=Data_File Fallout 4 Data File page]. | |||
== Master Files (*.esm) and Plugins (*.esp) == | == Master Files (*.esm) and Plugins (*.esp) == | ||
| Line 11: | Line 11: | ||
Note that not all game data is contained in the master and plugin files. Textures, meshes, sounds, videos, etc. are all part of the full game, and are stored separately in Archives (.bsa files) or as loose files. | Note that not all game data is contained in the master and plugin files. Textures, meshes, sounds, videos, etc. are all part of the full game, and are stored separately in Archives (.bsa files) or as loose files. | ||
{{NewFeature|Skyrim uses the new [[Papyrus]] script engine. A side effect of this is that scripts are now saved externally as separate source and compiled files, and are no longer included directly in the plugin file.}} | |||
== Dependencies == | == Dependencies == | ||
Master files, plugins and savegames are usually dependent on other master files or plugins (the exception being the original master file that shipped with the game - that master file has no dependencies, and runs on its own). Typically, a Skyrim mod will be dependent on the original Skyrim master file. The masters of a given mod or savegame is simply the list of "parent" | Master files, plugins and savegames are usually dependent on other master files or plugins (the exception being the original master file that shipped with the game - that master file has no dependencies, and runs on its own). Typically, a Skyrim mod will be dependent on the original Skyrim master file, in addition to the Update master file. The masters of a given mod or savegame is simply the list of "parent" plugin files that the mod or savegame depends on. The master files of a mod can be seen in the Creation Kit details view. | ||
{{WarningBox|As scripts are stored externally, the engine no longer effectively removes scripts from a save if a plugin file is removed. '''Clean Saves no longer exist''', and therefore a mod cannot be completely removed from a save. The only way to ensure a removed plugin does not cause any issues in the future is to revert to a save from before the plugin was added - [[Save File Notes (Papyrus)]].}} | |||
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. | 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 | 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. | ||
== FormIDs == | |||
FormIDs are hexadecimal (numbers with the base of 16, instead of 10 like in standard decimal numbers), and are the way the game internally encodes information like "the 2,034th object defined by my fourth master". The first two digits of the FormID is the mod index, which tells the game which plugin file that the object in question comes from. | |||
The mod index is defined by your load order, where Skyrim.esm is always 00 and Update.esm is always 01, however every other mod index can vary, depending on its location in your load order. For example, if two people have MyAwesomeMod.esp, it could have the index of 03 in one install and 0D in another, depending on its location in your load order. An index of FF is a special index reserved for objects created from within the game, that are specific to that save. References created using [[PlaceAtMe]], arrows fired from a bow, ash piles etc. will all have a mod index of FF, and are unique to that save game. | |||
It's also important to note that in terms of FormIDs, [[Base Object]]s and any [[Object Reference]]s will have unique FormIDs. That means that while a base object may have one FormID, every instance of it in the world will also have a separate, unique FormID. If you create a new base object for your mod, that and any references will have the mod index of your plugin. However if you create a new reference of a vanilla base object (for example, you add a new XMarker to a location), then the base object will retain its mod index of 00 (in addition to any existing reference). Only your newly placed reference will have the mod index of your plugin. You can also mark objects and references from other plugins as '''modified''', without creating a new FormID. More information on that is in the next section. | |||
As FF is the last mod index (255 in decimal) reserved for save generated references, and 00 and 01 are always reserved for Skyrim.esm and Update.esm, that gives a total of 252 plugin files that can be loaded by the game in addition to the core files. | |||
== Records and Overrides == | == Records and Overrides == | ||
As mentioned before, a mod file (master file or plugin) 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 | As mentioned before, a mod file (master file or plugin) 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 new records, and modifications of existing records (i.e. of records defined by the mod's masters). E.g. "Cool Swords.esp" might introduce three new swords, as well as modify two existing swords defined by Skyrim.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 indivisible object as far as Creation Kit and the game engine are concerned. Think 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. | The important thing about records is that each record is a single indivisible object as far as Creation Kit and the game engine are concerned. Think 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. | ||
| Line 29: | Line 41: | ||
== Load Order == | == 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. Skyrim goes first, then the next mod in load order, up to the last mod. Whenever two mods conflict, the later loading mod will win. | 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. Skyrim goes first, followed by the Update master file, then the next mod in load order, up to the last mod. Whenever two mods conflict (i.e. modify the same FormID), then the later loading mod will win. | ||
As far as the order is concerned, master files (.esm) always load before plugins (.esp) Then within each groups, files are ordered | As far as the order is concerned, master files (.esm) always load before plugins (.esp) Then within each groups, files are ordered as defined in the plugins text file. You can re-order mod files manually through the launcher or a mod manager, or through a utility such as [http://code.google.com/p/better-oblivion-sorting-software/ BOSS]. | ||
So the following load rules exist: | So the following load rules exist: | ||
| Line 37: | Line 49: | ||
* Newer plugins trump older plugins | * Newer plugins trump older plugins | ||
* Newer master files trump older master files | * Newer master files trump older master files | ||
== Summary == | == Summary == | ||
Remember | Remember that 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. | ||
==Active Files== | ==Active Files== | ||
When working in the Creation Kit, you can load multiple plugins, but you need to set one to be 'Active'. When you save, your changes will be written to the active plugin. | When working in the Creation Kit, you can load multiple plugins, but you need to set one to be 'Active'. When you save, your changes will be written to the active plugin. Note that the mod index of the FormID listed in the Creation Kit is not the same as in game. | ||
Some notes on Active files: | Some notes on Active files: | ||