Difference between revisions of "Modding Terminology"

1 byte removed ,  11:43, 28 March 2010
m
imported>UDUN
imported>UDUN
Line 63: Line 63:
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 betweend 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).
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.  
Anonymous user