Difference between revisions of "Modding Terminology"
→Modules, Records, Formids: Linked the FormID article
imported>UDUN m (→References) |
imported>Shademe (→Modules, Records, Formids: Linked the FormID article) |
||
| (2 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 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 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.) | ||