This was brought up a few weeks ago, but for for anyone who doesn't follow the oot community closely, a hilariously awful quirk known as crit walk was figured out.
If you're at 1 heart or less health, on every 256th visual frame (i.e. frame 0x000, frame 0x100, frame 0x200 etc) starting from entering the scene, the game will alter your "forward facing" direction by a random amount between 0 and 10000 rotational units, or 0 to about 54.9 degrees to the left.
This code is located within the NORM1 camera function (NTSC 1.0 80038A14, offending code starts around 8003936C), so it doesn't come into play with all camera states, like Z-Targeting for instance
@Slowking: Spectrum creates a map of how things are laid out in RAM. It is quite helpful for understanding different aspects of a number of glitches.
With Wrong Warping, some cutscenes are stored in actor overlay files, meaning that the cutscene pointer will be placed within a space in ram I call "Actor Heap". With spectrum you can better understand how that memory is being utilized, and perhaps find new manipulations with these types of cutscene pointers.
Ocarina of Time also has a number of glitches related to memory management, from the "Hyrule Field" glitch where the game simply runs out of free "Actor Heap" space, to the Ganon Barrier duplication glitch, to the more recent glitch where feeding a Bombchu to a Dodongo corrupts the block list managing "Actor Heap".
Lastly, the code blocks for actor files are mapped dynamically to a ram address, meaning that for example, the code file for Dodongos will have a different start address in ram depending on how you progress through the dungeon. Spectrum allows you to easily hone in on the start address, making debugging easier.
More on topic, it was recently discovered that you can in fact perform GIM in the Deku Tree on N64. In order to accomplish this, you need to first buy a bean plant. Then, when you perform Get Item Delay with Deku Nuts, you simply pull out the bean, which will change your GI object file to the bean plant's. This is enough to avoid the crash.
recently released a big update to a memory mapper program for the Zelda 64 engine called Spectrum
I think it should work for any 32 bit N64 emulator, provided you set it up to locate the start of ram. Could be of use to someone here
Hello All,
I realize that most likely no one will see this since no one has posted an OoT run since two-thousand and freaking four, but I, and aspiring speedrunner who is attempting to discover new tricks, have some questions. If you can answer any of them, please do so.
1) What RAM value stores the player's name?
2) " " " the respawn entrance?
3) What format is text stored in? (hex, dec, &c.)
4) Why has the ZeldaSpeedruns.com website been down for a few days?
Thanks!
For 1&2, there is a structure I call the "Save Context", which is stores data pretty much the same way across all versions, and thus addresses here can be converted easily. In NTSC 1.0, it's start address is 8011A5D0. The player's name is stored at offset "Save Context" + 0x24. The "respawn" entrance is a bit trickier to give, since there are multiple variables involved used for spawning Link into the game.
If we're talking base entrance indexes, there are two such variables in the save context. One is at 8011A5D0 itself, which stores the base entrance index of the area you're currently in as a 4 byte value (rather than the normal 2 byte value). Then there's the 2 byte base entrance index used as part of the "checkpoint" respawn data, located at 8011B948.
Then there's another variable located in a different structure known as the "Global Context", which is located at 801C84A0 in NTSC 1.0. In this structure, there's another variable that stores what base entrance index will be used to spawn Link, set before leaving the immediate area. It's another 2 byte value located at 801DA2BA.
3) You didn't phrase it awkwardly, you phrased it in a way that showed how clueless you are about such things. Anyway, OoT's English/French/German dialog is stored in Ascii, while the Japanese dialog appears to be stored in Shift-JIS. Console output (which only appears in the Debug Builds and can't normally be seen) is encoded in EUC-JP. The player's name uses one of two non-standard character sets, one for the US/Japanese builds, and one for the English/French/German builds.
4) I see nothing wrong...
More seriously though, from what I've been told the main issue with ZSR being down is that we get a serious amount of traffic. Maxx (the site developer) has been trying to work on it recently, and actually switched hosts for the front end site a short while back.
andypanther wrote:
mzxrules wrote:
Seems a little silly to host tases of rom hacks while banning MQ 64.
MQ has an official release, ROM hacks are pure fan creations.
Very important things to clarify the GIM
To be honnest, I don't really know why it crashes on N64 (notice that it also crashes on VC or emu depending on the item you use to do the GIM)
However
It has been proofed that the GIM wouldn't crash on N64 if there was a way to not show Link while he raises his hands in the water (maybe it's possible with HP duplication ???)
Also, I heard that GIM only crashes with nuts if you have the 64DD (?!) so please if anyone has a 64DD and could test that would be awesome !
The real mystery is why GIM doesn't crash on VC. We (or maybe just myself and a few people) have a relatively good understanding of why GIM crashes on N64. It does so when the game attempts to render the "GIM"ed item over Link's head, because the game sends a garbage task to the RCP. I've talked about it on ZSR, but I'll recap here as well.
When you collect an item that Link lifts over his head normally, the game displays a "hi res" model of that item. The data for the model (called an object file) is loaded off of rom on the fly into a special block of ram located immediately after Link's instance that is reserved for small graphical assets related to Link. This space is thus shared by all of the models held over link's head, as well as the "Title Card" graphic used when entering a new area. Lastly, there's a set of ids given to every different "get item" model (GI ID) that Link can hold over his head. The GI IDs are used to look up the start of the model, relative to the start of the shared space. When the game is ready to render whatever model over Link's head, the game sets a variable in Link's instance to the value of the appropriate GI ID. This data is conveniently stored in the same table used to determine what item you receive.
Get Item Manipulation Sheet
The process is different with GIM. You start off by collecting whatever item for the first time (for simplicity, lets say it's the Deku Nut). The Deku Nut GI object is loaded into ram, and the model id to render is set to 0x12 (0xEE is a signed byte, the sign is used for something else). When you manipulate what item you get and surface, the game doesn't overwrite the Deku Nut GI object file, but it overwrites the GI model id, which changes where the game looks for the start of the model.
Thus when Link is rendered, the malformed task of rendering the model over his head is sent, and the RCP chokes on it.
There is one other potential way to prevent the crash, at least for some situations. When you collect Light Arrows or the Blue Potion, it just so happens that those two GIMed items set a GI model id of 01, which correlates to an Empty Bottle. If there was a way to keep the Bottle object file loaded, the game wouldn't crash.
ok first of all, can everyone use real N64 addresses instead of whatever address mhs reports? They aren't that hard to figure out and having them makes it 100x easier to use addresses across different emulators. I really should make a proper guide for this, but writing takes a lot of effort for me. I wonder how many people still think that MHS doesn't work with PJ64
Assuming your monitoring NTSC 1.0, the first address's real address is 8011A5D0 (it's actually a word sized variable here, but if you treat it as a short it would be at 8011A5D2).
Also, that second address you list is actually used for setting up where you go to NEXT, not for storing your previous entry point... that's what the first address is for.
Anyway, looking into it, I figured out everything that is going on in the video.
Before I can begin, I need to explain zoneout types. There is a variable that stores what type of zone out occurred last. There are a few values that have different effects to them, but the most important ones here are zoneout types 1-3, and -3. Types 1-3 are special because these respawn link based on a previously stored coordinate. Type 1 is used for standard oobs checkpoints, Type 2 is used for returning from a grotto, Type 3 is Farore's Wind. Type -3 is used for zoning out from a warp song, but overwrites some of Type 2's variables.
You start off by playing Minuet, while locking your current entrance index in order to reach the top of Tower Collapse. When warping with Minuet, Type 2's entrance index is overwritten, setting things in motion.
When you reach Tower Collapse, zoneout type 1's respawn is set. You then lock the current entrance index to 61. This is actually wrong because the value of 61 is the scene id for the Grotto, not a proper entrance index to one. It works out fine though in your video because the proper entrance index is 0x3F (63 in decimal), and you are an adult, giving you a complete entrance index that takes you to the grotto, but if you were a child you would end up in the shooting gallery.
Now when you fall oobs like you do in your video, you trigger a Type 1 zoneout, causing you to reload the tower collapse zoneout coords. Your next entrance address is set to the tower collapse zoneout, but locking the current entrance index variable to 61 causes you to spawn in a grotto.
When you spawn in the Grotto, zoneout type 1's respawn is NOT set, because this is special cased. There are two reasons for this. First, when setting the return point Farore's Wind copies zoneout type 1's coordinates over into zoneout type 3. Second of all, it's a little known fact that Farore's Wind initially work everywhere at one point during development.
This brings us to exiting the grotto. Leaving a grotto sets zoneout type 2, and zoneout type 1's respawn is not updated again. The zoneout type 2 respawn is only fully initialized on entering a grotto. By default, all variables for zoneout type 2 are zeroed out, meaning that you spawn at entrance index 0 (Deku Tree), in room 0, at coordinates 0,0,0, rotation 0, with Link's spawn parameter set to 0, making him invisible and with locked controls. By playing minuet at the beginning, this sets your entrance index to 0x600 (Sacred Forest Meadow) instead, but with all other variables mostly the same.
Lastly, since you spawn and fell out of bounds, you triggered a zoneout type 1, which is still the tower collapse respawn. The best part here is that you can then lock your current entrance index and start the process all over again.
The (J) version of OoT has faster text. It doesn't feature any glitches that are not possible on the (U) version as far as I know. If the any% (U) version had a completely different route due certain glitches not being possible, then there probably would have been multiple versions.
The N64 NTSC releases are identical save for a character that sets the game language, but there are a set of wrong warps that behave differently because a different language is used. Reason is that with these warps the cutscene pointer ends up pointing to a space that previously had a texture with text on it, but was not overwritten. I don't think any major routes are affected by this though.
GIM could potentially be affected for similar reasons, but we'd need to find a special way to trigger Get Item Delay.
OoT in general is messed up though because the current any% route is impossible on a proper N64 emulator.
Would the VC rom extracted and made to run on an actual N64 also not freeze for that glitch?
The US/Japanese VC rom is identical to NTSC 1.2, whereas the PAL rom is almost identical, save for a small tweak in a dialog box in the French? localization. Or in other words, no.
Amateseru wrote:
I heard from Mzxrules (no from is mouth but this is what I saw on some chats) that there is an infinite loop when the Link put the item above his hands.
Deathbasket tested something and traced through with Nemu and fount that the RCP ended up getting stuck in an infinite loop. I don't know exactly what was tested though since there are actually several different scenarios with GIM.
As for the thing Skater found, particularly with Anju, it's kind of odd. I want to investigate it further
Reading wikipedia, the hardware for the iQue is looks to be the same stuff as an N64, so it should be possible to create a binary (rom) file that is compatible with existing N64 emulators.
The tricky thing is getting to that readable binary. Looking at the files that Aleckermit gave me years ago, it appears that the files are compressed and probably encrypted.
There is something weird that I've noticed though. The Ocarina of Time cache folder contains two rather large files: one that's 29MB in one folder, and one that's 40 MBs in a second folder. I have a theory on the contents of these files:
The 29MB file may be a 32MB oot rom, equivalent to a direct rip of an n64 rom, that has been compressed/encrypted with whatever algorithm. Or, it could be the demo that comes pre-installed.
The 40MB file however may be a 64MB oot rom where the internal yaz0 files have all been decompressed. Then the 64 MB file has been compressed/encrypted with the same whatever algorithm.
So there could actually be two different iQue roms.
Ganondoor might not be working because of this: by performing the 231 skip, you end up changing Link's speed when exiting the door, thus the timing for Ganondoor will either be different or impossible.
Normally, Link's speed when walking into an area depends on how fast he was moving when touching the previous exit. However, certain spawns will lock Link's speed to a fixed value, which is the case when entering the Deku Tree. When you go through doors and touch a loading zone, your velocity is reverted back to the stored value, thus the speed is always consistent when performing Ganondoor normally.
Wow, I just learned about this improvement 2 days ago when Cosmo described it during Awesome Games Done Quick 2013. I didn't expect to see it in action so soon! Thanks! :D
I mentioned it on the Oot thread some months ago.
Slowking wrote:
I thought the fact that temp flags are transfared was figured out by accident, with other wrong warps, wasn't it?
I need a history lesson here. :D
A considerable time before wrong warping was discovered, Petrie wrote up a thread on the perm/temp flags for hacking purposes, and I worked on understanding the save format. This thread and a few discussions with petrie helped me understand most of how scenes saved permanent data, and how farore's wind saved temporary data.
At this time, one could have made the conclusion that temporary flags persist between scenes, as this is easily observable with the push block puzzle in Dodongo's Cavern by backtracking from the boss room to the dungeon, but nothing could really be made of this knowledge.
Wrong warping was discovered some months later. At the very least, I knew that Farore's Wind could be used to transfer temporary flags long before it was found that knocking down the slingshot ladder dropped the stairs in DC, but I never actually looked into it until someone stumbled onto knocking down the ladder in DT to drop the stairs in DC, due to the relative newness of Wrong Warping, schoolwork, and my work on a project to map out perm scene flags.
As evidence of this, a quote from my #zelda logs from ~February 27th, 2012, before Ganondoor.
"[00:37] <mzxrules> because I have a theory about wrong warp that temp flags can be transfered between dungeons"
I put the idea on the back burner until the DC thing was discovered
~May 19th, 2012
[14:10] <Runnerguy2489> mzxrules, did you see the thing about getting the slingshot or something in deku tree, doing wrong warp and then having the DC stairs being down?
[14:11] <mzxrules> Runnerguy, that makes no sense
[14:11] <mzxrules> slingshot wouldn't set stairs down
[14:11] <mzxrules> perhaps something in that room sets a temp flag
With this I put in some effort to get a better understanding of how temporary flags worked, mainly when temp flags are reset (It's dependent on what exit used), and what flag values are set by what (Deku Tree's Slingshot Ladder sets the same bit that the Dodongo's Cavern Staircase sets, and the same bit as the lowest gate back into Tower Collapse. r0bd0g did help push me in the right direction: Tower Collapse.
~May 20th, 2012
[16:24] <r0bd0g> is there a flag in deku that opens the bars in the tower
[16:25] <r0bd0g> if you could open the door behind you, you might be able to fall oob after the cs and then zelda still be there?
[16:25] <mzxrules> i only found one flag in deku
[16:25] <mzxrules> temp flag
[16:25] <mzxrules> just the ladder
[16:26] <r0bd0g> are the bars in the tower temp flags?
[16:26] <mzxrules> idk
[16:26] <r0bd0g> it might open one of them and if it was the one behind you it might save a bit of time
[16:27] <r0bd0g> idk something worth double checking maybe
[16:28] <mzxrules> the gates are temp flags
[16:32] <mzxrules> found the temp flag related to Deku's slingshot ladder
[16:34] <mzxrules> it's tied into the lowest exterior tower gate
Tower Collapse sequence. This one uses normal OoT 64. Basically, sock discovered that falling OoBs during the tower collapse sequence occurs when the difference between the starting height of your fall and your current y become greater than a certain distance (320 units).
It turns out that when you are hit mid-air, your fall height is reset to the distance that you were hit at, making it possible to drop down to the next level.
http://www.youtube.com/watch?v=W4Z2FRUyjWA
MHS is pretty straightforward to use once you figure out how to lock on to a program. The trick is to find the start of the N64's ram block, since then you can search for values within just the 4/8 megabyte block.
Even better, unlike Project 64, the ram starts at the same offset from the start of the program data.
Are you able to lja bit in the forest temple without buffering? It should be doable on console.
Also it's really confusing when you say things like "bite can be done from the forest temple" when you mean that you can perform the bit for bite in the forest temple.
It is definitely the door at 15:28.
However... I just realized something very interesting about Master Quest.
The Deku Tree in Master Quest sets more temp switch flags that we can use. The flame switch on the top floor unlocks the gate after the one at 15:28, the falling floor in the Deku Tree unlocks the first exterior gate ("F4"), and most interesting of 'm all, the ladder no longer unlocks the last exterior door, it unlocks the "F3" door.
Why is it interesting? Because it means that if you jump OoB you can skip the first floor.
Edit: I want to point out that I haven't tested any of this with Ganondoor, if someone would try it out in just normal OoT with the ladder that'd be great.
I'm pretty sure it's the last door on the exterior, but I'm not sure it'd be worth the time to get chus in Any%, and MST would just do it normally anyway.
No. DC stairs and DT slingshot ladder are NOT permanent changes.
Slowi is still right about perm flags though.
There is a spot in memory I call the SRAM block because when the game is saved, an exact copy of this ram block is stored in the SRAM.
Inside this block exists a rather large segment that I call the Scene Flags. This block stores all the permanent flags tied in to a particular scene, except for certain actors (like skulltulas for example).
It's important to note that the main dungeon and it's boss room are two different scenes.
Now there's another block that petrie discovered that stores the flags that affect the current scene, including the permanent Scene Flags. Permanent Scene flags are updated in this temporary holding, then pushed into the SRAM block either when the scene is left or the game is saved.
Anyway, there's a part of this temporary flag block that stores temp "switches", like the DC Stairs or the DC "boss door" puzzle. It starts at 801CA1CC (version 1.0) and is a full word. The byte at A1CC is special because it stores room local flags that are reset when the room is exited; It should be impossible to store these flags with FW, and they are reset on death. The last 3 bytes are typically related to an area rather than just a single scene, and are reset depending on the exit used. The state of these 3 bytes can be stored in FW, but FW will only store the state they were at when at the last room entrance (most likely meaning the either the last door opening or death).
If necessary, timed temp switches like crystal switches can be kept by leaving the room they were set in either by outrunning their timers or death warping.
With the help of Gregortixlkyns's OoT Bingo route, I discovered temp dungeon flags are not reset when death wrong warping, meaning that death wwing will preserve temp flags, much like FWWWing will restore temp flags to the state they were at when the restore point was set.
The only thing discovered so far is that the ladder in DT's slingshot room shares the same temp flag as the flag that determines if the bombable staircase in DC is down.
<p>Wrong Warping: This is a glitch which allows Link to warp to a different location than expected by exiting a room in some way while a timer is ticking down for the warp in that room. It's done by performing the ocarina items glitch at the very edge of a blue warp at the end of a dungeon. Doing this allows the player to actually control Link during the cutscene where, normally, he would be floating up towards the ceiling. When the duration of that cutscene is up, the screen will simply fade to white (even though Link is on the ground) and the normal cutscene will begin. However, if the room is left in some way at a very precise moment, the game will warp you to a certain location, which is determined by the last cutscene viewed prior to doing the trick. Fortunately, the cutscene required to warp to Ganon's Castle is the Deku Tree opening cutscene, which is directly on our path in this run.
Location is determined by a combination of the entrance index set by opening the door, and the number of the cutscene that would have played if the blue warp cutscene were to follow through. The last cutscene never determines where a warp takes you initially, it only determines what cutscene (if any) will play following the warp with most wrong warps.
Knowing what the last cutscene was is critical to the success of the trick as different cutscenes will cause the game to look at different locations in the ram for the cutscene, and if the data there can't be interpreted nicely the game will crash.
