Oblivion Mod:Save File Format/REFR

A REFR Change Record (change record type 49) describes changes to the objects placed in cells (REFR mod file records). Although it is the most common type of change record, the complexity of the record format has made it impossible, so far, to fully predict the locations of all subrecords, let alone understand the subrecord contents. It seems likely that to properly process a REFR change record, it is first necessary to read the original information for the record. In other words, the exact details of which records appear may be controlled not only by data provided in the save file, but also by information from the Oblivion.esm (or other relevant .esm files). Nevertheless, it is possible to fairly reliably scan the entire REFR record, and it is also possible to reliably extract the data likely to be of most interest.

The REFR change record shares many similarities with the even more complicated ACRE and ACHR change records.

Names of SubrecordsEdit

The first difficulty in interpreting a REFR change record is that the record's overall Flags do not provide a simple guide to the record's contents. The following table lists the name assigned to each flag value (using the names providing in text file dumps). It also summarizes what subrecord(s) may appear when that flag is set:

• "Standard subrecord" means that a single subrecord appears in a fixed location whenever the corresponding byte is set.
• In many cases, the data appears in the Properties structure. This structure has its own system of flags which are used to identify the specific properties contained in the structure. These properties can appear in any order within the structure, and the properties that appear are only loosely related to the record's overall Flags.
• In other cases, the data may appear in the Miscellaneous section. The contents of the Miscellaneous section are not fully understood: they appear to all be optional, for unknown reasons.
• Yellow rows are ones that are also found (with the same meaning) in ACHR and ACRE change records.

Summary information about the location and size of the associated subrecords is listed in the next section.

Byte in Overall Flags	Hex Value of Byte	Subrecord Name	Notes
0	0x00000001	Form Flags	Standard subrecord; same as all Form Flags subrecords
1	0x00000002	Created	Standard subrecord
2	0x00000004	Moved	Standard subrecord
3	0x00000008	Havok Moved	Two possible subrecords. One subrecord only appears if neither "Created" nor "Moved" is set. A second subrecord may appear in the Miscellaneous section.
4	0x00000010	Scale	Standard subrecord
5	0x00000020	All Extra	Data is found in the properties section. Can be associated with multiple properties (0x2a, 0x2b, 0x41, 0x53, etc).
6	0x00000040	Lock	Data is found in the properties section, under property 0x31.
7	0x00000080	Owner	Data is found in the properties section, under property 0x27. 7 is also used for "Owner" in ACRE change records, but not in ACHR change records (where 7 is used for "Crime Gold").
10	0x00000400	Map Marker Flags	Data is found in the properties section, under property 0x33.
11	0x00000800	Had Havok Move Flag	Data appears in Miscellaneous section, if there is any data. Only seen on "NOT LOADED" records?
16	0x00010000	Empty Flag	Data appears in the Miscellaneous section, if there is any data.
17	0x00020000	Dropped Item Flag	Zero-size subrecord (no data is ever added to record)
18	0x00040000	Door Default State	Data appears in the Miscellaneous section, if there is any data.
19	0x00080000	Door State	Zero-size subrecord (no data is ever added to record)
20	0x00100000	Teleport	Data is found in the properties section, under property 0x32.
21	0x00200000	Extra Magic	Data is found in the properties section. Can be associated with multiple properties (0x3a, 0x39).
22	0x00400000	Furniture Markers	Data appears in the Miscellaneous section, if there is any data.
23	0x00800000	Oblivion Flag	A subrecord only appears if none of "Created", "Moved", or "Havok Moved" is set.
24	0x01000000	Movement Extra	Data can be found in one or both of two possible sections. It can be found in the properties section, under property 0x4b. It can also appear in the Miscellaneous section.
25	0x02000000	Animation	Data can be found in one or both of two possible sections. It can be found in the properties section, under property 0x4a. It can also appear in the Miscellaneous section.
26	0x04000000	Script	Data is found in the properties section, under property 0x12.
27	0x08000000	Inventory	Standard subrecord (although it is a complex subrecord)
28	0x10000000	Leveled Creature	Data is found in the properties section, under property 0x35.
30	0x40000000	Enabled/Disabled	Zero-size subrecord (no data is ever added to record). Can be named "Enabled", "Disabled", or "Enabled/Disabled" in the text file dumps.
31	0x80000000	Cell Changed	Standard subrecord.

Locations of SubrecordsEdit

This table summarizes the best current understanding of what data appears in a REFR change record, in what order, and when.

• Yellow rows are ones that are also found (with the same meaning) in ACHR and ACRE change records.

Relative Location	Byte in Overall Flags	Hex Value of Byte	Subrecord Name	Size	Notes
1	31	0x80000000	Cell Changed	16	This subrecord has not actually been seen in any REFR records, but it seems safest to assume that it is theoretically possible for it to appear.
2	1	0x00000002	Created	36	Both "Created" and "Moved" are listed at relative position 2, because only one of them is found in a given record. "Havok Moved" can also appear at this same location, if neither "Created" nor "Moved" is set.
2	2	0x00000004	Moved	28
2*	3	0x00000008	Havok Moved	var.	"Havok Moved" only appears at position 2 (using the same 28-byte structure as "Moved") if neither "Created" nor "Moved" is set. Additional "Havok Moved" data may appear in the Miscellaneous section.
3*	23	0x00800000	Oblivion Flag	0-4	4 bytes of data is added for "Oblivion Flag" only if none of "Created", "Moved", or "Havok Moved" is set.
4-5	These two relative locations have been skipped to maintain consistency with the ACHR and ACRE change record formats
6	0	0x00000001	Form Flags	4
7	27	0x08000000	Inventory	var.
10	5, 6, 7, 10, 20, 21, 24, 25, 26, or 28	Properties
The properties section is present in a REFR change record if any of the listed flags have been set. However, there is no guarantee that any particular property will appear in the properties section -- it is even possible for the properties section to be empty (be two bytes in length, containing 0x0000). The following lines list the specific properties that have been found in REFR records. The properties can appear in any order within the section. The sizes of fixed-length properties are listed as 1+x: 1 for the property flag, x for the actual contents of the property (x matches the size listed on the Properties page). Note that the text file dumps generally add 2 more to the size of these properties, to account for the two-byte "propertiesNum" entry that starts the Properties section -- except the 2 extra bytes are added to every single property, resulting in erroneous total sizes. Also, it is only useful to know the property flags associated with each subrecord name when making comparisons to text file dumps.
	5	0x00000020	All Extra	var.	Property flags = 0x2a, 0x2b, 0x41, 0x53. This is probably a catch-all flag for any other properties, in which case the list of possible properties could be much longer.
	6	0x00000040	Lock	1+6	Property flags = 0x31.
	7	0x00000080	Owner	1+4	Property flags = 0x27.
	10	0x00000400	Map Marker Flags	1+1	Property flags = 0x33.
	20	0x00100000	Teleport	1+28	Property flags = 0x32.
	21	0x00200000	Extra Magic	var.	Property flags = 0x3a, 0x39.
	24	0x01000000	Movement Extra	var.	Property flags = 0x4b. Movement Extra data can also appear in the Miscellaneous section.
	25	0x02000000	Animation	var.	Property flags = 0x4a. Animation data can also appear in the Miscellaneous section.
	26	0x04000000	Script	var.	Property flags = 0x12.
	28	0x10000000	Leveled Creature	1+0	Property flags = 0x35.
20	3, 11, 16, 18, 22, 24, or 25	Miscellaneous
All of the subrecords found in the Miscellaneous section use the same format, making it difficult to identify the relative order of the subrecords. Furthermore, subrecords are frequently dropped from the Miscellaneous section, for unknown reasons. The subrecords that have been found in this section are listed on the following lines, using the best guess of the order in which they appear.
	24	0x01000000	Movement Extra	var.	Movement Extra data can also appear in the Properties section.
	25	0x02000000	Animation	var.	Animation data can also appear in the Properties section.
	3	0x00000008	Havok Moved	var.	"Havok Moved" only appears at position 2 (using the same 28-byte structure as "Moved") if neither "Created" nor "Moved" is set. Additional "Havok Moved" data may appear in the Miscellaneous section.
	11	0x00000800	Had Havok Move Flag	var	Only seen on "NOT LOADED" records?
	16	0x00010000	Empty Flag	0-2
	22	0x00400000	Furniture Markers	0-2
	18	0x00040000	Door Default State	0-2
		After Miscellaneous
30	4	0x00000010	Scale	4
		Zero-size Records
N/A	17	0x00020000	Dropped Item Flag	0
N/A	19	0x00080000	Door State	0
N/A	30	0x40000000	Enabled/Disabled	0

Cell ChangedEdit

The Cell Changed subrecord is present when byte 31 (0x80000000) is set in an ACHR/ACRE/REFR record's overall Flags. Its length is a constant 16 bytes. It contains information about the original position of an actor who has moved from one cell to another. When present, it is always the first subrecord to appear.

In analyzed save files, Cell Changed subrecords have only been seen in ACHR and ACRE change records. However, occasionally REFR change records are seen for creature-related objects such as LVLC, which perhaps could also change cells. Therefore, it seems safest to assume that this subrecord could appear for any of the three change record types.

The x/y/z data in this subrecord is identical to the contents of the original mod record's DATA subrecord; the cell is the same as the CELL group in which the record originally appeared. One theory is that this data is used when cells are reset, to ensure that the actor is respawned at its original location (or perhaps is only respawned if it would not produce a duplicate).

Name	Type/Size	Info
cell	iref	Iref pointing to the cell where the object was originally located (before changing cells)
x	float	X coordinate of object's original location.
y	float	Y coordinate of object's original location.
z	float	Z coordinate of object's original location.

CreatedEdit

The Created subrecord is present when byte 1 (0x00000002) is set in an ACHR/ACRE/REFR record's overall Flags. Its length is a constant 36 bytes. It contains information about the base item and the object's position.

The only subrecord that precedes the Created subrecord is Cell Changed, if both were to appear in the same record.

Note that newly-created ACHR/ACRE/REFR (e.g., placed instances of items) are only identified by this section -- they are not also listed in the save file's createdData section. The createdData section is reserved for new item definitions, e.g. custom-defined potions, weapons, or other item types.

Earlier documentation listed "Base Object" as the subrecord corresponding to byte 1; the Base Object subrecord was listed as a 4-byte subrecord containing the same information as base_item in the Created subrecord. The earlier information was probably based on an incomplete analysis of the record's contents.

Name	Type/Size	Info
flags	ulong	flag 0x2 (only one that seems to be read) determines whether to process this record as a world object or a bound object
base_item	iref	An iref pointing to the base object; equivalent to the NAME subrecord in a REFR mod record, except it is an iref instead of a formID.
cell	iref	Iref pointing to the cell where the object is located.
x	float	X coordinate of object's position.
y	float	Y coordinate of object's position.
z	float	Z coordinate of object's position
rX	float	Rotation around the X-axis in radians. See notes about rX under Moved
rY	float	Rotation around the Y-axis in radians.
rZ	float	Rotation around the Z-axis in radians.

MovedEdit

The Moved subrecord is present when byte 2 (0x00000004) is set in an ACHR/ACRE/REFR record's overall Flags. Its length is a constant 28 bytes. It contains information about the object's new position.

The only subrecord that precedes the Moved subrecord is Cell Changed, if both were to appear in the same record. It appears in the same relative location as the Created subrecord, and presumably appears in place of the Created subrecord for pre-existing objects. Moved and Created subrecords have never been seen together, and it is assumed that they never would appear simultaneously, since all of the information provided in the Moved record is already covered by the Created record.

Name	Type/Size	Info
cell	iref	Iref pointing to the cell where the object is located. 0x00000000 means that the cell has not changed (Previous documentation emphatically but incorrectly claimed that cell was a formid, not an iref. In current analyses, 59438 subrecords have been found that contain irefs; another 95156 subrecords contained 0x00000000. No subrecords were found containing formids, even formids to temporary objects).
x	float	X coordinate of object's position.
y	float	Y coordinate of object's position.
z	float	Z coordinate of object's position
rX	float	Rotation around the X-axis in radians. rX frequently appears to contain some sort of flag, instead of the actual rotation. For example, rX values such as 0xFFFF7F7F have been seen, which translates into the improbable float value of 3.4E38. Generally, rY and rZ contain "normal" values for rotation in these cases (although rare cases of flag-type values for rY and rZ have also been seen). The significance of rX in these cases is unknown.
rY	float	Rotation around the Y-axis in radians.
rZ	float	Rotation around the Z-axis in radians.

Havok MovedEdit

This Havok Moved subrecord is present when byte 3 (0x00000008) is set in an ACHR/ACRE/REFR record's overall Flags, but only if neither Created nor Moved appears (if neither flag 1 nor 2 is set). Its length is a constant 28 bytes, and uses the same format as a Moved subrecord. It contains information about the object's new position.

The only subrecord that precedes the Havok Moved subrecord is Cell Changed, if both were to appear in the same record. It appears in the same relative location as the Created and Moved subrecord, and appears in place of those records. Presumably it is used for objects which only moved as a result of the havok physics (e.g., because they were bumped, or the table on which they were located was jostled), as opposed to objects which were grabbed or dropped in a new location by the player. Objects that were Havok Moved are normally re-positioned in their original locations when the cell is reset.

Note that this subrecord is only one part of the "Havok Moved" data. Additional data can be added to the Miscellaneous section, although details of the additional data are poorly understood.

Oblivion FlagEdit

The Oblivion Flag subrecord is present when byte 23 (0x00800000) is set in an ACHR/ACRE/REFR record's overall Flags, but only if none of Created, Moved, or Havok Moved) appears (if none of flags 1, 2, 3 or set). Its length is a constant 4 bytes, and contains information about the Oblivion cell in which the object is located.

The only subrecord that precedes the Oblivion Flag subrecord is Cell Changed, if both were to appear in the same record, but only because data is added for the Oblivion Flag only in the absence of the other preceding sections. Otherwise, no data is added to the record; the Oblivion cell information can instead be retrieved from the cell entry in one of the other sections.

One theory for this subrecord's rationale is that it is used when an Oblivion World is de-activated and all the change records associated with that world need to be found and deleted. Oblivion worldspaces are unique in that they are de-activated, and then later new instances of the entire worldspace may be created, with no memory of the earlier worldspace -- the cell reset on an Oblivion worldspace needs to be more thorough than on any other cell, and this subrecord is part of the mechanism for the thorough reset.

Name	Type/Size	Info
cell	formid or iref	Formid or iref for the Oblivion cell (i.e. Planes of Oblivion CELL or WRLD record) where the object is located. Both formids and irefs have clearly been seen in this record -- even for references to the same cell, within the same save file.

Form Flags

The Form Flags subrecord is present when bit 0 (0x00000001) is set in any change record's overall Flags. Its length is a constant 4 bytes.

The Form Flags subrecord has been seen in nearly every type of change record, always associated with bit 0, always using the same name in the text dump files, and always using the same format. The only record types without any Form Flags (so far) have been: CELL, FACT, INFO, PACK, and QUST. Furthermore, in analyzed save files, bit 0 has never been set for any of those five record types, so it is possible that even for those records, bit 0 is reserved for the Form Flags subrecord.

Name	Type/Size	Info
flags	ulong	The record's current form flags. Related to form flags in mod files, but the meaning of some bits is unknown. Example: If an item from an ESM file was originally a quest item, and stopped being one, flags = 0x00000009 Example: If an item from an ESM file was not originally a quest item, and became one, flags = 0x00000409

InventoryEdit

The Inventory subrecord is present when byte 27 (0x08000000) is set in an ACHR/ACRE/REFR change record's overall Flags. Its length is variable. The parameters controlling its length are well-understood but complex: it consists of a specified number (itemNum) of entries, each of which is documented by a structure of variable length. You need to decode the entire Inventory subrecord in order to determine the total size of the subrecord. The subrecord details the items that the character, creature or containers (drawers, chests, etc.) currently possess -- and those that are no longer possessed.

Because this is a change record, the inventory lists changes relative to that specified in the ESM/ESP files, both additions and substractions. For example: at the start of the game, your character receives "royal jewelry" a.k.a. wrist irons. If you never drop or sell them they are not listed in your character's Inventory subrecord, because you are still carrying them. On the other hand, if you do drop the wrist irons, then they are listed in the Inventory, with stackedItemsNum=-1. Therefore, if you want get a complete list of the inventory contents, you need to read first the listing provided by the ESM and ESP files. Then you can read the save file's contents and add or remove items, yielding the inventory's final list.

A minimal inventory item entry provides the item's iref (ulong), item count (StackedItemsNum, ulong), and count of extra information (changedEntriesNum, ulong). If changedEntriesNum is 0, then no further data is provided for that item -- the total size of that item's entry is 12 bytes. However, many items include extra information, documenting changes to the item's properties (e.g., whether the item is equipped by the player, the item's health, the available charge of an enchanted weapon, etc.). The structure and data length for this extra information depends upon the number and type of the changed properties.

The extra information count, changedEntriesNum, does not list the number of changed properties, but rather the number of sets of changed properties. Each set of changed properties (each changedEntries structure) applies to one subset of the item stack. Multiple changedEntries information sets are provided if a stack of multiple items contains items with a range of properties; conversely, an inventory entry documenting a single item will only have one changedEntries set. For example, if the player is carrying 12 Iron Longswords (base health 140), 1 of which is equipped and damaged to 10% health and 4 of which have been repaired to 125% health (leaving 7 "unchanged" swords at 100% health), the inventory listing will consist of:

• iref (4 bytes; value differs for every save game)
• stackedItemsNum=12 (4 bytes)
• changedEntriesNum=2 (4 bytes)
• The first changedEntries set, describing the equipped but damaged sword (8 bytes total):
  • propertiesNum=2 (2 bytes)
    • itemHealth property: flag=0x2b; value=14.0 (5 bytes total)
    • equipped property: flag=0x1b; value=empty (1 byte total)
• The second changedEntries set, describing the 4 expert-improved swords (10 bytes total):
  • propertiesNum=2 (2 bytes)
    • itemHealth property: flag=0x2b, value=175.0 (5 bytes total)
    • affectedItemsNum propery: flag=0x2a, value=4 (3 bytes total)

(Note that in earlier documentation of the inventory record, the structure and meaning of this extra information was inaccurate; the earlier documentation would only work for relatively simple sets of changed properties).

Name	Type/Size	Info
itemNum	ushort	Number of items in inventory.
item	struct[itemNum]	Items in characters inventory.
iref	ulong	Points to the FormId's location in the FormIdArray (unless iref>0xFF000000, in which case it is the FormId of an item in the createdData array).
stackedItemsNum	ulong	Number of items added to (or removed from) stack by the change record.
changedEntriesNum	ulong	Number of entries listing changed properties (e.g. equipped, used, damaged etc) If changedEntriesNum is 0, this is the end of the item's data
changedEntries	struct[changedEntriesNum]	Each listing in changedEntries is a collection of properties describing one or more of the items in the stack. If the properties apply to more than one item, then one of the properties entries will be affectedItemsNum; conversely, if affectedItemsNum does not appear, then the properties describe only one item. Since these are changed properties, any properties that are not specified have default values.
propertiesNum	short	Number of properties changed for this subset of items
property	struct[propertiesNum]	Structure detailing an individual property change.
Flag	byte	Changed property indicator. The properties page documents all known values for this flag.
-Value	different	Changed property value, The type of value and its length depends upon the flag; see properties. (Value is not present for flags with zero-length values)

PropertiesEdit

A properties section appears in a REFR change record only if one or more of the following bytes are set in the record's overall Flags:

• 5, 6, 7, 10, 20, 21, 24, 25, 26, 28

Within this section, the individual properties can appear in any order -- each property is preceded by a flag identifying its contents. The full list of possible property flags and the format associated with each flag is documented on a separate Properties article.

MiscellaneousEdit

This section of the record is not yet properly understood. It does not always appear; when present, it can contain one or more subrecords, each of variable length. All of the subrecords in this section follow the same format, and the meaning of the data within the subrecords is unknown, making it very difficult to differentiate between the subrecords. Given that the contents of the Miscellaneous section are so uncertain, the easiest way to handle it is to simply skip past the section.

Data that is known to appear in this section (based on the subrecord sizes in text dump files) include:

• Animation (byte 24)
• Movement Extra (byte 25)
• Havok Moved (byte 3)

Other subrecords that are believed to appear in this section are:

• Had Havok Move Flag (byte 11)
• Empty Flag (byte 16)
• Furniture Markers (22)
• Door Default State (18)

However, these additional subrecords are always empty (contain 2 0x00 bytes), or are subrecords that only appear in records identified as NOT LOADED in the text dump savefiles, and whose data length is therefore unknown. This prevents a size-based analysis of the subrecords' presence and relative location.

Within the section are a series of subrecords, all with the following format:

Name	Type/Size	Info
dataLen	ushort
data	byte[dataLen]

The number of such sections to appear in a Miscellaneous section is difficult to predict. Existing theories (discussed below) work in some cases, but overpredict the number of subrecords in other cases. What can be more reliably deduced from the record's overall flags is where the miscellaneous section ends, essentially by working backwards from the end of the REFR change record. Specifically:

• If byte 4 (Scale) is not set, the section ends at the end of the REFR change record.
• If byte 4 is set, the section ends 4 bytes before the end of the REFR change record.

The most reliable way to process the Miscellaneous Section is:

1. Determine the end of the section
2. Read subrecords until the end of the section is reached

In cases analyzed to date, 0 to 3 subrecords have been found in the Miscellaneous Section. The best guess at the order to use when assigning those subrecords is:

1. Movement Extra (if byte 24 is set)
2. Animation (if byte 25 is set)
3. Havok Moved (if byte 3 is set)
4. Had Havok Move Flag (if byte 11 is set)
5. Empty Flag (if byte 16 is set)
6. Furniture Markers (if byte 22 is set)
7. Door Default State (if byte 18 is set)

Presumably, Bethesda's algorithm for processing records does not require first calculating where the section ends. However, a pattern identifying which subrecords will appear has not yet been identified. For example, if both bytes 24 and 25 are set, sometimes only one subrecord appears in the Miscellaneous Section; other times, two subrecords are clearly present.

The following sections summarize some of the statistics used to reach the previous conclusions. The most important tool used in determining the subrecords present in the Miscellaneous Section is the sizes listed for loaded records in text file dumps. However, those sizes cannot be used to differentiate between two-byte subrecords; there are clearly inaccuracies in the listed sizes; and, Had Havok Move Flag subrecords never appear in loaded records. Therefore, in many cases, the analysis comes down to whether the entries in the Miscellaneous Section are two-byte entries (0x00,0x00) or multi-byte entries (more than two bytes in size). Several of the subrecords are assumed to be at most two bytes in size (namely, Empty Flag, Furniture Markers, and Door Default State), and therefore cannot be paired up with multi-byte entrie.

Movement ExtraEdit

The Movement Extra subrecord may be present in the Miscellaneous Section when byte 24 (0x01000000) is set in a REFR change record's overall Flags. This data is in addition to any that may appear in the Properties section, under property 0x4b. The meaning of the Movement Extra data is unknown.

In loaded records listed in text file dumps, sizes ranging from 15 to 5137 are reported for the Movement Extra subrecord. After deleting the size of any data found in the Properties section, the remaining sizes range from 2 to 5096 bytes. When seen in loaded records, the remaining size of the Movement Extra subrecord always matches the size of the first entry in the Miscellaneous Section.

AnimationEdit

The Animation subrecord may be present in the Miscellaneous Section when byte 25 (0x02000000) is set in a REFR change record's overall Flags. This data is in addition to any that may appear in the Properties section, under property 0x4a. The meaning of the Animation data is unknown.

In loaded records listed in text file dumps, sizes ranging from 4 to 179 are reported for the Animation subrecord. After deleting the size of any data found in the Properties section, the remaining sizes range from 2 to 179 bytes (the property entries were 6-14 bytes in size, and were always the only Animation data present in the change record).

Havok MovedEdit

The Havok Moved subrecord may be present in the Miscellaneous Section when byte 3 (0x00000008) is set in a REFR change record's overall Flags. This data is in addition to any that may appear in place of the Moved subrecord. The meaning of the Havok Moved data is unknown.

In loaded records listed in text file dumps, sizes ranging from 2 to 33 are reported for the Havok Moved subrecord. After deleting the size of any data found earlier in the subrecord, and deleting any superfluous data (the total of the text file dump sizes is frequently 28 bytes too large when the Havok Moved subrecord is present), the remaining sizes range from 2 to 5 bytes. However, in NOT LOADED records, larger sizes are frequently inferred; also, in ACHR/ACRE change records, where the Havok Moved subrecord seems better-behaved, its size can also be much larger than 5 bytes.

Had Havok Move FlagEdit

The Had Havok Move Flag subrecord may be present in the Miscellaneous Section when byte 11 (0x00000800) is set in a REFR change record's overall Flags. This subrecord is only seen in unloaded records in text file dumps, so no information is available about its expected size. It is also never seen in records with the Havok Moved subrecord.

However, it seems likely that the Had Havok Move Flag can have data sizes of more than 2 bytes. Overall, the inferred sizes for the Had Havok Move Flag subrecord are very similar to those for the Havok Moved subrecord -- suggesting that the Had Havok Move Flag essentially inherits the Havok Moved data. In other words, this flag may indicate that the Havok Moved data is all obsolete and needs to be purged from the record the next time the record is loaded, but in the meantime the data is still there and needs to be taken into account when processing the record's data.

Empty FlagEdit

The Empty Flag subrecord may be present in the Miscellaneous Section when byte 16 (0x00010000) is set in a REFR change record's overall Flags. The flag is always seen for REFR records whose base object is a plant (FLOR record), so it is possible this flag keeps track of whether or not a plant has been harvested (i.e., has been emptied of ingredients).

In loaded records listed in text file dumps, the size of the Empty Flag subrecord is always listed as two bytes, and therefore it has been assumed that the Empty Flag subrecord is never more than two bytes in size. However, the resulting conclusion is that the relative position of the Empty Flag data varies depending upon which set of subrecords are present. Specifically:

• In several combinations, Empty Flag (16) comes after the Havok subrecords (3, 11). Namely: 25-11-16, 25-3-16
• In other combinations, the Empty Flag must come before the Havok subrecords. Namely: 16-11, 16-3

The size statistics for more complex combinations are inconclusive (no multi-byte records could be associated with any of 3, 11, or 16).

Furniture MarkersEdit

The Furniture Markers subrecord may be present in the Miscellaneous Section when byte 22 (0x00400000) is set in a REFR change record's overall Flags. The meaning of the flag is unknown.

In loaded records listed in text file dumps, the size of the Furniture Markers subrecord is always listed as two bytes. In cases where Furniture Markers is the only possible subrecord in the Miscellaneous Section, the Miscellaneous Section almost always contains a single 2-byte entry -- confirming that the Furniture Markers subrecord does appear in this section. However, when seen in combination with other Miscellaneous subrecords, the Miscellaneous Section often contains only multi-byte entries -- so presumably the Furniture Markers subrecord is frequently dropped. Therefore, the Furniture Markers subrecord appears near the end of the list of possible subrecords.

Door Default StateEdit

The Door Default State subrecord may be present in the Miscellaneous Section when byte 18 (0x00040000) is set in a REFR change record's overall Flags -- although it seems more likely that in fact no data is added when this byte is set. As described in more detail under Door State, this subrecord appears related to the use of the SetDoorDefaultOpen command.

In loaded records listed in text file dumps, the size of the Door Default State subrecord is always listed as two bytes. However, it seems likely that no data is actually added to the REFR change record. The sum of the subrecord sizes is always larger than the total record size by two (or more) bytes when byte 18 is set. Furthermore, byte 18 has only been seen simultaneously with bytes 24 and 25; in all such cases, only one 2-byte (0x00,0x00) entry is present in the Miscellaneous Section. There is no way to definitively identify the correct subrecord for this entry, but byte 24 seems the most probable (there are 4 missing bytes for byte 24, plus byte 24 is known to have data in the Miscellaneous Section).

ScaleEdit

The Scale subrecord is present when byte 4 (0x00000010) is set in an ACHR/ACRE/REFR change record's overall Flags. Its length is a constant 4 bytes, and provides the size of this particular object relative to the standard object size.

In a REFR change record, Scale is always located at the end of the subrecord.

Note that there is also a Scale property (property flag 0x37), but the property is only found in Inventories, not in REFR property sections.

Name	Type/Size	Info
scale	float

Dropped Item FlagEdit

"Dropped Item Flag" is true when byte 17 (0x00020000) is set in a REFR record's overall Flags. No subrecords or data are added to the record when this flag is set.

Name	Type/Size	Info
N/A	0	No data is added to the record

Door StateEdit

"Door State" is true when byte 19 (0x00080000) is set in a REFR record's overall Flags. No subrecords or data are added to the record when this flag is set.

Note that there is also a "Door Default State" subrecord (triggered by byte 18) that appears in the Miscellaneous section. In one test using the console, both bytes 18 and 19 were set when the command SetDoorDefaultOpen 1 was run; however, neither byte was set when the command SetOpenState 1 was run. However, this test involved REFRs to STAT records, not REFRs to DOOR records, so it might not be representative.

Name	Type/Size	Info
N/A	0	No data is added to the record

Enabled/DisabledEdit

This value is true when byte 30 (0x80000000) is set in an ACHR/ACRE/REFR record's overall Flags. No subrecords or data are added to the record when this flag is set.

It is unclear, however, what this flag means. In text file dumps, this flag is described as "Enabled", "Disabled", or "Enabled/Disabled"; "Enabled/Disabled" is only used on NOT LOADED records. One logical explanation would be that this flag means the item's default status has been reversed: that objects which are initially enabled are disabled when this flag has been set, and vice versa. However, it does not seem to be that straightforward. For example, statistics from one save file show that:

• This flag appeared 450 times for objects identified in Oblivion.esm as being "disabled by default" (byte 19 set in the flags1 field).
  • 46 of these objects were "Disabled" according to the text file dump.
  • 404 of these objects were "Enabled" according to the text file dump.
• This flag appeared 932 times for objects identified in Oblivion.esm as being initially enabled (byte 19 was not set in the flags1 field).
  • 190 of these objects were "Disabled" according to the text file dump.
  • 742 of these objects were "Enabled" according to the text file dump.

In other words, in the majority of cases, this flag means that the object is Enabled, regardless of the object's initial status. It is unknown how savefile parsers are supposed to determine the correct meaning of this flag.

In a small number of cases (7 in the previous example), a property identified as meaning "Disabled" was also set.

Name	Type/Size	Info
N/A	0	No data is added to the record