ZSR Forums

Explanation:
http://pastebin.com/FqqFQLvA

Videos:
https://www.youtube.com/watch?v=13xHP6YsdWU Any% bottles theory
https://www.youtube.com/watch?v=OVuZv5-wuBo OoT3D version

Docs:

Some explanation stuff: http://www.reddit.com/r/speedrun/comments/2usz7c/oot_get_light_arrows_in_the_deku_tree/

NTSC 1.0 Chest list (should be same for all "vanilla" oots): http://pastebin.com/gEcbRZTj


Get item table, aka the list of items you can obtain via a hold up animation. For the purposes of this glitch, chests will write their contents to the variable in question as a negative value. So 0x100 - the index column = value written by a particular chest.

http://wiki.cloudmodding.com/oot/Get_Items_(ovl_player_actor)#Get_Item_Table


Theoretical list of items obtainable from the trick for NTSC 1.0. Some values may change during runtime which is where the next file comes into play:
https://docs.google.com/spreadsheets/d/1iC55h-oy3NAIW739yNQ8Cg9QNpDGTyVRys_NLHpnG_o/edit#gid=0


Listing of values that change during runtime within the space used in the "glitched" get item table. Purple = values that change, pink is unrelated:
http://imgur.com/DW4PJSP


Cool Images:

http://puu.sh/fuYSb/8013814d1c.gif

By NTSC, do you mean the US release, or actual NTSC, i.e. US and JAP?

There's a one byte difference between NTSC U and J for n64 releases, and it certainly isn't within the data I dumped. This is what I mean by NTSC 1.0

The weird Navi glitch, where she gets stuck in the bottom left behind the camera, looks to behave just like if an item was hovering in your face. Zfg got it on stream yesterday but didn't do anything with it, so when it happened to me I continued as normal to see what it'd do. No recording, but it crashed my console as expected. It skips the dialog box when picking up the item though, so perhaps it has some value. Looks like it also prevents interacting with doors.

Regular seeds + map crash:
https://www.dropbox.com/s/wx5rga2s5hmhqj4/IMG_20150205_053252.jpg?dl=0
https://www.dropbox.com/s/z3bcyn4r115sxmm/IMG_20150205_053257.jpg?dl=0
https://www.dropbox.com/s/5rr80hqemit2dkg/IMG_20150205_053307.jpg?dl=0
https://www.dropbox.com/s/e9noual4f49rsvx/IMG_20150205_053319.jpg?dl=0

Weird Navi + nuts + map crash:
https://www.dropbox.com/s/itn8uzg7qmrpta4/IMG_20150205_173138.jpg?dl=0
https://www.dropbox.com/s/dtajwbhnztegya8/IMG_20150205_173146.jpg?dl=0
https://www.dropbox.com/s/ma1h9xcdfajz2du/IMG_20150205_173200.jpg?dl=0
https://www.dropbox.com/s/vgqqwjgee8brarz/IMG_20150205_173213.jpg?dl=0

Those screenshots are pretty useless. The only useful info is the RCP hanging, which is not unexpected based on what I know so far about the glitch.

Important variables:

Link's instance is at 801DAA30. Link's X coordinate is + 0x24 to this if you're not smart enough to know how to convert real addresses.

0x0424 from the start of Link's instance is the "get item" byte value
0x066C from the start of Link's instance is a series of flags for different states that Link can be in.

066C
 0x20 - Stops Link and other enemies from walking/performing actions. There seem to be more variables than this one. Walking While Talking is triggered when this variable is zeroed when it shouldn't

066E
 0x04 - Seems to be used for collecting items? This is the bit that when set causes Link to receive an item when surfacing the water.

That's very useful, do you happen to have an MHS save file handy? Also, is there a page somewhere where all of your notes can be found? I'd love to help but I wouldn't want to re-invent the wheel.

Thanks

The MHS sticky has one for Mupen re-recording. Converting it for other versions of Mupen is pretty easy, since all you have to do is solve for the offset to the start of ram used in the MHS save, subtract the known addresses by that constant (giving you the real N64 addresses) and then find the new constant starting point to the ram for the version of Mupen you're using, then just do maths.

I don't have very many notes about this particular glitch (hoping someone will give me a list of things they tested), but I've got some documentation of Link's actor here:
http://wiki.cloudmodding.com/oot/Ovl_player_actor

Ok, some more info (some old, some new).

Crashing is caused by lifting an item. The reason for this is complex, and I'm not 100% on this explanation.

Here's roughly how things normally work:
* Link runs into an item or opens a chest
* The game calls whatever function to make Link hold an item over his head and collect it.
* The value at 0x424 from Link's instance is grabbed to perform a lookup of the Get Item table (http://wiki.cloudmodding.com/oot/Get_Items)
* The object id is used to pre-fetch an object_gi file. This file contains the model that Link will hold over his head.
* When the game is ready to render the item being held over Link's head, the game copies the get item model id variable from the Get Item table (after making it a positive value) into 0x852 from Link's instance. This number sets the specific model to render, and is an index into another table of data that contains the proper references for pointing to the model within the object_gi file we loaded into memory earlier.

Now, here's where things go wrong with GIM. When you collect an item and do GID, you load the object_gi file and lock the model id variable to that of the model of the item you interrupted. When you jump into the water and surface, the game completely skips the routine for pre-fetching the proper object_gi file, but changes the "shader" to that of the new item. This results in the game not being able to find the proper start of the model, which then likely causes it to read a bad display list which then causes the RCP to flip out.

This is related to the new stuff Skater found somewhat with the Anju collection delay.

When you set up GIM and then receive a pocket cucco from Anju, you will swap object_gi files from whatever item you used to do the GID with the pocket egg object_gi, resulting in crazy graphical glitches because the object_gi file is swapped several frames before gi model id is updated.

You can also change the object_gi file loaded by simply holding up a trade item while GID is set up. This can either cause instantaneous graphical errors or no perceivable effect (though I feel like odd effects happening occurs less often).

However, this doesn't come close to explaining how Skater is able to get different items with the new trick

Just been looking at your google doc and apparently items like boomerang and hammer are impossible to obtain with this glitch. Is this because the chests necessary to obtain them don't exist (i.e a chest which has master sword) or is it some other reason?

the "item (desc)" column lists all the items that should be obtainable with this glitch (0x80-0xFF), plus the valid items you get normally (0x00-0x7C).

If it's not there, there's a small chance of manipulating the chest contents (that's an aspect that I still need to look into more), but if that's impossible it isn't.

New Info:

Bombs (+10) chest can be used to get item #200. BA/RBAing this item is completely useless since it hits a section of the visited room flags in forest that is never touched.

I think Skater was able to use GID to double collect on chests. If true, this would be useful mostly for small key chests.

According to your table big poe should be impossible to get but I managed to get it in BotW after grabbing a stick, humping the compass chest and jumping in water. The game would keep crashing but if I pointed the camera in the right direction it wouldn't crash (this is on emulator). It gave me a text box with two options (in japanese so I couldn't read but it had the numbers 10 and 50) and if I picked the second option quite a few of the textures unloaded.

I dunno if this is expected or not but I'm happy to make a video if necessary.

Not sure what part of the table you were reading but it states on the table that you can get a big poe from the compass chest or a key chest (192 and 190). I haven't actually seen the text for it though, and what you said about camera angles sounds very promising if it also means we can get N64 to not crash

I'm curious if it's possible to get a bottle using BotW GIM with this method if you don't have a bottle already. I've tried for a while to get the Green Bubble to hit me while I pick up a Deku Stick while exiting the crawlspace in BotW, but it seems to be just barely out of reach. (Maybe if you have Bombchus to propel you into it it'd be possible?)

As well I tried placing a Bombchu down, quickly entering and exiting the crawlspace and then hitting the stick and having the Bombchu's damage activate GIM, but this as well seems to be just a few frames away from possible, however it needs more testing.

 IIRC the only two ways to get a bottle with the crawlspace GIM method right now are Deku Tree and Zora's Domain, if we could do it in BoTW it'd open new possibilities for puzzles and bingos.

I was watching a stream of someone who had a consistent method, I want to say it was Runnerguy. He was trying things you did, none of them succeeded. Even if you have the bombchu explode on the frame you grab the stick, the explosion acts the same as if you pulled ocarina to damage buffer. The green skull still flies around but the explosion doesn't tick.

I checked back the next day and he was doing this method. If you have a fairy and bombchus, you go into the room where the bombchus are (under an bombable floor right in front of the main entrance). He saved his game so the floor was open already, used bombchus to damage himself to 1/2 heart as he walked to the main room, then threw the deku stick into the river where the green skull would go. Then he clipped through the bombchu door wall and drowned while going back up into the main room, and during the fairy revive animation he grabbed the stick. I forget which chest he was using, probably the small key, but it gave a different item every time.

Indeed, but you need a bottle to do that method. I hoping to find a method without a bottle, in addition to the Deku Tree and Zora's Domain methods at current.
Oh well.

I can't see the point to get a GIM bottle in bots since it's gonna be slower than the cuccos.... Probably.

https://www.youtube.com/watch?v=byt76ZqbZTs Here is a vid fot LA in botw tho. important fact: I didn't crashed in the vid, but sometimes I did on different save files, I don't think it's because of the camera but on what you have in your inventory (or the flags you activated maybe ?)

Made a significant discovery with GIM.

I found what was overwriting the get item's object file (which contains the data for the model Link holds up). It turns out that the title card that appears when entering a new area is loaded into the same slot in memory!

This is likely the reason why buying the an item from a shop before the title card disappears delays obtaining that item... the game has to wait for the title card to disappear before its safe to load the get item object file.

Anyway, knowing this I figured out that you could prevent loading the title card by simply warping in to a location using Farore's Wind.

What does this mean?

Well, if we can figure out a way to set the flag that gives an item when surfacing the water WITHOUT loading a new object file when performing GID, we could get this to work on N64 by casting FW in Deku Tree/BoTW, get a bottle from Anju, then return with FW and perform GID.

For those on emulator I found a way to at least not get it to crash when hitting the water and getting your item:
Backup and change links instance + 0x134 u32 ActorMain to 0, pick up item and change it back to original value.

Less complicated (if your purpose is simply to play around with GIM and test stuff), go get the Slingshot and you can perform GIM with Deku Seeds (doesn't crash).