

Everything about shine mines:

Reflect Sphere Position Update Flag ( RSPUF ):



If a character has an active reflect sphere, it's absolute position on stage is updated into the characters data structure during projectile-player collision tests. The position is drawn from the absolute position of the "reflect" bone, which is determined by the action-state initiating the reflect sphere. However, the reflect sphere position can be needed many times a frames. Presumably in order to save work, the game sets up a bit flag in the character data ( RSPUF,

at 0x19E8, leftmost bit

) so that the reflect bone position is needed to be resolved only once in a frame. If RSPUF is 1, the reflect sphere position is "updated", and the reflect bone position calculation to acquire the sphere position for collision test is skipped, and the sphere position is used drawn straight from data.

(x, y and z co-ordinate floats for reflect sphere are stored at (0x19EC - 0x19F8))





Why Shinedrop through a platform is special:



Normally, every action-state that setups a reflect sphere will also take care of turning off

RSPUF .

(done in a "physics function" determined by the action-state, probably because it's run every frame)

However, shinedrop action-state immediately setups a reflects sphere, but it fails to turn off RSPUF for the first 2 frames, until transitioning to "regular" aerial shine reflect. As a result, if RSPUF was left on before shinedrop, the game will skip updating the reflect sphere position, and instead uses the last defined position. The last defined position can of course be anywhere on the stage, and doesn't need to be near to where fox/falco is shining.





Setupping a shine mine



In a regular match, RSPUF is only ever turned on exactly when it's needed: when the reflect sphere location is required so that collision check with a reflectible projectile can be resolved. There needs to be a projectile in play that could be reflected by the character (own projectiles won't do), and the character needs to have an active reflect sphere. Otherwise the collision logic involving reflect sphere position isn't run, the sphere position won't update and RSPUF won't be turn on. Note that as the action-states with reflect sphere, aside from shinedrop, will turn off RSPUF every frame, you'll also need to exit the action-state before all projectiles disappear and before the reflect sphere deactivates (2nd case applies to shielding).



The commonly known setup is shining while (enemy) projectile is on the screen, and jumping out of the shine. That leaves the reflect sphere location where the jump started. Another way to setup a mine involves GuardReflect (Digital shield start-up action-state, "powershield")

(Possibly new, I haven't heard of this from others.)

Starting a powershield reflect window while a reflectible projectile is on screen will leave the reflect sphere location to where the powershield was. You do need to leave the shield at frame 3 the latest, as otherwise the reflect sphere disappears, but RSPUF will still be turned off.





How a mine can deactivate:



Once you have setup a shine mine, it will persist when the projectile(s) that was on screen disappears, and the mine can be used to reflect entirely different projectiles later. The mine persists even through a death and respawn. However, starting any action-state that has active reflect sphere while there's no reflectible projectiles in play, will turn RSPUF off and deactivates the mine that way. Regular (non-power) shield will also do that despite it having no reflect sphere. The only exception is that you can shinedrop for 2 frames and immediately jump out, as in the first 2 frames of shinedrop the RSPUF isn't turned off.



The "Go Mine"

How can the mine in the gif at the start of this post work, as shinedrop is the first action the falco takes, there's no setup?



Match start is an interesting special case. It turns out the area of character data where the reflect sphere information is stored later isn't initialized when the character is created. The area will contain "garbage data" from what the memory was used for in the previous scenes. In fact it's not ever initialized, data is just fed into it. The collision logic doesn't recognize the data is garbage, and uses that garbage as a position data for reflect sphere. If RSPUF happens to be 1 at the start of a match, then the collision logic interprets the following data as position co-ordinates for reflect sphere, and fox/falco can spawn a reflect sphere at that "random" location with shinedrop. As the garbage doesn't necessarily consist of floats, they'll most likely be 0.0 when loaded as floats, or very large values. In the gif, the sphere spawns at (0, 0, 0) . Common way for the critical part of RSPUF being 1 at the start is the previous data in the block being a pointer. The contents of the reflect sphere location data and

RSPUF

at the start of a match depends on at least characters, ports, and stage chosen. When games are started with exactly matching configurations, the results seem consistent though.





Develop mode hitbox display oddity:

