Oblivion Mod talk:Save File Format

Changes to Page

• I think that we should change most of "formId" text to irefs. For example only in game created objec records have FormIds - other are irefs to form id array. Any comments? Resetgun 04:37, 10 April 2007 (EDT)
  • Seems reasonable. Change records are indexed by actual formids. But other than that and ingame objects, everything is by iref. --Wrye 14:37, 10 April 2007 (EDT)

Patch 1.2 / Shivering Isles

• Patch 1.2 / Shivering Isles changed version numbers from 125 to 126. However - I didn't notice any other large changes in save file structure - anyone else noticed any? Resetgun 04:37, 10 April 2007 (EDT)
  • No, but I'm fairly sure that there wouldn't be large scale changes (i.e., not the general structure). Bash has a couple of functions that beat up on the structure moderately (e.g. the face munging, spell/item editing/removal, bloat removing) and I haven't heard of any problems with those. I haven't seen that much on the mod file format side either. There's new stuff going on with cells apparently (going by the assert errors, etc.) and there was addition of custom animations to npcs. (Cane animations for sheogorath, etc.) That's all I've seen so far. --Wrye
    • I am running Oblivion with the ShiveringIsles_v1.2.0416English patch installed the save files still report version 125 (Both save header and file header), I figured this could have been because of a botched install but after a reinstall and checking the version number on the main menu it still states 125 on a clean save. Any thoughts on this? --Cam 23:47, 6 September 2007 (EDT)

Does anyone have any information on where exactly version 126 comes from -- or even confirmation that version 126 exists? Basically, I've been completely unsuccessful in tracking down where version 126 comes from. The page currently states "After Shivering Isles and patch 1.2 minor version has been 126," but under those same conditions I'm only seeing version 125. More than two years ago, Cam first reported that SI+patch1.2 produces version 125, yet since then, nobody has provided any followup. All of which means I think the information on the article needs to be revised.

On the PC, I've installed patch 1.2.0416 and Shivering Isles, but every save file I create is version 125 -- whether the save is made in Tamriel or in Shivering Isles, and even if I start a completely new character. I've reinstalled SI and reinstalled the patch, to no effect. On the Xbox 360, I'm at version 1.2.1 (equivalent to PC 1.2.0416) and have Shivering Isles, and, again, all of my saves are version 125 (directly copied from the Xbox, without being modified by Oblivion on my PC). I've even tried to go back through old saves to look for version 126, with no luck -- the only caveat is that my old saves are all Xbox 360 saves. However, I do have a pretty good range of Xbox 360 files, including saves before any patches were released, saves after the 1.1.511 patch, and saves made with the original 1.2.0214 patch (both with and without SI, and even a save with the SI ref bug: nextObjectId=0x000eba89). All are version 125.

On both platforms, I'm running an original Oblivion release (US version) that has subsequently been patched and expanded. Which led to me wonder whether somehow GOTY introduced version 126 save files. However, GOTY is not a possible explanation. Version 126 was first reported on 10 April 2007, but GOTY was first released five months later (September 2007). Oblivion was first released via Steam on June 16, 2009.

I've come up with a few theories about where version 126 might come from:

• Theory 1: Version 126 was introduced with patch 1.2.0214, then discontinued with patch 1.2.0416. When the information about version 126 was posted (10 April 2007), the most up-to-date patch was 1.2.0214 (released March 23 2007). The current patch, 1.2.0416, wasn't released until April 30, 2007, so it's clear that the save file where version 126 was first seen could not have been created with the current patch. But why would Bethesda discontinue the new version? And why are Xbox 360 save files with the same patch still version 125?
• Theory 2: Version 126 was introduced with the beta patches, and then discontinued with patch 1.2.0416. Perhaps the developers at first thought a new save file format was necessary to handle the the reference bug, and then ultimately realized that the save file format wasn't to blame. Except the first beta patch (1.2.0410) was released one day too late, on 11 April 2007... unless the OP somehow obtained an advance version, or UESP's release date is incorrect.
• Theory 3: Version 126 was a side-effect of the SI bug. An out-of-range temporary reference could theoretically increment the memory address where the version number was saved. The OP simultaneously posted information about the SI bug, confirming that the OP owned bugged save files... but given his/her awareness of the issue, wouldn't he/she have ruled out that possibility before posting information about a new version? And wouldn't Oblivion refuse to load a save file with an incorrect version number?
• Theory 4: Version 126 is used on the PS3, where Oblivion was first made available in March 2007. But the original editor reported that SI was installed, and SI wasn't available on the PS3 until October 2007. Not to mention the uncertainty over the basic format of PS3 save files, and that the user who posted the information clearly owned Oblivion pre-PS3.
• Theory 5: Version 126 is used by non-English versions (or at least non-US versions) of Oblivion.

In other words, I've racked my brain to come up with explanations for version 126 save files, but I've failed to come up with anything satisfactory. If anyone out there has some actual version 126 save files, it would be great to get some details and actually resolve this mystery. Details such as platform, patch version, date on which save file was created, new character or existing character, status relative to SI bug.... anything else that seems relevant. --Nephele^Talk 06:12, 6 June 2010 (UTC)

Fully patched here and still on 125. rpeh •T•C•E• 07:32, 6 June 2010 (UTC)

Pending Questions

• Is the savefile formids array ever compressed? If not, it would grow linearly as mods are added and removed. And readded... --Wrye

Save file doesn't need to have full formid array - it only need to have form ids that are changed in save file. So no - mod file count shouldn't have singinificant size increase to save file. However interesting question is: how big save file is going to be after one year active playing - when player has dropped thousands items to ground and interacted (and changed) with almost all objects in game? Is there somekind decay mechanism that returns game state back to orginal? Or is save file slowly growing until it is bigger than actual Oblivion object database? --Resetgun

By "compression" I mean that outdated references are removed from the formids file. By "decay" I take it that you mean that things like shot arrows and other minor changes are removed from the game. And it's not just the player is it? NPCs practice shooting arrows, summoning creatures, etc. MW did have a mechanism to remove such references from the game. But it did not have the formids array. Given the size of the problem, I think the game almost has to have decay/compression. Still... Gotta test this. Shouldn't be too hard.--Wrye 11:34, 3 May 2006 (EDT)

Yes. With "Decay" I did mean that the game is removing items and changes made by a player/NPC/Actor - or reseting itself to back orginal state. And I agree - there most likely have somekind mechanism that "compress" or remove unused entries, from the form id array. In fact, it shouldn't be hard to implement for the Bethesda, they most likely need the form id array only when saving and loading save games. So basicly they are rebuilding form id array everytime when saving a game. However, I think that more intresting question is that whatkind "decay" functionality there is in the game - or is save game growing until hard drive is full. --Resetgun 05:19, 4 May 2006 (EDT)

I just did hit to really weird mod indexes in my save games. These indexes are refering to plugins that are not existing in the save files plugin list (index values are too big and not 255). Still, Oblivion is able to read these save files fine. Most likely they are old remains from mod that I have removed from the game. So maybe, Oblivion is handling this way "compression" by changing mod indexes to invalid and slowly removeing change records from the save file? Or maybe my parser is just malfunction... anyone else encountered weird mod indexes in the form id array? I guess that I was wrong again - array compression is problem, and eventually it might slowly grow. Interesting side detail: when I saved game that did have these weird mod indexes, they were removed from new the save file. --Resetgun 07:28, 11 May 2006 (EDT)

I've just added a statistics function to Wrye Bash, and have done a few quick tests. I'm fairly sure that the formids array never compresses. E.g., if you remove a mod from a savegame, then all any entries in the formid array that come from that mod are simply set to 0. However, any change records associated with that mod are removed from the save game. I'm not sure about ResetGun's weird index values -- but as he notes, they're deleted -- which I take to mean "set to zero". BTW, what triggered me to look at this was a savefile problem that some people were having -- files sizes were becoming huge. Problem apparently is some mod (probably a companion mod) is repeatedly duplicating certain items. Devs who looked at the file reported something like 50,000 copies of a type of light armor. --Wrye 20:05, 12 June 2006 (EDT)

I saw a couple of example of weird (too high) modindex values in a savegame that someone sent to me. So, I can confirm ResetGun's report above. --Wrye 15:53, 13 June 2006 (EDT)

Would be really nice to have some example of this problem linked so we can all learn how to avoid it. Do you remember any of the details?--Dev akm 12:15, 26 January 2007 (EST)

We didn't figure it out at all (at least I didn't), just noted that there were a few such anomalies. I think that the most that I can do is write a little bish script that can be used to scan a savefile for too high modindexes. PM me a reminder on the Elder Scrolls forum, and I'll whip something up when I get a chance. --Wrye

• Well, it seems like that you needed a small catastrophe to catalyst change. Hopefully Bethesda will fix their code and form id recycling for ingame objects is fixed. I am actually more surprised that scripting engine is so stupid that it running all scripts when user isn't nearby. They really need to improve their scripting engine for next TES. Resetgun 04:37, 10 April 2007 (EDT)

Yeah, I was a bit surprised by that. From what I understand of the CS, it's definitely not ALL scripts. There are rules which limit when certain types of scripts get run. This is better documented on the cs wiki. May be worth checking out a bit more. --Wrye 14:47, 10 April 2007 (EDT)

There appear to be some flags that control this for certain scripts. In particular, the "No low level processing" flag used for CREA and NPC_ records flag is supposed to control whether updates are done continuously or only when the player is around. And for some characters, there is processing that needs to be done even when the player isn't there (i.e., NPCs that travel from one city to another needs to be updated so that they're in the right places). --Nephele^Talk 15:14, 10 April 2007 (EDT)

Umm... so isn't this "No low level processing" flag work for these guards? Current "script fix" is testing very brutally is player in same cell. Of course I haven't ever visited in that Greenmote - so no idea what those guards are actually doing, my ebil girl did follow dark path instead of drugs, rock and roll.... --Resetgun 18:38, 10 April 2007 (EDT)

• Mistake in the quickKeysData structure

It's stated that each entry can be either 2 or 5 bytes but I believe that this is wrong. Whilst writing some code I tried following the 2 or 5 byte rules laid out and had problems not reaching the correct structure size.

I strongly believe that it should be a 1 byte or 5 bytes rule:

1 Byte to store the state flag and if that is set then a uint_32 to store the formID linked to that quick key.10

For example with no quick keys set I'd expect to see a structure with only 8 bytes (1 byte for each possible quick key) and looking at a real save with no quick keys set this is exactly what I see.

I have analyzed the actual code and it seems to treat the 1 byte value as a counter. It reads it in then loops that many times, reading a 4 byte iref each time.

2.103.0.212 03:52, 10 November 2013 (GMT)

Xbox save files

I've got a bunch of Xbox save files that I was finally able to transfer to PC, and I can confirm that the Xbox save files start with a CON record. I also know that if I try to open the Xbox files unaltered on the PC it just freezes the game. It's not that the file is completely incompatible... in the load menu it's showing the correct screenshot for the Xbox saves and the summary info is correct. So I'm going to try deleting the CON record and see if that helps... in the meantime I was wondering whether anyone has any other ideas on differences that might exist between PC and Xbox save files. --Nephele 23:43, 2 November 2006 (EST)

Update: removing the CON record does nothing to help. So I've started parsing the save files to see where the format differs from that documented here.

One minor bit of trivia is that on the xbox, the patch shows up as a second plugin, so you see both "Oblivion.esm" and "update.esp" listed as plugins. Presumably that's something to do with the fact that on xbox the original Oblivion.esm can't be overwritten, so the update info isn't just merged into the Oblivion.esm file.

But the more significant issue that I'm hitting is that for some reason embedded in the middle of the Records is a big empty chunk: 3000+ bytes of \0. In the one file I'm looking at right now, it happens after reading 7655 records, all of which seemed to be properly formatted (the type was always one of the expected values, the version was always 125). Checking multiple files, this empty chunk seems to often start 692272 bytes into the files and typically consists of 4034 bytes of \0. The start of the blank does not coincide with the start of a new record. Does anyone happen to know why this blank space would be there?

--Nephele 23:32, 3 November 2006 (EST)

To finish my one-sided conversation, in case any one else ever stumbles across this: problem solved! I discovered that there is a generic container file format used on the Xbox 360. The "CON " record is only the first part of this container; the other chunks of data I was finding inserted into the file are the rest of the container. I posted some more information and some links on the main page. --Nephele 04:37, 4 November 2006 (EST)

thumbsup! (Hmmm... We need a smilies plugin.) --Wrye 16:07, 4 November 2006 (EST)

"http://manual.b2evolution.net/Smilies_plugin" here you go :P

PS3 Save Files

I noticed that there is nothing on the page pertaining to the PS3 save file format for Oblivion. Is that because it is very convoluted, or rather because no work has been done towards that end? — Unsigned comment by 71.193.126.82 (talk)

I am not aware of anyone who has transferred a PS3 save file to a PC or otherwise been able to look at the file's contents and format. It seems almost certain that the basic format of the save file would be the same as that described on this page. The only anticipated difference would be whether the PS3 adds any encoding or security layer, such as that added by the Xbox 360. --Nephele^Talk 11:19, 17 August 2007 (EDT)

I have, actually, transferred a save file to the PC. It is rather easy to do, simply highlight the save file using the "Saved Data Utility" and copy it to a USB or SD card, and transfer it to the pc from there. The file structure is markedly different, though:

• PS3
  • SAVEDATA
    • BLUS30007-SAVE-1
      • ICON0.PNG
      • PARAM.PFD
      • PARAM.SFO
      • PIC1.PNG
      • SYS-DATA

So, as you can see, the format here is a lot different. I know that other PS3 games use this exact same format, with some filenames changed or files added and removed. The PARAM files seem to contain the general Name, Level, Location, Time, etc. whereas the SYS-DATA contains a whole bunch of apparent gibberish. It does not match the specs given on the save file format, so I've come to the conclusion that it may be either compressed or encrypted.

I'd be willing to bet that one of those files matches the savefile format described here. Basically, there's no reason for the Bethesda team to rewrite all of their input/output subroutines just because the game is being played on a new platform. They'll do the bare minimum necessary to meet the PS3's requirements, rather than restructure the entire data file.

If the SYS-DATA file appears to contain a lot of gibberish, then that's probably the savefile, because the data is all saved as binary data. In other words, you need to parse the data according to the format specifications provided here in order to make any sense of the information. Looking at the data in a text editor or word processor it will be nearly completely unintelligible. --Nephele^Talk 01:22, 19 August 2007 (EDT)

Please mind that the PS3 is, if I remember correctly, a big-endian platform: the bytes on anything longer than a single byte type of data are in reversed order compared to the native PC format. A conversion might be necessary before attempting to parse the file, or maybe you can try opening it on a Mac (which is big-endian too and won't need conversion) instead of a PC. --Namu 17:31, 28 February 2008 (EST)

Thing is, even if it is big-endian, it shouldn't quite look like gibberish, just jumbled some. And it pretty much looks like gibberish. I also ran it through a number of compression programs (even going as far as to dig up Unix compress and give that a go, after a number of more likely candidates like gzip), but nothing came of it--though that's probably not conclusive, I'm thinking that it's probably not that. 76.4.241.126 17:50, 30 March 2008 (EDT)

It is definitely more than the file being big-endian. I did a histogram on the values of the bytes, and each occurs roughly the same number of times. The rarest byte value is 113 and occurs 3185 times in my file, and the most frequent value is 60 occurs 3505 times. This flat distribution is almost certainly the result of cryptography since it looks like what you would expect if you generate all the bytes randomly. So, this file needs to be decrypted before it is edited. 206.124.142.228 22:49, 17 April 2010 (UTC)

Does anyone have any updates on this??

It can't be that different, but from the looks of it, and from last time i checked when i copied a savegame to my computer, at least the screenshot itself isn't present in the savefile but rather as that extra file, and the same should apply to any location information (I think PC also had that) which would mean that the header of the file could look completely different but the rest of it should be the same. That would be the sane approach for Bethesda, since data duplication isn't good, and the PS3 firmware likes to have screenshots and savefile descriptions for itself. Jyujin 06:00, 17 August 2008 (EDT)

I think certain sections of the 'sys-data' file are referred to in the 'param.sfo' file, and, from comparing different files, the encryption changes, this is, the same file copied 5 times, each file changes, but certain bytes stay the same...

I've also managed to change my conjuration skill, from 57 to 999, if you exceed three ASCII characters, then the file becomes corrupt, the rest remain 00 00 00 00 00 00 00 00 etc, DO NOT CHANGE THEM.