mzxrules' notes on Ocarina of Time

[mzxrules]

Rather than create 20 threads for every little thing I mess with, I'm going to start.

C# Programs:

Ocarinabot - An IRC bot with various functions for Ocarina of Time / general irc stuff.
VCSaveGen - A crummy hex editor for editing save data from emulators/virtual console.
MasterOcarina - A C# code base that assists in my various rom hacking endeavors.
VerboseOcarina - Program that prints out various Scene/Map data.
Dungeon Rush (Rom Generator utility) - Converts a NTSC 1.0 file into the Dungeon Rush hack.
Petrie's Challenge (Rom Generator utility) - Converts a Master Quest rom into Petrie's Challenge hack.
zcodec - A newish/incomplete console based program that compresses/decompresses roms, and byteswaps them. More functionality will be added eventually
Spectrum - A simplistic console based memory viewer for the purpose of mapping out the game's ram in an attempt to understand the game better.

Other:

Ocarinabot Database - My own database for Ocarina of Time related stuffs. Originally started as an xls table for performing simple RBA calculations, it's been expanded to hold data on a number of different things (entrances, exits, dmadata).
Bitflag mapping xls file - A file I created to help map out the save format. Mainly covers flags (scene flags, event flags). Improvements to VerboseOcarina have largely replaced the need to continue documenting scene flags.

Other threads I've posted on:


NTSC 1.0 Notes - https://www.the-gcn.com/topic/2189-sods-oot-10-u-notes/
Collision Mesh notes - https://www.the-gcn.com/topic/2910-collision-questions/
Hookshot as Child - https://www.the-gcn.com/topic/2209-use-hookshot-as-child-link/
Porting Jabu Jabu's room between versions - https://www.the-gcn.com/topic/2685-lol/
Event flags - https://www.the-gcn.com/topic/2064-zelda-oot-event-flag-documentation-just-before-zelda/
Random Questions - https://www.the-gcn.com/topic/1996-random-questions/
Odds and ends (Scene header commands, object filesize limit, text format) - https://www.the-gcn.com/topic/3003-collection-of-things-i-discovered-last-week/

[mzxrules]

Double posting because I want to keep the posts separate.

 

Someone asked me for the tables I use in Ocarinabot, so I put 'm online here http://www.mediafire.com/download.php?qy26qtahw48hs5q

A lot of it is information taken directly from the wiki (the Debug File table, Actor/Object Tables), but I also have a proper entrance table with human readable descriptions for every position. I also have an almost complete table of cutscenes, with the known cutscenes all given human readable names, but the bank offsets are v1.0 only.

[Jason777]

Wait... I'm a little confused as to what Ocarinbot does? It interests me though

[mzxrules]

It's two big features are calculating Reverse Bottle Adventure and Wrong Warp results. The RBA calculator lets you calculate RBAs for both the 64 and 3DS versions, and allows you to even try out impossible combinations like...

 

!rba Sun's Song, Boss Key

The wrong warp calculator calculates the result of a wrong warp: What scene, what entrance, whether it will crash, what cutscene will play if that can be determined, or whether the previous cutscene is a factor. The way you use it, is you search for a scene...

 

!ootscene Deku Tree
<OcarinaBot> Deku Tree #0, Deku Tree Boss #17

Which will return a list of scenes paired with their index in the scene table. Then you use the index as a parameter in a command that looks up all the "base" entrance index values for that scene:

 

!ootsceneent 0
<OcarinaBot> x0000: from Kokiri Forest x0252: from Deku Tree Boss

Then you can either do a Death Hole Wrong Warp calculation with the !dhww command, passing the entrance index value as a parameter, or a "normal" wrong warp with !ww, passing in the entrance index value and the cutscene number the blue warp sets: 0 for Inside Jabu Jabu's Belly, 1 for Deku Tree and Dodongo's Cavern, 3 for Fire Temple:

 

!ww 0252 1
<OcarinaBot> x0252: Deku Tree from Deku Tree Boss with cutscene 1 will wrong warp you to x0257: Tower Collapse Interior Burning Rocks from Tower Collapse Exterior Lower but is affected by the cutscene pointer.

[Jason777]

So it's basically a glitch calculator? It sounds really complicated.. I'm really impressed!

[mzxrules]

I've been posting a lot of stuff in https://www.the-gcn.com/topic/2189-sods-oot-10-u-notes/ lately as I've been working on reconfiguring the entrances blue warps/cutscenes take you for a mod I'm calling Dungeon Rush.

I've been posting mostly v1.0 specific findings there, but just now I've found how to change which entrance and cutscene to play when opening a chest with the Silver Gauntlets inside.

It's located inside ovl_player_actor. These are absolute Debug Rom locations rather than relative to the file start.

 

C1D006: Check against what item was gotten inside the chest, to determine whether to play the cutscene (Default is 0035 for Silver Gauntlets)

C1D00A: Entrance Index (set to 0123). Search for 240E 0123
C1D016: Entrance Cutscene (set to FFF1 for cutscene 1).

[mzxrules]

Yaz0 Compression/Decompression algorithm for C#. Ported from C? code found at  http://www.amnoid.de/gc/index.html

 

http://pastebin.com/nvKLmRti

 

The intended usage is

byte[] Decode(FileStream sr, int yaz0BlockSize) to decompress a yaz0 block, where FileStream is assumed to be positioned at the start of the compressed yaz0 block.

 

int Encode(byte[] src, int srcSize, FileStream dstFile) to compress and save a yaz0 block, where the returned value is the size of the compressed file in bytes (don't think it includes the header as I only just added some code to print out the header).

[mzxrules]

Figuring out some stuff with Skulltula flags

 

They are located at offset 0x0E9C, and are grouped into bytes based on Dungeon/World Map location, which allows for the game to easily check which areas still have missing tokens. They appear in the following order in OoT 3d.

 

Deku Tree

Dodongo's Cavern

Jabu Jabu's Belly

Forest Temple

 

Fire Temple

Water Temple

Spirit Temple

Shadow Temple

 

Well or Ice Cavern

Well or Ice Cavern

Hyrule Field

Lon Lon Ranch

 

Kokiri Forest

Lost Woods

Market

Death Mountain

 

Kakariko Village

Zora's Domain

Lake Hylia

Gerudo Valley

 

Gerudo Fortress

Haunted Wasteland

Unused?

Unused?

 

This data is affected by endianness, so on a true N64 the ordering will be

 

Forest Temple

Jabu Jabu

Dodongo's Cavern

Deku Tree

 

Shadow Temple...

[mzxrules]

So something amusing popped up earlier today in # involving the Inventory screen.

 

There are two kinds of slots within the inventory screen: Those that display ammo counts, and those that don't. Now, the way the ammo count display works is a little weird. If you put an item on a slot that displays an ammo count, then the ammo count for that item will be displayed, but the ammo count is displayed at a fixed position. For example, if you use codes to put the Deku Sticks in the slot where the Fairy Bow would be, the Deku Stick count will be displayed over the Deku Stick slot rather than the Arrows slot. 

 

Now, if you end up putting an item that doesn't display an ammo count into an ammo count slot, then the game will try to display an appropriate ammo count for that item. For example, putting a Fairy Ocarina / Ocarina of Time over the Deku Stick slot will display the unused Ocarina ammo address as an ammo count. These items typically position the ammo count display over the Deku Stick slot, since they aren't needed anyhow.

 

It also turns out that if you put most bottle items (Fish, Bugs) onto an ammo count item slot, then the game will try to read the unused ram address set by Gerudo Mask Rba as an ammo slot, and display it over where the Deku Stick count is.  

[Three_Pendants]

Indeed, we still have yet to figure out how the Ammo Counts actually work and their placements. I would surely love to try and use some of the unused ammo counts, mainly for several items, the Boomerang comes distinctly to mind as an item that could have a "durability" counter, so to speak displayed as Ammo.

[mzxrules]

Petrie asked me about how I added in the Great Fairy Fountain into Dungeon Rush, which got me to thinking again about how certain scenes like the Shooting Gallery have exits which can lead to two or more different entrances. I figured out this much. If the index within the exit list for a scene is between indexes 7FF9-7FFF inclusive, then the entrance index used for that exit will be determined by a list stored within ovl_player_actor. The exit index partially determines what offset to start at within this list, while the entrance number (the value that picks the map/position couple) further determines what entrance index to use

 

DEBUG ROM ADDRESSES

C23398 - Exit list for index 7FFE (Great Fairy Fountain, Link Upgrades)
C2339E - Exit list for index 7FFB (Potion Shop? must have been only one scene at one time)
C233A2 - Exit list for index 7FFC (Bazaar)
C233AA - Exit list for index 7FFA (Shooting Gallery)
C233AE - Exit list for index 7FF9 (Great Fairy Fountain, Magic Spells)

[mzxrules]

Ok so a while back Petrie was working on figuring out how chests are displayed on map. From my IRC logs he was able to figure out that ovl_map_mark_data  (located at 00C27940 to 00C2E420) contains the data used to display the chests on the minimap screen (but NOT the pause screen map), and maybe more about the format in which this data is stored than I do.

 

Each room except for the transition room into the boss room has it's own minimap that shares the same room number (ex: Inside the Deku Tree, minimap 0 is of room 0, minimap 1 of room 1 etc.). Then if a room spans multiple floors, it's added on to the end of the list (ex: Deku Tree's room 0 spans 3 floors, has 12 rooms, so minimap 10 (-1 for no boss transition minimap, -1 because it's an index) is floor 2, minimap 11 is floor 3).

 

The format is pretty gross and I still don't quite understand it. It appears that you have up to 0x72? bytes per minimap, at least that's what it seemed like Nintendo was using. If you set values wrong you'll end up displaying the next minimap's chest data?

 

First 2 bytes serve as a sort of header. The first byte sets the icon to display (options are chest, boss skull, nothing, crash), while the second is the number of icons to display. Following that you have one byte for chest flag, one for x, and one for y coordinates relative to minimap's left corner. Higher Y values will place the chest icon closer to the bottom of the screen rather than the other way. FF is used as a terminator somehow;

 

At the very end of the file are some virtual addresses and relative offsets. The last word in the file is used to seek back to the start of a bounded array of relative offsets. The elements in this array point to virtual addresses that in turn point to the data for  minimap 0 for scenes 0-9. The first word in the array of relative offsets is the number of elements in the array. Each relative offset is in the form 82xxxxxx.

 

From this, I was able to port the Debug Rom version of ovl_map_mark_data into v1.0 J for Dungeon Rush: Master Quest. What remains now is to see if I can't port over the chest icon data for the map screen.

[Airikita]

ovl_Kaleido_Scope for the chests for dungeons on the status screen? Should be fun moving those to match the minimap. Of course, you can do the minimap later.

[mzxrules]

Dungeon Rush: Master Quest has kind of been pushed to the side for the time being, instead focusing on my other pet projects.

 

Lately, I've been working on improving Ocarinabot's OoT database and "Master Ocarina", which is the collection of C# projects that make up my rom hacking programs.

 

With Ocarinabot, I've been working on pairing v1.0 files to DBG rom file names to make it easier to modify v1.0. I've actually paired up all Scene, Room, Actor, and Object files, as well as a few paired up manually.

 

With "Master Ocarina", I've worked on untangling the mess of code used for creating the Dungeon Rush and Dungeon Rush 2 mods, and created a patcher program that create's Petrie's mod. I've also improved my scene/room reader program so that it's easier to pull data off of different rom builds.

 

Also, I fixed a few bugs / tweaked things with the C# Yaz0 algorithm I posted a few months back. The worst bug found was that in some situations (ex. encounters a long sequence of 00s used for padding) the algorithm would read in way more bytes than it could encode. I'll post the updated code soon.

 

I'm also thinking of maybe creating a console based program that performs a couple of functions I've coded but have to hack into a generic winform whenever I need to use them.

 

Some features I think i'll add:

- Ability to byteswap a rom

- Ability to decompress a rom (programs exist for this already, but it'd be trivial to implement)

- Ability to compress a rom, (using a source rom's file table, or by listing what files shouldn't be compressed)

- Ability to spit out specific files (ex. Files that are different between roms, all scene/room files that make up one scene)

- Ability to patch a compressed rom (similar to how Dungeon Rush does it)

- Ability to import scenes/rooms.

 

Lastly, I'm still working on improving actor definitions. I've gone through my notes in order to make things a little cleaner looking, and figured out how a few more actors worked as well. I'm sort of putting off adding more definitions to the xml doc for SceneNavi since i'm waiting for some improvements (really need some way to add comments for certain actors).

[mzxrules]

Today I decided to crack open Nemu and figure out this hacking thing.

 

For my first hack I decided to come up with a simple mod that allows you to save pretty much anywhere outside of dungeons in v1.0.

 

B06318 change 1061000E to 1000000F

What it does is it changes a BEQ? instruction located after all the special checks for the dungeon/boss rooms so that it always branches, and so that address 11A5D0 isn't re-assigned.

 

I also found a couple of addresses for things in the process

 

80057030 - Copy Save Function?: Copies save file from ram to 8011A5D0, one byte at a time. (Entire contents of the SRAM is loaded in memory while on the File Select.

800902F0 - Start of the Spawn Entrance Index correction routine. Immediately follows the call that copies the save file

B7EA40 - Jump Table for setting the spawn entrance index on save load. Indexed by the scene number that the file was saved in. 26 entries.

800FC090 - List of Entrance Indexes that are set to 11A5D0 when reloading a save inside a dungeon.

[mzxrules]

So lately I've been working on a program that I can use to better understand what is allocated where in ram, and from it I've come to understand a number of things a lot better. Some notes:

 

The actor table in code.asm is used to keep track of what actor overlays to keep loaded in ram, and is the structure that the debugger reads off of when printing one of the screens

 

Actor Instances and Overlays are managed by, unsurprisingly, a doubly-linked list structure in ram. In V1.0 the pointer to the start of this linked list appears to be located at 11BEF0.

 

Structure:

??????aa ssssssss nnnnnnnn pppppppp
???????? ???????? ???????? hhhhhhhh
???????? ???????? ???????? ????????

a = determines if the memory is free for re-allocation. 00 if it's being used, 01 if free.

s = size in bytes of the following file

n = next element pointer in the linked list

p = prev element pointer in the linked list

h = head element pointer

[mzxrules]

Where can I find how much memory is being allocated to an actor instance?

 

Edit: I figured it out. It's located at offset 0x0E in what the wiki calls the data block. A virtual address within the actor table points to the start of this data block.

Quoting myself to find this info easier/recent observation.

 

an ovl_En_Test instance allocates ~0x918 bytes for itself, much larger than the data blocks that I've been assuming to be the size of the instance (i think? it's 5am). One of the many things I'm working towards is creating a program that can output ovl file data, so I'll be able to understand this more perhaps

[mzxrules]

NTSC 1.0 File Listing

PAL MQ File Listing

 

The 1.0 file list has been around for a while, but the MQ one is new, and has been something had been meaning to get around to for a while.

 

These tables are generated mainly by locating different file tables located in code in the debug rom, and finding the corresponding table in the other versions.

 

Edit: File list turned out to be for PAL MQ

[mzxrules]

Bump to show I'm not dead/keep it easy for me to find this thread.

 

I think since I last posted on this, cloudmodding.com added wikis for OoT, MM, and OoT3d. Added lots of stuff to help figure out what file is what ootwise, as well as organized the stuff that was on spinouts wiki a lot better.

 

I also did a complete overhaul on the formatting for the Actor List so that it's a lot easier for documenting and modders. I also have all the data stored in an xml file, which is why everything is formatted so well. I want to add more metadata info but I'm not sure how to take it to that next step yet.

 

Posted this on the screenshot thread:

A charset for the Hylian langauge exists in the japanese character set. Can easily be used in game

[mzxrules]

Figured out what the 05 and 06 cutscene commands do. They position the camera relative to Link, and are affected by Link's Y Rotation.

Been investigating/documenting actor 008C (ovl_Demo_Kankyo) recently.

• When it's variable is set to 000D, it becomes the door of time and spawns actor 0070, which is the door's collision model.
• I located/documented the starting offsets for all the warp song cutscenes within it. This is how I figured out the purpose of the 05/06 cutscene commands
• Glitterberri mentioned that the actor lists a dependency of object 00B6 (object_gi_melody), a.k.a the Get Item Music Note. Based on this, it appears that the actor should spawn a music note when it's variable is set between 0008 and 000C, but nothing is displayed and I don't have the tools to trace through the draw routine.

Added some documentation on actor 0015 (En_Item00). Not sure if the random drop table is part of that actor, but it fits thematically so I put it in.

[mzxrules]

Today I solved much of the mystery of ovl_En_Wonder_Item, actor 0112. It is truly a wonder item, and quite possibly the most versatile puzzle element that nobody has fully understood...

 

Actor 112
 
& F800 = Type
- 02 = Invisible, free collectible
- 03 = Invisible Collision Box, drops collectible (see Z rotation)
- 08 = Bomb window?
& 07C0 = Items  Table located at DE970C NTSC 1.0
- 00 = 0C
- 01 = 06
- 02 = 0E
- 03 = 0F
- 04 = 03
- 05 = 08
- 06 = 09
- 07 = 0A
- 08 = Green Rupee
- 09 = Blue Rupee
- 0A = Red Rupee
- 0B = 12
- 1F = No item?
& 003F = Switch Flag
 
Z Rotation
- Additional parameter
//When type = 2 this is the number of collectibles spawned
//When type = 3 this sets the type of interaction that triggers the drop
// 00 = Drop on Sword Swing hit
// 01 = ?
// 04 = Drop on Slingshot Seed/Arrow hit
// 06 = ?

As you can see, the lesser known functionality to this actor is that it provides it's own collision, sets a switch flag, an can be triggered through a variety of different methods, meaning you can now create more weird "cow" switches

[CAS-1006]

If I could um... see a demonstration I'm sure I'd understand it a bit more.
Though I'm pretty sure everyone is sorta asking the question of "Can you explain this in better detail?"

[mzxrules]

bleh

ovl_En_Wonder_Item is completely invisible, and has no object dependencies (unless you're using type 8 since it spawns a hylian soldier to bomb you). In addition to that, wonder item sets a switch flag rather than a collectible items flag, even though it drops items.

 

If you're not familiar with either, basically there's a set of flags per area that every actor has access to that actors can read or write to in order to preserve their state or interact with one another. Switch Flags and Collectible Flags are two different subsets of these flags, where switch flags are used for nearly everything, while collectible flags are used for just item drops. 

 

Since wonder item is invisible, can be used anywhere, and sets a switch flag when triggered, there are probably a lot of creative things you can do with this actor with making puzzles. In Master Quest, Nintendo used them for cow switches by placing a cow down somewhere, then putting a few wonder items around it to give the appearance that shooting the cow triggers the switch on event. 

[Arcaith]

I wonder if some of the Z rotation params are things like 'explosion', 'walk into', 'roll into' etc? Be good to test it. I'm assuming that the switch flags are just a boolean of 003F and the clear flag to be used? If so, does it use the first or second byte?

[mzxrules]

I haven't tested all of the Z-Rotation parameters of type 3 yet so at the very least there's more to be found. If type 3 has no walk into, you could still just use type 2 to achieve the same effect (not sure if it works if no item is set, but you can just as well give a rupee). 
 
I think you're confused by my notation. & xxxx is meant to be interpreted as a mask that captures what bits make up a variable that has a non-standard bit length. I created it because when I first started working with the existing actor variable documentation, the notation used made it hard to see the underlying values that the developers were setting. I've gotten some flack for it not being the most readable form, but I like it because it's super concise since shift operations are implied.
 
Basically a mask of & F800 means that the value captured is the leftmost 5 bits, and has a range of 0-1F. You can easily see this if you plug it into something like Window's calc when you set it into programmer mode:
 

F    8    0    0
1111 1000 0000 0000

The 1s show what bits to capture, while the number of 0s to the right of the rightmost 1 adds up to the number of shifts to perform to read/insert the value (11 in this case).

So & 003F isn't meant to be a boolean state, but rather the standard range for switch flags (0-3F).

Also, every modder should totally be using this page: http://wiki.cloudmodding.com/oot/Actor_List_(Variables)