Difference between revisions of "User:Jongyon7192p"
|Line 61:||Line 61:|
Proved ttm DR is impossible without a breakthrough. Tyler Kehne then finds breakthrough.
Proved ttmDR is impossible without a breakthrough. Tyler Kehne then finds breakthrough.
==bitfs 0x (wii vc)==
==bitfs 0x (wii vc)==
Latest revision as of 21:28, 19 July 2020
glitchy wall kicks [failure to analyze]
sm64 1 key
This VCutM platform moves mario down just as mario flies into a PU. Since this isn't an OJ, this immediately upwarps mario into the surface of OoB water which conserves mario's speed AND voids him out back to the water of outside the castle WITHOUT killing him and putting him on land. Neat as fuck.
From the castle moat, mario reactivates his speed on land, and this is the PU route he goes to minimize his slow af turning time while still going down in Y position enough using slopes to touch the moat door back at the main map.
2336 ( 3,-3) +3,-3
2337 (14,-1) +11,+2
2354 ( 6, 3) -8,+4
2354 A (kill speed)
2356 A (kill speed)
2365 ( 0, 0) -6,-3
It's just a desmos graph.
Proved ttm is impossible without a breakthrough. Tyler Kehne then finds breakthrough.
bitfs 0x (wii vc)
Converges and reaches 0 after 2 or 3 months. Must find bad_boot's graph again to confirm.
Approximated the speed cap to be 160. If mario can keep punching on the pillar for an extended 1 more frame, spd can reach 170 or more. i forgot my approximated 2nd value.
(1) the 10k glitch step
The fwd component of your joystick tilt is multiplied by (speed+100)/200. (It's intended that the result is your fwd component is halved or stays the same cuz your max slide speed should be 100 unit/f. But ofc, you hyperspeed, and you can do the 10k glitch.) We'll name this the "modified fwd".
(2) turn mario
based on the sideward component of stick tilt (which i define as "side"), rotate mario's velocity vector like this.
[ 1 0.05*side ] [velX]
[ -0.05*side 1 ] [velZ]
And then you do v\*oldSpd/newSpd for both x and z component, cuz the game wants to not change your speed. You can think about the implications of this yourself. (the max and min angle it can change depending on your speed, and other questions)
Your velocity vector is added by a vector of magnitude 7\*normal.H, pointing downhill.
Then the resulting vector is multiplied by the lossFactor, which is smth dumb defined by the slope type, and increases depending on the modified fwd. So this step does depend on your speed.
Finally, mario's facing angle changes by 2.8125 (360/128) degrees or less towards your velocity vector's angle.
Speed - 4 + 1.7\*normal.H (range: -4 ≤ accel < -2.3)
Speed - 1 + 1.7\*normal.H (range: -1 ≤ accel < 0.7)
Effects Overlap for 1f between the C^ and the Punch:
Speed - 5 + 3.4\*normal.H (range: -5 ≤ accel < -1.6)
WF Tower platform rotation displacement
the tumbling bridge block rotates in a stupid way, but i managed to decompose its euler angle frequencies into parts. Turned out fucking useless cuz we could just fucking yeet ourselves or smth, idk, ask iwer.
and i'll try to summarize my block of text now.
All but proven at every math-skill level. Please implement it.
target = -stickY*v/5 (max=±12.8v)
If crossed 0, cap |pitchVel1|<32 for 1f.
target = -stickX*v/4 (max=±32v)
If target<0< <yawVel , |yawAccel|=64 if <0<target<yawVel , |yawAccel|=32 If <0< <yawVel<target, |yawAccel|=16
If crossed 0, cap |yawVel|<16 for 1f.
a = -pitch/45° -.5[1-cos(yaw)] -1 cap v>=0
if v>16, pitchVel2 = 6(v-32), Range: ( -96 ~ +∞ ] //positive if v>32 if 4<v≤16, pitchVel2 = 10(v-32), Range: (-280 ~ -160] if v≤ 4, pitchVel2 = -1024
if nullWall collision, pitchVel3 = -512