Tes4Mod talk:Save File Format

The UESPWiki – Your source for The Elder Scrolls since 1995

Contents 1 Changes to Page 2 Patch 1.2 / Shivering Isles 3 Pending Questions 4 Xbox save files 5 PS3 Save Files

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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

[edit] 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? ^{—The preceding unsigned comment was added by 71.193.126.82 (talk • contribs).}

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)

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)