OoT3D Game Save Data Offsets and Info

I recently got a Save File backup device for my 3ds (http://www.r4i-sdhc.com/SaveDongle.asp) and because of my interest in OoT3D I began looking into the format of the save file and such, mostly the offsets for specific save data, by comparing multiple save files I'd set up.
I've spent several days comparing over 50 different save files I've set up to figure out the new offsets for different data and I've made some progress. (They've re-arranged and moved everything)
Now, most of the data I've collected is pretty much useless as we can't edit the save files without re-calculating the checksum for the file, but I've been able to confirm some theories regarding changes such as Iron & Hover boots.
For those familiar with the OoT64 Game Data Format will see that some things are kept the same, but they've moved. Like the ZELDAZ string for example. It is now placed after the File Name instead of before it.
They've also changed Data Types and Length of various things.

Here's a list of everything I've gathered so far: http://cloudmodding.com/zelda/oot3dsave

I also checked out NG+. But there weren't any unexpected changes to the NG+ save file. The only thing NG+ did was to write onto the "B Button (Current)" byte when creating the file.
And while I were at it, I also looked if there were anything different with the files that save on a horse or while fishing. I didn't see anything out of the ordinary.

It should also be worth mentioning that it seems like the placement of the items in the item menu doesn't actually seem to be within each save##.bin in the 3ds save file. They seem to be handled in a different manner.

When you set Farore's Wind after playing Boss Battle the Farore's Wind Map is set to FF FF FF FF. This can explain why the game seem to crash and reset.
I wasn't aware that entrances were stored in 4 bytes. Thought they were stored in 2.

When you use Shield Swipe Bottle Dupe to dupe over a blank button it dupes properly. However, since the item slot linked to the button you duped over still is value FF (for blank slots), the game will still treat it as a blank button. As a result, you won't see the bottle (the button will still be displayed as if it was empty), and as soon as the game reads the inventory grid again the slot will be disabled.
An interesting side-effect however is that by doing this, you can change the item linked to item slot FF (Blank). You can see which item you've written onto FF by highlighting a blank slot in the inventory menu. To do this, simply select an item you can't equip, then use the touch screen to attempt to move the item to a blank I, X, Y, II slot twice fast. The empty slot should be highlighted, and you'll see a transparent icon of the item linked to slot FF.

I recently figured out a much faster method to test stuff as well. As the save files have save counters, and the game create backup saves whenever you save your progress, I can simply save, do something, save again, do something, and then save again. Then I just look through the save, find the 2 backups and the current file by looking at the save counter, and compare the files. That way I can spot the effect of things easily.

Pages used as reference:
http://zeldaspeedruns.com/oot/ba/reverse-bottle-adventure
http://zeldaspeedruns.com/oot3d/ba/reverse-bottle-adventure
http://zeldaspeedruns.com/oot/ba/item-chart
http://zeldaspeedruns.com/oot/wrongwarp/entrance-index-list
http://oot.cloudmodding.com/wiki/Entrance_Table_%28Data%29
http://oot.cloudmodding.com/wiki/Save_Format

I would personally like to see the files for myself.

Some observations:

The length of the filename is incorrect. The range 1Ch-2Bh inclusive contains 10h items, not Fh. Also I find it somewhat curious that the filename's length is saved since the 64 version has a constant 8 1 byte chars.
The switch/hold settings are now part of the save format.
Are you saying that the tunic/boots byte (0xB7) is still active? As in, we can potentially rba over things?
Save for the MQ Water Temple crystal switch / locked door, the permanent scene flags aren't worth it to figure out on the 3ds version. The few flags you've figured out are enough to tell me that the vast majority will be identical to the 64 counterparts.

offset 0x0040 relates to 0x002C N64, however offset 0x007C relates to 0x0064, so somewhere between the two is an extra 4 bytes. Also, for reference.

mzxrules wrote

I would personally like to see the files for myself.

Some observations:

The length of the filename is incorrect. The range 1Ch-2Bh inclusive contains 10h items, not Fh. Also I find it somewhat curious that the filename's length is saved since the 64 version has a constant 8 1 byte chars.
The switch/hold settings are now part of the save format.
Are you saying that the tunic/boots byte (0xB7) is still active? As in, we can potentially rba over things?
Save for the MQ Water Temple crystal switch / locked door, the permanent scene flags aren't worth it to figure out on the 3ds version. The few flags you've figured out are enough to tell me that the vast majority will be identical to the 64 counterparts.

The Filename length is stored so the game knows how many bytes it should read. If you delete a file and create a new one over it, it will just overwrite the name from the previous file.
Example:
I create a file called "CloudMax", 8 letters.
Then I delete the file and create one called "Link". The save file will say "LinkdMax", and have a byte telling the game that the file name is only 4 letters long.
And yeah, the filename length is supposed to be 10. I recently rewrote it all in Calc/Excel, thought I fixed all the errors.
(Noticed that I did another mistake at the save counter offset)

The boots byte is still active, yes. This is the reason why you can't RBA over the boots item slot after you receive the boots. The game will revert them back right away as the tunic&boots byte says that you're supposed to have the boots. If you however remove the iron/hover boots from the tunic&boots byte with RBA, it is possible to RBA over the boots item slots again.

And I did not plan to figure out all the scene flags. The reason I wrote them down initially was to find the chest flag byte for deku tree (as it is the first 4 bytes in the first scene), then Dodongo's Cavern to figure out the length of one scene record. (as DC is the 2nd scene). Turned out that the scene record stayed the same on 3ds.

Just found a program that can open up 3DS save files in a file tree view (3DSExplorer v.1.5.1.0)
It allows me to extract each file separately. Now it all starts to make sense. The length of a save file is much longer than I previously thought, and the 3ds inventory grid is in fact part of the save file. (I have already documented the offsets for the inventory data, I just couldn't figure out it's offset relative to the save data)

Here's the save of my Main OoT3D file:
File 1: Sold Out on II as Child & Adult
https://www.dropbox.com/s/cnj2f9pnfc2r721/save00.bin

File 2: 100%, has LA&IA as Items, Hasn't opened Kokiri Sword Chest
https://www.dropbox.com/s/q6c9bnjofs5l9ir/save01.bin

File 3: FW NG+, at boss in all child dungeons
https://www.dropbox.com/s/1ypf84n9wd20kwu/save02.bin

File 4: Watched Intro Cutscene
https://www.dropbox.com/s/6q8m1p47161oev2/save03.bin

And here's the entire 3ds save file in one piece:
https://www.dropbox.com/s/qnvhiazhaprw5th/Version%201.dec (Decrypted)
https://www.dropbox.com/s/b8beto0fhj6j3g9/Version%201.sav (Encrypted)

I had totally forgotten about this, but I'm using the OoT3D from the Ocarina Edition, which means that I'm using the AUS version of the game. The save files does not support transfer between EUR and AUS copies of the game. It's quite a bummer, considering the other 2 cartridges I've previously used are the EUR version (I gave my original copy of the game with my first 100% file to my kid brother for christmas a few years ago, and my older brother is about to sell his copy of the game)... And I really wanted to transfer over them.. I've created save points at specific locations on them.
I do have a 4th copy of the game, a sealed one that comes with the zelda 3ds, but I honestly don't want to open it, even if it is a worthless game. :p

I can provide more examples and info on the specific saves if you need it.


The OoT3D Inventory Data seems to be located at offset 0x1370-0x13B9
the first 0x1A bytes stores what item you have in each item slot.
the next 0x18 bytes is a 6x4 grid (I, X, Y, II buttons is part of it) for child link, linking each inventory slot with a item slot.
The 0x18 bytes after that is the same thing for adult link.

Edit: Updated the list. Split some parts of the table into separate records, and added the OoT3D Inventory Data. And I wrote a function to calculate the Length for me (I'm writing everything in OpenOffice Calc) .. Started to get annoying having to fix the mistakes manually.

Edit2: Did some scarecrow song testing, and the offset seems to have moved by 0x18. I also performed a test to see where the World Map Data were located. And it seems to have moved by 0x18 as well.
I also noticed that both the Farore's Wind XYZ,Y-Rot Data & Farore's Wind IsSet Flag has moved by 0x18.
However, the X,Y,Z,Y-Rot section appears to be 0x14 in length instead of 0xA. This is just a wild guess from looking at the data, but perhaps they're using 8 bytes for each coord instead of 4, and 4 bytes for the Y-Rot. It would make sense as that way the Entrance Index is placed right after the Y-Rot bytes.

More things:
There appear to be two file names: The "new" file name which comes before ZELDAZ, and the old one which is unused. It's the sequence of 8 DF bytes following ZELDAZ. This explains the 0x14 byte difference: 0x10 from the name, 0x04 from the name length/game settings.

I speculated that this was the case when it turned out that RBA had changed a bit, but the save files confirm that the 3ds version stores values in Little-Endian byte order rather than Big-Endian as it was on the 64. This is why the Odd Mushroom/Pocket Cucco etc. RBAs changed.

As it turns out, if the next entrance index variable is set to -1? (FFFF in N64, FFFFFFFF OoT3d?), you will end up on the Title Screen. This is why restoring your FW point takes you there.

Edit: I figured out where all the extra 4 bytes at the start of the save come from, for the offset of +0x18.

The equipment data record for the original 64 game is 0x0A bytes, where you have the following bytes:
B Button item
C-Left,
C-Down,
C-Right,
C-Left item slot
C-Down item slots
C-Right item slot,
Unused,
Tunics & Boots
Sword & Shield

(note that Tunic / Boots order is different from 3ds).
Now, Grezzo extended this structure by two bytes. Why? One extra button.

Now in the original N64 version, the equipment data records for the Adult and Child equipment was positioned immediately after one another, giving us 0x0A + 0x0A = 0x14, whereas with the 3ds equipment record you get 0x0C + 0x0C = 0x18, a difference of 4. The equipment data record for the current equipment does not add any extra bytes because it appears that 0x0C bytes were allocated for that particular record.

Sorry that I just disappeared yesterday. Our internet line got cut at some digging site, seems to be back up now.
And yeah, I kind of forgot to mention that they changed the byte order on the 3ds version.

Now that we know what it is that causes the offset differences, it should be much easier to piece everything together.

I am still confused as to why the sequence of 8 DF bytes even exist. They are always set to DF, so it seems pointless?

As for the equipment data record, this would mean that byte 0009 is unused. And I must've been blind to not notice that byte 0005-0008 was for the item slots. It was so obvious.

I've made some updates to the list since yesterday. I also tried out things yesterday while internet was down and came up with some good results, going to post it in the discovery thread when I'm done testing.

Edit: Looking at the equipment data record... I finally understand RBA and BA. I never understood why it used C-Right or II. But it's because the B button doesn't have it's own byte storing the B Item Slot. :p

I guess this byte difference thing is the reason why some Wrong Warps are different?

If you RBA with a blank C-Right/II, or even bottle dupe over a blank slot, would it use 255 as the inventory offset? If so, wouldn't that point to Fire Temple Scene Data? Or am I completely misunderstanding?

EDIT: Actually, I think I miscounted... If it worked it would probably be Water Temple. Plus it'd probably be different between N64 and 3DS.

CloudMax wrote

Edit: Looking at the equipment data record... I finally understand RBA and BA. I never understood why it used C-Right or II. But it's because the B button doesn't have it's own byte storing the B Item Slot. :p

Doesn't the 64 RBA page explain that?

Pedalpowertoast wrote

I guess this byte difference thing is the reason why some Wrong Warps are different?

What specific wrong warps? There's more than one flavor after all.

nathanisbored wrote

If you RBA with a blank C-Right/II, or even bottle dupe over a black slot, would it use 255 as the inventory offset? If so, wouldn't that point to Fire Temple Scene Data? Or am I completely misunderstanding?

The 64 inventory starts at 0x8C. 0x8C + 0xFF = 0x018B
The scene data records starts at 0xEC. 0x018B - EC = 0x9F

0x9F / 0x1C = 5 for scene 5, Water Temple.
0x1C * 5 = 0x8C
0x9F - 0x8C = 0x13
0x13 / 4 = 4, which is the unused flags.

mzxrules wrote

Doesn't the 64 RBA page explain that?

Apparantly it does. I believe it wasn't there when I first learned RBA&BA, or I could just've missed it.
I haven't really read up on all the OoT pages though.
Found out about http://zeldaspeedruns.com/oot/ba/quickswap-sword-deletion today. And http://zeldaspeedruns.com/oot/ba/minigame-items-on-b yesterday when doing B item testing. :p The minigame items on B turned out to contain a lot of useful information, the page title was just misleading.

mzxrules wrote

The 64 inventory starts at 0x8C. 0x8C + 0xFF = 0x018B
The scene data records starts at 0xEC. 0x018B - EC = 0x9F

0x9F / 0x1C = 5 for scene 5, Water Temple.
0x1C * 5 = 0x8C
0x9F - 0x8C = 0x13
0x13 / 4 = 4, which is the unused flags.

So it lands on an unused flag for both N64 and 3DS? I'm not really surprised, because if duping over a blank C button did something interesting to the scene data, it would have been documented a long time ago. Still, it seems like just a couple bytes further and you could manipulate the map info in the Water Temple, which would be cool... Oh well.

I want to see two saves with very minimal differences between them. The best way to do to so is this: Simply play any file, save immediately, copy the output. Then do the same but wait a little longer before opening the save menu and saving.

mzxrules wrote

I want to see two saves with very minimal differences between them. The best way to do to so is this: Simply play any file, save immediately, copy the output. Then do the same but wait a little longer before opening the save menu and saving.

I'll get two saves ready soon.
https://www.dropbox.com/s/84w4albjp40odlj/save01Compare1.bin
https://www.dropbox.com/s/wgg2d3x336b7qvu/save01Compare2.bin
The save count is increased by 4 on the second file. The reason is because if I just save once without doing anything, the file doesn't really update itself. Or something like that...

And here's another set of two saves. This time I copied the first MQ save onto MQ slot 2. Opened MQ save 1, saved 3 times. Opened MQ save 2, saved 3 times.
https://www.dropbox.com/s/33gz2e4o85et8ru/save03Compare.bin
https://www.dropbox.com/s/hslz2dyqqor9o2e/save04Compare.bin
As you can see, the save counter isn't equal on both, even though it should be. The save initially had 2 saves. Then I copied it, and saved on both files 3 times. So both saves should have the value of 5. The second file says 4. Sometimes it seems like I'm not extracting the latest file, which is odd. If I were to continue playing on save 2, I believe it would continue from value 5 like it's supposed to, and not 4.

One thing I noticed a while back is that 004C-004D seem to increase constantly, like a timer of some sort. The faster I save the game, the lower the value will be (it seems to start at 0 when I load the file)
I figured that it would be the equal to this value:
"0x003A uint16_t 2 Some clock? Increments every cycle, unless the game is paused. Resets whenever a new map is loaded"
from the table here http://wiki.spinout182.com/w/Save_Format
Do you know what it is used for?

I think I just found the bytes storing the timestamp of the saves.
13BC-13CF Savestamp
13BC-13BF Year
13C0-13C3 Month
13C4-13C7 Day
13C8-13CB Hour
13CC-13CF Minute