Difference between revisions of "Modding Terminology"
→Modules, Records, Formids: Linked the FormID article
imported>UDUN m (→Dynamic Items) |
imported>Shademe (→Modules, Records, Formids: Linked the FormID article) |
||
| (4 intermediate revisions by 2 users not shown) | |||
| 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 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'''. | ||
| 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.) | ||