wonkashot

Wonkashot explanation
---------------------

Somaria in slot 9 decreases any value stored in $039D by 1 every frame. It just does. Always.

$039D is also where the game puts which slot the hookshot is in when spawned. So if you start a hook in slot 4, it will be set to 4. If you start it in 2 it will be set to 2.

The game's code for handling what to do when Link is using hookshot uses $039D to find the slot, instead of going through each slot looking for the hookshot. Developers be like "I mean, you can only have one hookshot on screen, and it's not like Link can do anything while the hookshot is in effect. We can trust this value." Well except the Somaria in slot 9 will decrement whatever value we put into $039D by one, each frame, until it's set to 0. Suddenly it no longer represents the slot index of the hookshot.

The way the game knows how long it should pull Link, is to count how long the hookshot was "thrown" before it hit something, then it just decrements that value back to 0 while moving Link. When it's 0, the game knows to terminate the hookshot etc. It makes sense - instead of checking if Link has reached a destination, it just counts the frames the hookshot took to reach the destination, and it knows it should take the same time for Link to get there.

(Weirdly enough, it ALSO checks whether you've reached your destination, to decide if it should terminate the hookshot. Or I guess it's not weird, they didn't want Link to clip into things.  I'll come back to this later.)

But what if it starts counting down on the wrong number? Because that's exactly what's happening with this glitch. The reason is in the first paragraph above.

Timeline of a wonkashot:
- Link presses Y. Hookshot is spawned and moving forward. Let's say it's in slot 4.
- For each frame it moves forward, a counter for slot 4 is incremented. Luckily for us, it does not use $039D, it uses the real slot for this.
- Once it hits something that Link can be dragged to, it starts pulling Link towards it instead. And it puts the slot into $039D.
- First frame of pulling, $039D will still be 4. So it will decrement the counter for slot 4 to determine if it should stop or not.
- Next frame of pulling, $039D will have become 3, due to Somaria in slot 9 decrementing it. So the wrong counter will be used to determine if we should stop being pulled or not. As long as it's not 0 or negative, it won't stop the pull.
- Next frame it's slot 2, then slot 1 then slot 0.
- After $039D has become 0, it will stay at 0, and you will keep decrementing the same counter. The wrong counter.
- It's not only using the wrong slot for the counter, it's also using the wrong slot for direction of movement!

In addition to using the counter, it also compares Link's coordinate with the hookshot's coordinate, and if Link is within 2 pixels of the hookshot (only in the direction Link is traveling), then the hookshot will terminate. Except since the slot is wrong, it actually compares Link's coordinate with old ancillae's coordinates! This is why when the trick was found, it sometimes worked on some pixels, and other times not. This should not be a problem anymore. (See below.)

Also a small note in this section - make sure you beam into a wall (or at least from a known good coordinate) if you want to eliminate the chance of EG. (I'll explain more in the more technical section below.)

So to get a healthy and prosperous wonkashot, we need to:
1. Have somaria in slot 9
2. Manipulate counters for slot 0 to be a high value (if we want a long distance wonkashot). For example, sword beams puts a high value (0x4C), so if you pop a somaria block and slash sword (with full HP) before any sparks leaves the screen, the beam will end up in slot 0, and slot 0 counter will have the value 0x4C, which should allow for a 76 frame wonkashot (or 304px of clipping).
3. Manuipulate counters for slot 1 and upwards to at least be 1. Because if it's 0, then the wonkashot will terminate before it hits slot 0, and be a wonkyshot instead.
4. Manipulate the directions (especially of slot 0). If you want to wonkashot leftwards, make sure the first beam goes left (in current setups).
5. When you do step 2 and 3, you have to consider where the coordinates of your ancillae will end up being. Especially step 2. If you sword beam the bottom of the wall, and you want to wonkashot downwards, then your wonkashot will not work except from specific coordinates. If you make sure the beam hits a block or something, higher up in the room, then you can hook from any point below that, and be safe.


For the initiated, here's some ram addresses, values and extra information.

- Link to somewhat annotated code: https://puu.sh/DKzl2/70108f4250.txt

- Note that if you hookshot from slot 1, then you only need to set up the counter for slot 0. However, I'm not sure if that's easier or not, but it does enable more setups to be used.

- The counters are found at $0C5E,X.

- Old ancillae coordinates are found at $0BFA (Y) and $0C04 (X)

- When you throw a boom, put down a bomb, produce sword beams etc. the game will write which direction you were facing into $0C72,X. As noted above, if you wonkashot from slot 4, it will decrement the counter at $0C5E,X for slot 4, then 3, then 2 etc. It will actually also use the directions from $0C72,X. So it's possible to set it up for Link to move rightwards for 3 frames, then upwards for 76 frames or w/e. Could come in handy in specific cases I guess.

- Some directions are pretty interesting, like if you set it to 9, Link will move diagonally, and really quickly. But I don't see a way to manipulate this array like that.

- To completely remove chance of EG, then make sure $03A4 is 0. Depending on your actions with slot 0 previously, you can set this to zero or nonzero at will. The reason we sometimes get EG and other times not, is because we use sword beam in slot 0, and the sword beam makes the memory cycle 0,1,2,3 until termination. To make sure it's 0, sword slash into a wall or something. If EG is what you actually want, then find a coordinate to slash from.

- If $03A4 is nonzero, then this is what happens:
  a) pseudo EG is toggled ($0476)
  b) The floor Link's in is decremented ($A4)
  c1) if $044A (EG strength) is 0, add 16 to the room number (basically a DG)
  c2) if it's 1 (strong eg) toggle $EE (Link's layer)
  c3) if it's 2 (weak eg) it does neither of those two crazy things. But a) & b) is done either way.

- Note that as long as Link transitions during the wonkashot, there is no chance of EG happening, as that code will not run at all in that case. However, I have noticed that I don't get chest contents in the room I wonkashot to. $A0 is set correctly, so not sure why. Perhaps some hookshot related RAM is not properly deinitialized.


Item values for the counters at $0C5E:
- Arrow, 8. Arrow in wall: 9 eventually.
- Boom: 1. 4 if it hits wall immediately.
- Hook: FF. Can get 0-2 by hooking from close distance.
- Bomb: 0B after explosion. Convenient if you don't need more since it's slot 1 & 0.
- Powder: 9
- Fire rod: Depends on distance. 24-2A. More if you can follow the shot in a big room.
- Ice rod: 2
- Bombos: 0
- Ether: 1
- Quake: 37
- Lamp: 0
- Hammer (star hits): 1
- Somaria: 0
- Byrna: 4
- Cape: 3

Other values:
- Boots dust: 6
- Bonk: FF
- Somaria sparks: 0
- Sword beam: 4C (distance traveled does not matter)
- Sword slash (master sword or better): 4
- Sword slash (fighter sword): 0
- Spin: If you interrupt it, from 0-49. If not, ends up at 3.
- Receive Item (pick up heart container, crystals etc): Depends on item?