Difference between revisions of "Modding Terminology"
→Modules, Records, Formids: Linked the FormID article
imported>DragoonWraith (adding introduction, nominating this for featured status) |
imported>Shademe (→Modules, Records, Formids: Linked the FormID article) |
||
| (7 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
{{ | {{Featured}} | ||
This article explains the fundamentals of how mods work. It is somewhat lengthy, and somewhat technical, but '''it is absolutely critical that a modder understands these concepts!''' Failure to understand the distinctions and explanations in this article can very easily turn a mod into a buggy mess. It is therefore ''highly'' recommended that you read this article in its entirety, and continue reading it until you understand it. ''Specific'' questions may be asked on the [[Talk:Modding Terminology|talk page]], but please be sure to check to make sure no one else has asked the same question. | This article explains the fundamentals of how mods work. It is somewhat lengthy, and somewhat technical, but '''it is absolutely critical that a modder understands these concepts!''' Failure to understand the distinctions and explanations in this article can very easily turn a mod into a buggy mess. It is therefore ''highly'' recommended that you read this article in its entirety, and continue reading it until you understand it. ''Specific'' questions may be asked on the [[Talk:Modding Terminology|talk page]], but please be sure to check to make sure no one else has asked the same question. | ||
| Line 7: | Line 7: | ||
Module files are collections of '''records'''. Different types of records define different types of things: sounds, races, placed objects ("references"), leveled lists, etc. While different types of records have different fields (e.g., weight of an arrow, x position of a placed object, sound id of an opening door), at the basic level they're all the same sort of thing -- a record. | Module files are collections of '''records'''. Different types of records define different types of things: sounds, races, placed objects ("references"), leveled lists, etc. While different types of records have different fields (e.g., weight of an arrow, x position of a placed object, sound id of an opening door), at the basic level they're all the same sort of thing -- a record. | ||
All records have a unique '''formid.''' Many (but not all) records also have '''editor ids'''. Formids are eight digit hexadecimal numbers (e.g. 00030FDC). Editor ids are short text strings (letters and number only, no spaces or special characters). For records listed in the Objects window of the CS, the editor id is listed in the first column and the formid in the second column (by default this column is too narrow to actually see the formid -- drag the column divider to the right to see the formid). Same thing for both panes of the Cell View window: the left pane lists the cells by editor id and then formid. Right pane lists placed objects in the same way -- with one caveat -- if no editor id has been assigned to a particular reference, then the editor id of the reference's base object is shown instead. | All records have a unique '''[[FormID|formid]].''' Many (but not all) records also have '''editor ids'''. Formids are eight digit hexadecimal numbers (e.g. 00030FDC). Editor ids are short text strings (letters and number only, no spaces or special characters). For records listed in the Objects window of the CS, the editor id is listed in the first column and the formid in the second column (by default this column is too narrow to actually see the formid -- drag the column divider to the right to see the formid). Same thing for both panes of the Cell View window: the left pane lists the cells by editor id and then formid. Right pane lists placed objects in the same way -- with one caveat -- if no editor id has been assigned to a particular reference, then the editor id of the reference's base object is shown instead. | ||
==Object vs. Object== | ==Object vs. Object== | ||
| Line 14: | Line 14: | ||
There's a major problem with the use of the word "object" when talking about modding. The problem is that there are several different equally obvious, yet pretty much incompatible ways to use the word. I'll cover those here, and then try to resolve those conflict -- in part by discarding some of the standard terminology. | There's a major problem with the use of the word "object" when talking about modding. The problem is that there are several different equally obvious, yet pretty much incompatible ways to use the word. I'll cover those here, and then try to resolve those conflict -- in part by discarding some of the standard terminology. | ||
When playing you tend to think of "objects" in the game world -- a wall, a rock, a creature, a dagger that you find | When playing you tend to think of "objects" in the game world -- a wall, a rock, a creature, a dagger that you find in a chest. When working in the rendering window of the CS, you tend to think of "objects" pretty much the same way, except that you're likely to think of fog banks, collision zones, etc. as also being "objects". Unfortunately, the CS contradicts that, calling those things "references", and seems to define "objects" as things listed in the "Objects Window". But from yet another view, if you're a programmer, you tend to think of discrete chunks of data as being "objects" -- i.e. you would see the internal representations of all the records (classes, factions, base objects and references) as being objects. | ||
So, what I'm going to do here is to use the term "object" as little as possible. When I do use it, I'll usually mean it in the game players way -- as things seen and handled in the game world. For modding, when I need to talk about data chunks in a general way, I'll say "records". Also, whenever I talk about any type of record ("cell", "faction", "weapon", "reference", etc.), that can be considered to be short for "cell record", "faction record", "weapon record", "reference record", etc.) | So, what I'm going to do here is to use the term "object" as little as possible. When I do use it, I'll usually mean it in the game players way -- as things seen and handled in the game world. For modding, when I need to talk about data chunks in a general way, I'll say "records". Also, whenever I talk about any type of record ("cell", "faction", "weapon", "reference", etc.), that can be considered to be short for "cell record", "faction record", "weapon record", "reference record", etc.) | ||
| Line 23: | Line 23: | ||
==References== | ==References== | ||
References are based on '''base records''' (aka "base objects" in CS). The base record for a reference is a prototype for that reference. Some bases have many references (e.g. standard containers), some have only one (e.g. most non-combatant NPCs). | |||
Most records in the game are references. (Think of it: hundreds of cells, with wall, racks, trees, creatures, etc. -- it all adds up.) While it would be possible to assign editor ids to all of these references, thankfully this is not done. Hence, most records in Oblivion.esm do not have editor ids. | Most records in the game are references. (Think of it: hundreds of cells, with wall, racks, trees, creatures, etc. -- it all adds up.) While it would be possible to assign editor ids to all of these references, thankfully this is not done. Hence, most records in Oblivion.esm do not have editor ids. | ||
| Line 29: | Line 29: | ||
Incidentally, aside from references, there is another group of records without editor ids -- and that is base records created in-game. Editor ids are really only useful to human modders, not to the CS or game engine, both of which prefer to work with formids. So, since the alchemy potions, spells, enchanted armor and weapons created in-game aren't expected to be viewed by humans, they're not assigned editor ids. | Incidentally, aside from references, there is another group of records without editor ids -- and that is base records created in-game. Editor ids are really only useful to human modders, not to the CS or game engine, both of which prefer to work with formids. So, since the alchemy potions, spells, enchanted armor and weapons created in-game aren't expected to be viewed by humans, they're not assigned editor ids. | ||
References can also have "parent" references. Parent references are | References can also have "parent" references. Parent references are used for two purposes: 1) chaining enable/disable states across the references (the appearance of Oblivion gates is controlled by such chains), and 2) linking references in a way that scripts can use (traps use this -- a trigger rope reference might have a falling log as it's parent -- the script for the rope will then trigger will react to an actor colliding with it by triggering the parent ref). Note that for enable/disable state control the parent ref really does act as a "parent", but when used in a trap, or similar situation, the flow is reversed -- it's the "child" that controls the "parent". | ||
==Base Records== | ==Base Records== | ||
| Line 59: | Line 59: | ||
As mentioned previously, '''dynamic items''' are not permanently associated with references, instead they have ''no'' reference while in inventory and are dynamically assigned a new record every time they are dropped into the world. Again, this is in contrast to non-dynamic items -- i.e., items that begin their existence by being placed directly into the world by a mod. Non-dynamic items will always be represented by their original, mod-defined reference, regardless of their movement between inventories, containers and cells. | As mentioned previously, '''dynamic items''' are not permanently associated with references, instead they have ''no'' reference while in inventory and are dynamically assigned a new record every time they are dropped into the world. Again, this is in contrast to non-dynamic items -- i.e., items that begin their existence by being placed directly into the world by a mod. Non-dynamic items will always be represented by their original, mod-defined reference, regardless of their movement between inventories, containers and cells. | ||
So what happens to the temporary reference of an dynamic item after you pick it up? Under most circumstances, it's immediately deleted from the save game. And in fact (after the recent 1.2.0416 patch), the formid for that dynamic reference is recycled. So if you're in an isolated cell, drop | So what happens to the temporary reference of an dynamic item after you pick it up? Under most circumstances, it's immediately deleted from the save game. And in fact (after the recent 1.2.0416 patch), the formid for that dynamic reference is recycled. So if you're in an isolated cell, drop an iron dagger check its formid, pick it up and then drop an iron shield, the dynamic reference for iron shield will likely be assigned the same formid that was just freed by picking up the iron dagger. | ||
However, under some circumstances the reference will ''not'' be removed from the save game. (Non-removal seems to be associated with having script record variables either attached to the reference and/or pointing at the reference.) In these cases, the reference continues to exist as data in the savegame, but is not visible in the game world, and is no longer associated with the item that's now in inventory. If the item is dropped again, it will not be reattached to this old reference, but instead be given a new dynamic reference -- which will likely suffer the same problem. It appears that these left over references are ''not'' cleared from the save game by the normal three day respawn/garbage collection process. As a result, if there are lot (1000's) of these references they can have a significant affect on savegame size. Accordingly, these are called '''bloat references'''. | However, under some circumstances the reference will ''not'' be removed from the save game. (Non-removal seems to be associated with having script record variables either attached to the reference and/or pointing at the reference.) In these cases, the reference continues to exist as data in the savegame, but is not visible in the game world, and is no longer associated with the item that's now in inventory. If the item is dropped again, it will not be reattached to this old reference, but instead be given a new dynamic reference -- which will likely suffer the same problem. It appears that these left over references are ''not'' cleared from the save game by the normal three day respawn/garbage collection process. As a result, if there are lot (1000's) of these references they can have a significant affect on savegame size. Accordingly, these are called '''bloat references'''. | ||
In understanding how dynamic items are moved between cells and containers and | In understanding how dynamic items are moved between cells and containers and between different containers, it may be that they're not so much moved as copied. I.e., the original object is copied to the new container/cell, along with its state information (armor/weapon health, enchantment charge, local script variables) and the original is deleted (or for bloat references, marked as destroyed). | ||
This copying is most evident when dropping multiple instances of identical simple items (e.g. arrows, or undamaged iron daggers). If you drop multiple such identical simple items (e.g., ten iron arrows), they won't drop as ten separate arrows, but rather as a single stacked arrow (their mouseover id will be "Iron Arrow (10)"). In this case, the game actually treats the ten arrows not as ten separate arrows but as 1 arrow x 10. (Note that this ''only'' happens for simple, dynamic items. | This copying is most evident when dropping multiple instances of identical simple items (e.g. arrows, or undamaged iron daggers). If you drop multiple such identical simple items (e.g., ten iron arrows), they won't drop as ten separate arrows, but rather as a single stacked arrow (their mouseover id will be "Iron Arrow (10)"). In this case, the game actually treats the ten arrows not as ten separate arrows but as 1 arrow x 10. (Note that this ''only'' happens for simple, dynamic items. | ||
| Line 136: | Line 136: | ||
Some clarifications on scripting in light of discussion here. | Some clarifications on scripting in light of discussion here. | ||
* getSelf applied to a mod based item will always return the original formid of the item. | * getSelf applied to a mod based item will always return the original formid of the item. | ||
* getSelf applied to a dynamic item will always return 0 -- even when the item is in a cell and has a reference. While you might expect it to return | * getSelf applied to a dynamic item will always return 0 -- even when the item is in a cell and has a reference. While you might expect it to return the formid of its dynamic reference while in the cell, apparently the function is rigged to return zero for safety reasons. | ||
* placeAtMe creates a dynamic reference -- ''and'' returns the correct formid. (Directly contrary to behavior of getSelf.) | * placeAtMe creates a dynamic reference -- ''and'' returns the correct formid. (Directly contrary to behavior of getSelf.) | ||