Get Item Manipulation (GIM) is a memory manipulation glitch which can be used to modify which item you receive from an item drop. This is possible by first performing Get Item Delay (GID), a collection of different tricks that allow you to interrupt the normal collection of an item that Link will display over his head. By doing GID, a flag that denotes that the player is getting an item will remain set, allowing you to obtain an item whenever you surface a body of water. From there, you can manipulate what item you receive by standing near certain actors that update Link's "Get Item" value.
When you normally collect an item that Link holds up, the game freezes other entities by setting one of Link's state flags (specifically, Link Instance + 0x66C, flag 0x20000000), sets a state flag noting that Link is getting an item (Instance + 0x66C, flag 0x00000400), and sets Link state such that the player can no longer move him. If you trigger an event that can zero out the freeze entities flag after you've collected an item you can re-enable enemy movement, which allows you to take damage from an enemy, which forces a state change and allows you to control Link while the item getting flag is still set.
Alternatively, it's possible to force Link into a "busy" state where collecting an item won't properly lock him down but still set the "getting an item" flag, negating the need to use an enemy to become un-stuck.
While the item getting flag is set, Link will be in an odd state. Bombs and Bombchus will stop updating once they leave Link's hand, meaning that they won't explode and will hang in mid-air, and cannot be used for hovers or similar. Sliding doors cannot be opened, only doors with a knob on it can.
Lastly, if you leave the area, die, or reset the game, GID will be disabled, since the state is directly stored in Link's instance.
The following item drops can be used to initiate GID:
The item drop that was used to initiate the Get Item Delay does not have any effect on the item obtained from GIM. However, it does have an effect on whether GIM will crash later on.
If an item you can pick up is close enough to the crawlspace, you can enter it and exit it to cause the camera to temporarily be stuck in place. If you pick up an item drop during that time, you will be in a glitched state which allows enemies to move while you are holding the item over your head. If you get hit by an enemy while in this state, you will get GID.
If you drown or die in water, the camera will spin around for a few seconds. If you grab an item drop during this camera spin, then get damaged or get in an airborne state, you will get Get Item Delay. If you die out of bounds, the animation of the camera spinning around Link will be delayed until Link is in bounds, giving you more time to perform the GID.
The original method for enabling GID is to use the swim on land glitch.
To activate this glitch, you need to be in water, equip Iron boots while holding Z and a direction to swim with Iron boots. This will allow you to swim on land, and you can unequipped iron boots to continue swimming on land.
If you dive and use certain items (hookshot, bow, ocarina), you'll be able to walk around while in the diving state. Collecting an item in this state will trigger GID and store a ground jump.
This method is very interesting because it doesn't require any enemies after picking the item drop. However this can only be done as adult since you need Iron boots.
Once GID is active, we can manipulate the state of the Get Item value to change what item can be obtained on surfacing a body of water. The Get Item value is a signed byte variable located at Link Instance + 0x424 (NTSC 1.0 address 801DAE54). The absolute value of the variable is used as the index to the Get Item table, which uses a different indexing than the one listed in the Item Chart. The sign of the value determines whether Link should be able to "immediately" obtain the current get item, or whether the item will be obtained by pressing A to open a chest (or other glitched actors).
The following list of actions will modify the Get Item value:
Of the above, chests are the most important due to their negative Get Item value. Unlike opening chests, surfacing water with GID active does not negate the Get Item value before using it to perform a table lookup, meaning that GID allows us to look up data at an address before the normal Get Item table.
A list of items which are obtainable from the corresponding chest is here: https://docs.google.com/spreadsheets/d/1SLJzamokLb7wDOaJh5x8DsxmMBy9oIYawyDN3dAWppw
In some scenarios, GIM will crash due to a malformed display list. The specifics are as such:
After spawning Link's instance, an ~0x2000 byte space is reserved for scene title cards (eg. the Kokiri Forest texture that appears when spawning in that area) and objectgi files. In this case, object files can be thought of as the files that contain model and texture data for actors and other entities. objectgi files are a subset of these files, containing model data for the items Link holds up over his head, or holds out when showing a trade item. The space is only big enough to store one file at a time.
If they're similar enough, a single objectgi file can store data for what are technically different items. For example, all of the differently colored rupees use the same objectgi file. Thus, there exists what is known as the GI model id, which is used to set what item to draw. It indexes a table containing a draw function pointer and an array of segment offsets pointing to the display lists required by the draw function.
When performing GID, the object file id and the GI model id of the item you collect is looked up from the Get Item table. The object file is loaded into the reserved space, and the GI model id is set, allowing the engine to draw the model. When performing GIM, the loaded object file remains the same, but the GI model id changes based on the Get Item value. Thus, the game will either render an incorrect model or crash when surfacing the water depending on the last file loaded into the ~0x2000 byte space, and the draw command data referenced by the item being GIM'd for.
Crashes can be avoided entirely by manipulating the camera so that the Get Item model is off screen (and thus never drawn). Another option is to pull out a trade item like the Magic Bean to change the object_gi file stored. However, the act of pulling out a trade item can crash the game for the same reason mentioned above.
In order to greatly speed up emulation, many emulators (including official Nintendo ones) default to a high level emulation of the N64's Reality Co-Processor (RCP). Instead of creating an accurate implementation of the RCP (which has it's own assembly language and is reprogrammable through what is known as microcode), emulators will intecept the tasks sent to the RCP and interpret the data directly. In other words, the emulator will interpret the display lists directly as it sees fit, rather than be constrained by the limitations of the RCP. Furthermore, unoffical emulators allow you to change graphics plug-ins which can drastically change the effects of GIM. Crashes in one plug-in can be ignored completely in another. And in some cases, absolutely bizarre errors have been known to happen.
The following table contains a list of items that are generally known to work for GIM. However, it's entirely possible for there to be combinations of GIM that will not work.
Since object_gi files should be binary identical across versions, there should in theory be no differences between the PAL and NTSC versions.
|Item/Console||Wii VC||Gamecube||Wii U VC||IQue|
For N64, items than can sometimes work are magic jars, deku sticks and both shields. Additionally, if you collect a Deku Nut, you can pull out either Magic Beans or Zelda's Letter safely, and attempt GIM with that.