Oblivion Mod talk:Save File Format/Properties

Sources

The information on this page was taken from a few different places in the previous UESP documentation:

• The Inventory section of the ACHR page, which previously provided the best documentation of properties
• The Actor States section of the ACHR page. I've effectively renamed "Actor States" to "Properties", since the section is used for inanimate objects as well as actors, and also because there is no relationship between these Properties and the Actor Flag. However, I have a few concerns about the original Actor States info:
  • I have no idea where the property names come from
  • I've deleted the flag 0x6d, listed as an unknown 24-byte structure. I've never seen this flag, and the gap between it and the next-highest flag (at 0x5c) is pretty large.
  • The AI Pack information (flag 0x1f) seems to bear little resemblance to the actual data at 0x1f, making me wonder whether "AI Pack" is in fact associated with 0x1f or some other flag
• The Inventory section of the REFR page, although most of that info was redundant/inaccurate

Plus I've added alot of new information/guesswork based on the save files I've been analyzing. --Nephele^Talk 23:28, 21 May 2010 (UTC)

First of all: you have done great work by reassembling all the scattered save file information.

About your concerns: I've called that array Actor States because I was focused on the actors change record and did not take into consideration other records for the reason to not get lost with to much details. I think you are right renaming it to a more common name.

The property names as far as taken from the previous ACHR wiki page are simply a guess derived from data found at the corresponding property flag and if I could not find an official name (e.g. from save file dumps).

Currently I can't reproduce how I've stumbled upon flag 0x6d. Maybe it was a fault (like so many others)

AI Pack: I've always encountered two locations where references to AI packages where appearing. One at property flag 0x1f along with a ulong value and the other directly following the properties array. The second with some strange behavior in its byte length and its suggested associated data sometimes strangly interrupted by a Dialogue sub record. -Dirtyolddunmer 11:07, 22 May 2010 (UTC)

Thanks for the quick feedback -- and for keeping me honest ;)

Re: AI Pack. In my original notes about AI Pack I'd scribbled "the first 8 bytes are NOT iref,long", and I didn't bother to recheck those notes yesterday... and now I can't figure out why I said that ;) (and of course I have no idea which record I'd been investigating at the time). The first dozen-odd cases I just looked at were indeed all 0x1f + (iref to a PACK) + ulong + (6 0x00 bytes). So actually the only change I'm making is adding 6 empty bytes onto the property -- which always seem to be there, but really only matter in terms of finding the start of the next property.

So I'll fix that up in the article! --Nephele^Talk 14:53, 22 May 2010 (UTC)

Flags and their meaning

AI Pack 0x1f: If debug text is toggled in Oblivion's console with code zero you can observe states of Package/Procedure Current Pack and Current Editor Package/Procedure Editor Pack. I understand that first is the current package that NPC follows and second the upcoming one. Taking into consideration ACHR record's AI Pack subrecord's obvious coordinate data 0x1f might be the reference to the upcoming package.

Edit: Created save at following ingame situation: NPC's active package is Lunch (custom package from a Mod); NPC stands up wanders arround and starts conversation with ohter NPC. Debug text shows: Package Dialogue; Procedure Current Pack - PROCEDURE_DIALOGUE; Current Editor Package; Procedure Editor Pack - PROCEDURE_WANDER. In save file I can find now following inside this NPC's ACHR record: Actor States - flag 0x1f set referencing to a custom mod's lunch package; a Dialogue sub record detailing a custom mod's HELLO topic and who the NPC is targeting (iref) along with lots of other data. This is followed by the subrecord that I understand as the AI Pack Data section/sub record inside the ACHR record with no reference to any package but with the usual float values.

I suggest 0x1f stores the interrupted package and the other sections/subrecords are detailing the procedures and is absent when a package works normal. -- Dirtyolddunmer 19:07, 24 May 2010 (UTC)

XMarkerHeading 0x1e: Reference inside this subrecord often points to a WRLD record. This record has two unknown subrecords: Nam0 and Nam9 which are looking like holding coordinates. It looks like 0x1e is something like an coordinate offset if you compare its four float values with the mentioned in the WRLD record.

Edit: Fourth value is definitely a float but often it is zero --Dirtyolddunmer 19:07, 24 May 2010 (UTC)

Unknown 0x36: Appears in the inventory subrecord often along with a set leveled items and seems to consecutively numbering them for what ever reason.

Just what I have found so far --Dirtyolddunmer 10:31, 24 May 2010 (UTC)

These are ExtraData

What you refer to as a "flag" is actually an enum denoting the type of ExtraData. Look at GameBSExtraData.h in the OBSE source code for enum values and GameExtraData.h for known ExtraData layouts. You'll find that many of these line up:

• 0x4B "Movement Extra" is ExtraSavedMovementData.
• 0x50 "Bound Item?" is ExtraBoundArmor.
• 0x52 "investmentGold" is ExtraInvestmentGold.

ExtraData classes have RTTI, so these are the original names as seen in Oblivion's source code. The in-memory layout of the classes may not be the same as the serialized data in the save file; I would expect the BSExtraData superclass to have a virtual "Save" method that one could disassemble to figure out the saved data layout, but OBSE doesn't have that documented. DavidJCobb (talk) 10:58, 29 July 2019 (UTC)

Oh -- one more thing: not all BSExtraData subclasses apply to placed objects in the game world. Some go on ACHRs or REFRs in general, but some also go on cells. DavidJCobb (talk) 11:03, 29 July 2019 (UTC)