mzxrules

In the commercial N64 releases of Ocarina of Time, there exists an extra file for N64DD related purposes. It's located after "code" in the file table. It appears to exist in all N64 commercial releases, but the pal releases do not have the same text inside of them utilizes black magic to store the text for all 3 languages simultaneously?. This file is seemingly removed from the GCN releases. In V1.0 the file is located at B8AD30-B9DA40. In the PAL versions I think that you can search for B014A26 to find the file.

You misunderstand. The game maintains a position that is restored if, for example, you go below -4000 y. It's my guess that Farore's Wind records this position when you set a return point, and also that one collision poly type will also put you back at this position.

First, can anyone explain all of this better because I've wanted to simplify this page but it's a complete mess to me: http://wiki.spinout182.com/w/Zelda_64:_Collision_Format#Polygon_Types Second, there has been some research into a glitch called "Void Warp", and what we've discovered is that there are at least two types of out of bounds collision polys. One is an instantanious zone out if Link steps on / is over it and respawns you based on the entrance index at I think 15E660 in the Debug Rom (it's where the save stuff starts), while the second respawns you based on the coordinates that would be stored by Farore's Wind if you set a return point. Is this known/correct?

*Legendary Light

Transition actors (which includes door actors) are added into the scene files rather than individual room files. You don't have to order transition actors in any special way.

The Gerudo Valley bridge is a massive set piece that actually completes both sides of the valley (ex. the stone bits near the bridge are actually part of the actor). Without the actor, there is no collision spanning the two points as it would be crazy to modify the scene's collision mesh mid game. Instead, the actor provides the collision, loading the appropriate meshes depending on whether the carpenter's have been rescued. Checking Link's age isn't redundant unless the broken and fixed versions of the bridge are two different actor instances. Edit: oh that bridge Edit2: The 004A bridge is used during the opening credit sequence, in which the bridge appears to always be down. The check may be related to that.

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

The ovl file is a separate entity from the actor instance (by instance I mean the variables that make up one copy of an actor), and I can already calculate the size of that file in ram using the vram addresses in the actor table. 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.

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

Without a 3DS emulator/debugger or the source code, no.

I like how I said the patcher was complete, and then ended up changing the ui of the program considerably as well as adding a neat little icon that took far to long to accomplish.

Vote over, Avatar picked.

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 1000000FWhat 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.

Vote Now

I think Air figured out her mistake, but I will address the points she brought up anyway for others reading: It's not. While saves are 1450h bytes long, the checksum is located at offset 1350h, which should mean that the only data saved is stored between offsets 0000 and 1350 since that data is verified by the checksum. 15E660 + 1350h = 15F9B0 so the range I posted isn't wrong. When you defeat a boss, you set a clear flag which is part of the scene save data. There is no separate flag set for determining if a boss has been defeated. Furthermore, bosses like Gohma do not check the save data, but rather the "local" set of scene flags (located near 1CA1D8 in V1.0, so somewhere similar in the Debug Rom. It works like this: - Actors interface with the "current" scene flags. Allows for actors to be re-used in different scenes/scenes can be re-ordered. - Current scene flags are copied into a specific spot in the save data based on the current scene number. - Copying into the save data occurs either when saving or scene reloading are triggered - Since the current scene flags aren't copied over every game tick, the perm scene flags located in the save data aren't always up to date.

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).

How?

The community seems pretty dead.

The patcher program for the mod (which is based on the code for my Dungeon Rush patcher) is complete. Just waiting for the go-ahead to release it.

Looks similar to a pose used by Princess Ruto during the credits.

"I have only done this once before." The contest is simple: Post any image you would like me to use on The-GCN. I will use it as an avatar for a minimum of 1 month. Rules: You have one week to post your images. Suggested avatars must be posted on this thread within one week from the creation of the thread. Images posted after one week will be disqualified. Once all the candidates have been listed, a second thread will be created where you will be able to vote on the best image. Maximum of two images can be suggested per person. Suggested images must not break any forum rules.

But you can reference C#'s Lists by index just like an array, and actually you can do it with any custom class if you implement an indexer http://msdn.microsoft.com/en-us/library/6x16t2tx.aspx

string Pointer = "10B5FD08"; //later on int pointeraddress = HexToDec(Pointer); lolwut

So a few more actors have been added in this doc, still a wip. http://pastebin.com/qGkumjx2 Edit: Found an odd bug, not sure if it's something needing fixing though since my xml def is wrong. <Definition Number="0x0117"> <Item Index="0" ValueType="System.UInt16" DisplayStyle="Hexadecimal" Usage="ActorNumber" Description="Actor Type" ControlType="System.Windows.Forms.TextBox" /> <Item Index="2" ValueType="System.Int16" Usage="PositionX" Description="Position (X)" ControlType="System.Windows.Forms.TextBox" Mask="0xFFFF" /> <Item Index="4" ValueType="System.Int16" Usage="PositionY" Description="Position (Y)" ControlType="System.Windows.Forms.TextBox" Mask="0xFFFF" /> <Item Index="6" ValueType="System.Int16" Usage="PositionZ" Description="Position (Z)" ControlType="System.Windows.Forms.TextBox" Mask="0xFFFF" /> <Item Index="8" ValueType="System.Int16" DisplayStyle="Hexadecimal" Usage="RotationX" Description="Rotation (X)" ControlType="System.Windows.Forms.TextBox" Mask="0xFFFF" /> <Item Index="10" ValueType="System.Int16" DisplayStyle="Hexadecimal" Usage="RotationY" Description="Rotation (Y)" ControlType="System.Windows.Forms.TextBox" Mask="0xFFFF" /> <Item Index="12" ValueType="System.Int16" DisplayStyle="Hexadecimal" Usage="RotationZ" Description="Rotation (Z)" ControlType="System.Windows.Forms.TextBox" Mask="0xFFFF" /> <Item Index="14" ValueType="System.Byte" DisplayStyle="Hexadecimal" Description="Type" ControlType="System.Windows.Forms.ComboBox" Mask="0x10"> <Option Value="0x01" Description="Silver Rupee" /> <Option Value="0x00" Description="Control Actor" /> </Item> <Item Index="14" ValueType="System.UInt16" DisplayStyle="Decimal" Description="Rupees to Collect" ControlType="System.Windows.Forms.TextBox" Mask="0x0FC0" /> <Item Index="15" ValueType="System.Byte" DisplayStyle="Hexadecimal" Description="Switch Flag" ControlType="System.Windows.Forms.TextBox" Mask="0x3F" /> </Definition>Note the "Type" item has a mask of 0x10, but has an option value of 0x01 (which is impossible) for Silver Rupee. Now if you open up map 12 of shadow temple (tested in decompressed 1.0 but should work in debug I think), scroll down the list of actors with the down arrow. The type combobox will be blanked for all but the control actor. Now, scroll up. Rather than a blank option like before, it will display the actor as being a Silver Rupee.