Ukikipedia - User contributions [en]

Iwerlipse

2025-10-16T17:36:06Z

Aurumaker72: add info about SM64 Lua Redux integration

The '''Iwerlipse''' (pronounced ee-ver-lipse /ˈivɜlɪps/) is the range of positions Mario can occupy while he is in the air and cannot turn, assuming that drag is constant. The boundary of the Iwerlipse is reached by '''Arctan Straining''' - the optimal way of air straining that gives the greatest distance along a chosen angle <math>\omega</math> for a given number of frames <math>T</math>. For a single frame <math>T=1</math>, the Iwerlipse is an ellipse with half-width 10 (in the sideways direction) and half-height 1.5 (in the forwards direction). For general <math>T</math>, it resembles an ellipse with half-width <math>10T</math> and half-height <math>3T(T+1)/4</math>, but bulges at the corners, covering more area than an ellipse with the same dimensions. As shown by ''Grassdigger'', the shape is well approximated by a generalised superellipse, and thus ''Pannenkoek2012'' proposed calling this shape the Iwerlipse - a pun on the name of ''Iwer Sonsch'', who first discoverered that Arctan Straining was optimal in April 2018.

==Basics==

Arctan Straining gives the maximum possible distance along a target angle <math>\omega</math> that differs from the facing angle <math>\theta</math>, over a finite number of frames <math>T</math>. It is performed by choosing straining angles <math>\phi_t</math> (intendedYaw) such that

<div style="background:#f9f9f9; border-left:3px solid #bbb; padding:0.4em 0.8em; margin:1em 0;">
<math>
\begin{align}
\phi_t - \theta =
\begin{cases}
\arctan \left[\dfrac{10\tan(\omega - \theta)}{1.5(T+1-t)} \right] & \text{if } \cos(\omega-\theta) > 0, \\[14pt]
\arctan \left[\dfrac{10\tan(\omega - \theta)}{1.5(T+1-t)} \right] + 180^\circ & \text{if } \cos(\omega-\theta) < 0,
\end{cases}
\end{align}
</math>
</div>

with <math>t</math> being the frame number between <math>1</math> and <math>T</math>. (Usually only the top row of this equation is given, but since the <math>\arctan</math> function only gives results between <math>\pm 90^\circ</math>, we must add <math>180^\circ</math> to the result if the target angle is behind Mario.)

Arctan straining is a result of two asymmetries in how Mario's forward velocity and sideways speed are updated

* Forward velocity accelerates gradually over time, while sideways speed is reset every frame

* Straining on a single frame has a weak effect on forward velocity (increasing velocity by a maximum of 1.5), but a strong effect on sideways speed for a single frame (setting sideways speed to a maximum of 10).

In terms of total distance acquired along some direction, forward velocity is thus more effective over long periods of time, where it has time to accelerate to large values, whereas sideways speed is more effective over short periods of time. Optimal straining over many frames then involves straining mostly along the forwards direction to build up a large forward velocity, and then towards the end of the trajectory, transitioning into sideways straining to exploit the large sideways displacement obtainable in a single frame.

==Update Equations==

When Mario is in the air and cannot turn, the function <code>update_air_without_turn</code> is responsible for updating Mario's velocity variables from one frame, <math>t-1</math>, to the next, <math>t</math>. Without loss of generality, we can choose coordinates so that Mario's facing angle is zero. In other words, he is facing along the <math>z</math>-axis, while his sideways speed is directed along the <math>x</math>-axis. Mario's forward velocity, <math>v_t</math>, and position coordinates <math>z_t</math> and <math>x_t</math> are then updated via

<div style="background:#f9f9f9; border-left:3px solid #bbb; padding:0.4em 0.8em; margin:1em 0;">
<math>\begin{align}
v_t &= v_{t-1} - D(v_{t-1}, \phi_t) + 1.5\cos(\phi_t),\\
z_t &= z_{t-1} + v_t,\\ x_t &= x_{t-1} + 10\sin(\phi_t),
\end{align}</math>
</div>

where <math>\phi_t</math> is the straining angle (intendedYaw) on frame <math>t</math>. The total effect of drag is given by the coefficient <math>D</math>, determined by

<math>
D(v_{t-1}, \phi_t) =
\begin{cases}
-2.35 & \text{if } v_{t-1} < - 16.35 - 1.5 \cos(\phi_t),\\
-0.35 & \text{if } -16.35 - 1.5 \cos(\phi_t) \leq v_{t-1} \leq -0.35,\\
v_{t-1} & \text{if } -0.35 < v_{t-1} < 0.35,\\
0.35 & \text{if } 0.35 \leq v_{t-1} \leq D_\text{cap} + 0.35 - 1.5 \cos(\phi_t),\\
1.35 & \text{if } v_{t-1} > D_\text{cap} + 0.35 - 1.5 \cos(\phi_t).
\end{cases}
</math>

where <math>D_\text{cap}</math> is a soft velocity cap equal to 48 for long jumps and 32 otherwise.

In practice, these drag boundaries are far enough apart that the drag is often constant over large periods of time. In this case we can write Mario's position after <math>T</math> frames as

<math>\begin{align}
x_T &= x_0 + 10 \sum_{t=1}^{T} \sin(\phi_t),\\
z_T &= z_0 + v_0 T - D \sum_{t=1}^T t + 1.5 \sum_{t=1}^T \sum_{n=1}^t \cos(\phi_n).
\end{align}</math>

Using <math>\sum_{t=1}^T t = T(T+1)/2</math>, and by grouping terms of <math>\cos(\phi_t)</math>, the latter can be simplified to

<math> z_T = z_0 + v_0 T - \frac{DT(T+1)}{2} + 1.5 \sum_{t=1}^T (T+1-t)\cos(\phi_t). </math>

Notice that, since forward straining produces an acceleration that is not reset between frames, earlier frames have a stronger effect on the final <math>z</math> position than later frames. The effective strength is <math>1.5(T+1-t)</math>, i.e. 1.5 multiplied by the number of frames remaining (including the current frame), since the forward velocity gained on one frame produces a displacement also on all remaining frames.

==Arctan Straining Proof==

The displacement vector after <math>T</math> frames is

<math>\mathbf{R} = (x_T - x_0)\mathbf{\hat{x}} + (z_T - z_0)\mathbf{\hat{z}}</math>,

while the unit vector along the angle <math>\omega</math> is

<math>\mathbf{\hat{n}} = \sin(\omega)\mathbf{\hat{x}} + \cos(\omega)\mathbf{\hat{z}}</math>.

The distance we move along a target angle <math>\omega</math> over <math>T</math> frames is then

<math> S = \mathbf{R} \cdot \mathbf{\hat{n}} = \langle S\rangle + \sum_{t=1}^T S_t, </math>

where

<math> \langle S \rangle = \left(v_0 T - \frac{DT(T+1)}{2}\right)\cos(\omega), </math>

is due to our initial velocity and drag, while

<math> S_t = 10\sin(\phi_t)\sin(\omega) + 1.5(T+1-t)\cos(\phi_t)\cos(\omega), </math>

is the effective contribution from straining on frame <math>t</math>.
Thanks to this separation, we can maximize the total distance <math>S</math> by individually maximizing each contribution <math>S_t</math> as a function of <math>\phi_t</math>:

<math> \frac{d S_t}{d \phi_t} = 10\cos(\phi_t)\sin(\omega) - 1.5(T+1-t)\sin(\phi_t)\cos(\omega) = 0, </math>

and finally we find

<math> \tan(\phi_t) = \frac{10\tan(\omega)}{1.5(T+1-t)}, </math>

or, rotating the coordinate system back to allow for general facing angles <math>\theta</math>,

<math> \tan(\phi_t - \theta) = \frac{10\tan(\omega - \theta)}{1.5(T+1-t)}. </math>

Since <math>\tan(x) = \tan(x\pm180^\circ)</math>, this equation has two solutions for <math>\phi_t</math> which are given above.

== Iwerlipse Equations ==

By writing <math>\sin(\phi_t)</math> and <math>\cos(\phi_t)</math> in terms of <math>\tan(\phi_t)</math>, and using the optimal straining relation, we obtain exact expressions for the boundary of the Iwerlipse after <math>T</math> frames:

<div style="background:#f9f9f9; border-left:3px solid #bbb; padding:0.4em 0.8em; margin:1em 0;">
<math> \begin{aligned} x_T - x_0 &= \pm10 \sum_{t=1}^T \frac{1}{\sqrt{1+\beta^2 t^2}},\\ z_T - \langle z \rangle &= \pm1.5 \beta \sum_{t=1}^T \frac{t^2}{\sqrt{1+\beta^2 t^2}}, \end{aligned} </math>
</div>

where

<math>\beta = \frac{1.5}{10}\tan(\omega),</math>

and

<math>\langle z \rangle = z_0 + v_0 T - \frac{DT(T+1)}{2}</math>.

We can restrict <math>0 < \omega < 90^\circ</math>, with the four combinations of plus and minus signs giving the remaining quadrants.
The Iwerlipse's half-width is <math>x_\mathrm{max} = 10T</math>, while its half-height is <math>z_\mathrm{max} = 3T(T+1)/4</math>.

=== Approximations ===

If <math>T</math> is large, the exact expressions involve large summation terms, so it may be useful to have approximate expressions that are easier to compute.
By replacing the summations from <math>t=1</math> to <math>t=T</math> with an integral from <math>t=1/2</math> to <math>t=T+1/2</math> (essentially performing the midpoint rule of numerical integration in reverse), we obtain

<div style="background:#f9f9f9; border-left:3px solid #bbb; padding:0.4em 0.8em; margin:1em 0;">
<math> \begin{aligned} x_T - x_0 &= \pm \frac{10}{\beta} \left[\operatorname{arsinh}(\beta t)\right]^{T+1/2}_{1/2},\\ z_T - \langle z \rangle &= \pm \frac{3}{4\beta^2} \left[\beta t\sqrt{1+\beta^2 t^2} - \operatorname{arsinh}(\beta t)\right]^{T+1/2}_{1/2}, \end{aligned} </math>
</div>

with the notation <math>[F(t)]_{t_1}^{t_2} = F(t_2) - F(t_1)</math>.
This approximation converges to the true result very quickly:
even for <math>T=2</math>, the RMS error (normalized by <math>x_\mathrm{max}</math> and <math>z_\mathrm{max}</math>) is <math>4.3\times10^{-3}</math>,
while for <math>T>6</math> it is less than <math>10^{-3}</math>.
Similar expressions obtained using the Euler–Maclaurin formula converge more slowly, even with first-order correction terms.

A simpler but less accurate approximation is obtained by fitting the Iwerlipse to the generalized superellipse:

<div style="background:#f9f9f9; border-left:3px solid #bbb; padding:0.4em 0.8em; margin:1em 0;">
<math> \left(\frac{x_T - x_0}{x_\mathrm{max}}\right)^{m(T)} + \left(\frac{z_T - \langle z \rangle}{x_\mathrm{max}}\right)^{n(T)} = 1. </math>
</div>

The optimal exponents <math>m(T)</math> and <math>n(T)</math> have been found up to <math>T=150</math> (5 seconds), and can be obtained from a lookup table<ref>[https://drive.google.com/file/d/1xDmgHz878qiAS1ZF1Y5M0M1eiZUdZRSl/view?usp=sharing Showing Iwer's proof and deriving the Iwerlipse expressions.]</ref>.
Unlike the integral approximation, this expression never converges to the exact result — there is always some small error.

== Quarterstep Penalty ==

If <math>q \in {0,1,2,3}</math> quartersteps are lost on the final frame,
the forward velocity gained on frame <math>t</math> no longer accumulates forward distance over <math>T+1-t</math> frames,
but instead over <math>T - q/4 + 1 - t</math> frames.
The optimal straining relation becomes:

<div style="background:#f9f9f9; border-left:3px solid #bbb; padding:0.4em 0.8em; margin:1em 0;">
<math> \tan(\phi_{t'}) = \begin{cases} \dfrac{10\tan(\omega)}{1.5(T - q/4 + 1 - t)}, & \text{if } t < T,\\[10pt] \dfrac{10\tan(\omega)}{1.5}, & \text{if } t = T. \end{cases} </math>
</div>

The optimal straining angle for the final frame is not affected, since in this case the ellipse shrinks in both directions rather than just vertically, i.e. a factor <math>1-q/4</math> cancels in the numerator and denominator.

== History ==

<div style="font-size:120%; font-weight:bold; margin-top:1em;">2 July 2017</div>
Plush discovers that during a dive recover, one can gain greater distance along an angle different from Mario's facing angle by “flinging” the control stick through different angles during the trajectory, rather than holding it at a constant angle.

Pannenkoek qualitatively explains this phenomenon that would later be known as ''arctan straining'':

<blockquote style="font-style: italic;">
I think you're supposed to hold forward-ish for most of it, then sideways at the end. Because sideways movement doesn't depend on your speed. So 5 frames of sideways holding at the start of the DR is equivalent to the 5 frames at the end. But forward distance depends on your hspeed. So let's say you start with some hspeed. If you go sideways then forwards, then you'll lose that hspeed. But if you go forward then sideways, then you'll take advantage of your starting hspeed. The best inputs would probably mix sideways and forwards somewhat.
<br /> — <b>Pannenkoek2012</b>
</blockquote>

Peter Fedak shares the correct velocity update equations, and the three of them begin to consider what the mathematically optimal inputs are.

<div style="font-size:120%; font-weight:bold; margin-top:1em;">3 September 2017</div>
Iwer Sonsch independently rediscovers the velocity update equations and realises that by facing along the hypotenuse of the forward velocity and sideways speed — a trick known in other speedrunning communities as ''vectoring'' — he can gain greater distance in a single frame.
He wonders how this would look over multiple frames, restarting the discussion of optimal straining.
However, there is no quantitative progress until it becomes relevant to the A Button Challenge the following year.

<div style="font-size:120%; font-weight:bold; margin-top:1em;">18 March 2018</div>
The “Blast to the Stone Pillar” star in JRB is collected in 0 A presses for the first time, after Tyler Kehne figures out how to use conserved speed to get from the nearby pillar to the star platform.

The community turns their attention to whether the “Treasure of the Ocean Cave” star can be collected in a similar way, again reviving the optimal straining question, as people including Iwer, bad_boot, and DeRockProject begin attempting to make the most of the limited speed they have available.

<div style="font-size:120%; font-weight:bold; margin-top:1em;">16 April 2018</div>
Iwer states the optimal straining equation for the first time in the following form:

<math>\phi_{t'} - \theta = \operatorname{arccot}(0.15\,r\,t')</math>

This is equivalent to our expression above, since <math>\operatorname{arccot}(x) = \arctan(1/x)</math>,
with, <math>r = 1/\tan(\omega)</math>, and, <math>t' = T + 1 - t</math>.
(If using this expression, we need to add 180° if the target angle is to the right of Mario, since <math>\operatorname{arccot}</math> only gives results between 0° and 180°.)

<div style="font-size:120%; font-weight:bold; margin-top:1em;">23 June 2018</div>
Pannenkoek posts an idea for collecting the “Scale the Mountain” star in TTM via a dive recover.
To find out whether it was possible, Iwer, Grassdigger, Jane, bad_boot, and DeRockProject work to plot all of Mario’s possible positions while air straining.

<div style="font-size:120%; font-weight:bold; margin-top:1em;">20 August 2018</div>
Iwer discovers the exact equations describing Mario's possible positions after <math>T</math> frames. Grassdigger and DeRockProject then show that the total shape can be well approximated by a generalised superellipse.
Pannenkoek proposes calling it the ''Iwerlipse''.

<div style="font-size:120%; font-weight:bold; margin-top:1em;">3 October 2019</div>
Silverstrawb provides an alternative proof<ref>[https://drive.google.com/file/d/1df97glqVn-cXEUmP15vNxgQtwa8jJK2w/view?usp=sharing Showing Silverstrawb's proof.]</ref> of the optimal straining relation by converting the discrete update equations into the continuous differential equations

<math>\begin{align}
\dot{x} &= 10 \sin(\phi(t)),\\
\ddot{z} &= 1.5 \cos(\phi(t)) - D,
\end{align}</math>

and using the calculus of variations.

<div style="font-size:120%; font-weight:bold; margin-top:1em;">29 July 2020</div>
Krithalith independently rediscovers Iwer’s original proof and extends it to include quartersteps.

<div style="font-size:120%; font-weight:bold; margin-top:1em;">27 November 2021</div>
sm64expert adds arctan straining to MKDasher’s input direction LUA program, making it accessible to everyone for the first time.

<div style="font-size:120%; font-weight:bold; margin-top:1em;">16 March 2024</div>
sm64expert adds arctan straining to [https://github.com/mupen64/SM64LuaRedux SM64 Lua Redux].

==See Also==
[[Straining]]

==References==
{{#ev:youtube|_yx0eutBwII}}
<references />
[[Category:Mechanics]]

Iwerlipse

2025-10-16T17:30:23Z

Aurumaker72: Undo revision 19858 by Aurumaker72 (talk)

The '''Iwerlipse''' (pronounced ee-ver-lipse /ˈivɜlɪps/) is the range of positions Mario can occupy while he is in the air and cannot turn, assuming that drag is constant. The boundary of the Iwerlipse is reached by '''Arctan Straining''' - the optimal way of air straining that gives the greatest distance along a chosen angle <math>\omega</math> for a given number of frames <math>T</math>. For a single frame <math>T=1</math>, the Iwerlipse is an ellipse with half-width 10 (in the sideways direction) and half-height 1.5 (in the forwards direction). For general <math>T</math>, it resembles an ellipse with half-width <math>10T</math> and half-height <math>3T(T+1)/4</math>, but bulges at the corners, covering more area than an ellipse with the same dimensions. As shown by ''Grassdigger'', the shape is well approximated by a generalised superellipse, and thus ''Pannenkoek2012'' proposed calling this shape the Iwerlipse - a pun on the name of ''Iwer Sonsch'', who first discoverered that Arctan Straining was optimal in April 2018.

==Basics==

Arctan Straining gives the maximum possible distance along a target angle <math>\omega</math> that differs from the facing angle <math>\theta</math>, over a finite number of frames <math>T</math>. It is performed by choosing straining angles <math>\phi_t</math> (intendedYaw) such that

<div style="background:#f9f9f9; border-left:3px solid #bbb; padding:0.4em 0.8em; margin:1em 0;">
<math>
\begin{align}
\phi_t - \theta =
\begin{cases}
\arctan \left[\dfrac{10\tan(\omega - \theta)}{1.5(T+1-t)} \right] & \text{if } \cos(\omega-\theta) > 0, \\[14pt]
\arctan \left[\dfrac{10\tan(\omega - \theta)}{1.5(T+1-t)} \right] + 180^\circ & \text{if } \cos(\omega-\theta) < 0,
\end{cases}
\end{align}
</math>
</div>

with <math>t</math> being the frame number between <math>1</math> and <math>T</math>. (Usually only the top row of this equation is given, but since the <math>\arctan</math> function only gives results between <math>\pm 90^\circ</math>, we must add <math>180^\circ</math> to the result if the target angle is behind Mario.)

Arctan straining is a result of two asymmetries in how Mario's forward velocity and sideways speed are updated

* Forward velocity accelerates gradually over time, while sideways speed is reset every frame

* Straining on a single frame has a weak effect on forward velocity (increasing velocity by a maximum of 1.5), but a strong effect on sideways speed for a single frame (setting sideways speed to a maximum of 10).

In terms of total distance acquired along some direction, forward velocity is thus more effective over long periods of time, where it has time to accelerate to large values, whereas sideways speed is more effective over short periods of time. Optimal straining over many frames then involves straining mostly along the forwards direction to build up a large forward velocity, and then towards the end of the trajectory, transitioning into sideways straining to exploit the large sideways displacement obtainable in a single frame.

==Update Equations==

When Mario is in the air and cannot turn, the function <code>update_air_without_turn</code> is responsible for updating Mario's velocity variables from one frame, <math>t-1</math>, to the next, <math>t</math>. Without loss of generality, we can choose coordinates so that Mario's facing angle is zero. In other words, he is facing along the <math>z</math>-axis, while his sideways speed is directed along the <math>x</math>-axis. Mario's forward velocity, <math>v_t</math>, and position coordinates <math>z_t</math> and <math>x_t</math> are then updated via

<div style="background:#f9f9f9; border-left:3px solid #bbb; padding:0.4em 0.8em; margin:1em 0;">
<math>\begin{align}
v_t &= v_{t-1} - D(v_{t-1}, \phi_t) + 1.5\cos(\phi_t),\\
z_t &= z_{t-1} + v_t,\\ x_t &= x_{t-1} + 10\sin(\phi_t),
\end{align}</math>
</div>

where <math>\phi_t</math> is the straining angle (intendedYaw) on frame <math>t</math>. The total effect of drag is given by the coefficient <math>D</math>, determined by

<math>
D(v_{t-1}, \phi_t) =
\begin{cases}
-2.35 & \text{if } v_{t-1} < - 16.35 - 1.5 \cos(\phi_t),\\
-0.35 & \text{if } -16.35 - 1.5 \cos(\phi_t) \leq v_{t-1} \leq -0.35,\\
v_{t-1} & \text{if } -0.35 < v_{t-1} < 0.35,\\
0.35 & \text{if } 0.35 \leq v_{t-1} \leq D_\text{cap} + 0.35 - 1.5 \cos(\phi_t),\\
1.35 & \text{if } v_{t-1} > D_\text{cap} + 0.35 - 1.5 \cos(\phi_t).
\end{cases}
</math>

where <math>D_\text{cap}</math> is a soft velocity cap equal to 48 for long jumps and 32 otherwise.

In practice, these drag boundaries are far enough apart that the drag is often constant over large periods of time. In this case we can write Mario's position after <math>T</math> frames as

<math>\begin{align}
x_T &= x_0 + 10 \sum_{t=1}^{T} \sin(\phi_t),\\
z_T &= z_0 + v_0 T - D \sum_{t=1}^T t + 1.5 \sum_{t=1}^T \sum_{n=1}^t \cos(\phi_n).
\end{align}</math>

Using <math>\sum_{t=1}^T t = T(T+1)/2</math>, and by grouping terms of <math>\cos(\phi_t)</math>, the latter can be simplified to

<math> z_T = z_0 + v_0 T - \frac{DT(T+1)}{2} + 1.5 \sum_{t=1}^T (T+1-t)\cos(\phi_t). </math>

Notice that, since forward straining produces an acceleration that is not reset between frames, earlier frames have a stronger effect on the final <math>z</math> position than later frames. The effective strength is <math>1.5(T+1-t)</math>, i.e. 1.5 multiplied by the number of frames remaining (including the current frame), since the forward velocity gained on one frame produces a displacement also on all remaining frames.

==Arctan Straining Proof==

The displacement vector after <math>T</math> frames is

<math>\mathbf{R} = (x_T - x_0)\mathbf{\hat{x}} + (z_T - z_0)\mathbf{\hat{z}}</math>,

while the unit vector along the angle <math>\omega</math> is

<math>\mathbf{\hat{n}} = \sin(\omega)\mathbf{\hat{x}} + \cos(\omega)\mathbf{\hat{z}}</math>.

The distance we move along a target angle <math>\omega</math> over <math>T</math> frames is then

<math> S = \mathbf{R} \cdot \mathbf{\hat{n}} = \langle S\rangle + \sum_{t=1}^T S_t, </math>

where

<math> \langle S \rangle = \left(v_0 T - \frac{DT(T+1)}{2}\right)\cos(\omega), </math>

is due to our initial velocity and drag, while

<math> S_t = 10\sin(\phi_t)\sin(\omega) + 1.5(T+1-t)\cos(\phi_t)\cos(\omega), </math>

is the effective contribution from straining on frame <math>t</math>.
Thanks to this separation, we can maximize the total distance <math>S</math> by individually maximizing each contribution <math>S_t</math> as a function of <math>\phi_t</math>:

<math> \frac{d S_t}{d \phi_t} = 10\cos(\phi_t)\sin(\omega) - 1.5(T+1-t)\sin(\phi_t)\cos(\omega) = 0, </math>

and finally we find

<math> \tan(\phi_t) = \frac{10\tan(\omega)}{1.5(T+1-t)}, </math>

or, rotating the coordinate system back to allow for general facing angles <math>\theta</math>,

<math> \tan(\phi_t - \theta) = \frac{10\tan(\omega - \theta)}{1.5(T+1-t)}. </math>

Since <math>\tan(x) = \tan(x\pm180^\circ)</math>, this equation has two solutions for <math>\phi_t</math> which are given above.

== Iwerlipse Equations ==

By writing <math>\sin(\phi_t)</math> and <math>\cos(\phi_t)</math> in terms of <math>\tan(\phi_t)</math>, and using the optimal straining relation, we obtain exact expressions for the boundary of the Iwerlipse after <math>T</math> frames:

<div style="background:#f9f9f9; border-left:3px solid #bbb; padding:0.4em 0.8em; margin:1em 0;">
<math> \begin{aligned} x_T - x_0 &= \pm10 \sum_{t=1}^T \frac{1}{\sqrt{1+\beta^2 t^2}},\\ z_T - \langle z \rangle &= \pm1.5 \beta \sum_{t=1}^T \frac{t^2}{\sqrt{1+\beta^2 t^2}}, \end{aligned} </math>
</div>

where

<math>\beta = \frac{1.5}{10}\tan(\omega),</math>

and

<math>\langle z \rangle = z_0 + v_0 T - \frac{DT(T+1)}{2}</math>.

We can restrict <math>0 < \omega < 90^\circ</math>, with the four combinations of plus and minus signs giving the remaining quadrants.
The Iwerlipse's half-width is <math>x_\mathrm{max} = 10T</math>, while its half-height is <math>z_\mathrm{max} = 3T(T+1)/4</math>.

=== Approximations ===

If <math>T</math> is large, the exact expressions involve large summation terms, so it may be useful to have approximate expressions that are easier to compute.
By replacing the summations from <math>t=1</math> to <math>t=T</math> with an integral from <math>t=1/2</math> to <math>t=T+1/2</math> (essentially performing the midpoint rule of numerical integration in reverse), we obtain

<div style="background:#f9f9f9; border-left:3px solid #bbb; padding:0.4em 0.8em; margin:1em 0;">
<math> \begin{aligned} x_T - x_0 &= \pm \frac{10}{\beta} \left[\operatorname{arsinh}(\beta t)\right]^{T+1/2}_{1/2},\\ z_T - \langle z \rangle &= \pm \frac{3}{4\beta^2} \left[\beta t\sqrt{1+\beta^2 t^2} - \operatorname{arsinh}(\beta t)\right]^{T+1/2}_{1/2}, \end{aligned} </math>
</div>

with the notation <math>[F(t)]_{t_1}^{t_2} = F(t_2) - F(t_1)</math>.
This approximation converges to the true result very quickly:
even for <math>T=2</math>, the RMS error (normalized by <math>x_\mathrm{max}</math> and <math>z_\mathrm{max}</math>) is <math>4.3\times10^{-3}</math>,
while for <math>T>6</math> it is less than <math>10^{-3}</math>.
Similar expressions obtained using the Euler–Maclaurin formula converge more slowly, even with first-order correction terms.

A simpler but less accurate approximation is obtained by fitting the Iwerlipse to the generalized superellipse:

<div style="background:#f9f9f9; border-left:3px solid #bbb; padding:0.4em 0.8em; margin:1em 0;">
<math> \left(\frac{x_T - x_0}{x_\mathrm{max}}\right)^{m(T)} + \left(\frac{z_T - \langle z \rangle}{x_\mathrm{max}}\right)^{n(T)} = 1. </math>
</div>

The optimal exponents <math>m(T)</math> and <math>n(T)</math> have been found up to <math>T=150</math> (5 seconds), and can be obtained from a lookup table<ref>[https://drive.google.com/file/d/1xDmgHz878qiAS1ZF1Y5M0M1eiZUdZRSl/view?usp=sharing Showing Iwer's proof and deriving the Iwerlipse expressions.]</ref>.
Unlike the integral approximation, this expression never converges to the exact result — there is always some small error.

== Quarterstep Penalty ==

If <math>q \in {0,1,2,3}</math> quartersteps are lost on the final frame,
the forward velocity gained on frame <math>t</math> no longer accumulates forward distance over <math>T+1-t</math> frames,
but instead over <math>T - q/4 + 1 - t</math> frames.
The optimal straining relation becomes:

<div style="background:#f9f9f9; border-left:3px solid #bbb; padding:0.4em 0.8em; margin:1em 0;">
<math> \tan(\phi_{t'}) = \begin{cases} \dfrac{10\tan(\omega)}{1.5(T - q/4 + 1 - t)}, & \text{if } t < T,\\[10pt] \dfrac{10\tan(\omega)}{1.5}, & \text{if } t = T. \end{cases} </math>
</div>

The optimal straining angle for the final frame is not affected, since in this case the ellipse shrinks in both directions rather than just vertically, i.e. a factor <math>1-q/4</math> cancels in the numerator and denominator.

== History ==

<div style="font-size:120%; font-weight:bold; margin-top:1em;">2 July 2017</div>
Plush discovers that during a dive recover, one can gain greater distance along an angle different from Mario's facing angle by “flinging” the control stick through different angles during the trajectory, rather than holding it at a constant angle.

Pannenkoek qualitatively explains this phenomenon that would later be known as ''arctan straining'':

<blockquote style="font-style: italic;">
I think you're supposed to hold forward-ish for most of it, then sideways at the end. Because sideways movement doesn't depend on your speed. So 5 frames of sideways holding at the start of the DR is equivalent to the 5 frames at the end. But forward distance depends on your hspeed. So let's say you start with some hspeed. If you go sideways then forwards, then you'll lose that hspeed. But if you go forward then sideways, then you'll take advantage of your starting hspeed. The best inputs would probably mix sideways and forwards somewhat.
<br /> — <b>Pannenkoek2012</b>
</blockquote>

Peter Fedak shares the correct velocity update equations, and the three of them begin to consider what the mathematically optimal inputs are.

<div style="font-size:120%; font-weight:bold; margin-top:1em;">3 September 2017</div>
Iwer Sonsch independently rediscovers the velocity update equations and realises that by facing along the hypotenuse of the forward velocity and sideways speed — a trick known in other speedrunning communities as ''vectoring'' — he can gain greater distance in a single frame.
He wonders how this would look over multiple frames, restarting the discussion of optimal straining.
However, there is no quantitative progress until it becomes relevant to the A Button Challenge the following year.

<div style="font-size:120%; font-weight:bold; margin-top:1em;">18 March 2018</div>
The “Blast to the Stone Pillar” star in JRB is collected in 0 A presses for the first time, after Tyler Kehne figures out how to use conserved speed to get from the nearby pillar to the star platform.

The community turns their attention to whether the “Treasure of the Ocean Cave” star can be collected in a similar way, again reviving the optimal straining question, as people including Iwer, bad_boot, and DeRockProject begin attempting to make the most of the limited speed they have available.

<div style="font-size:120%; font-weight:bold; margin-top:1em;">16 April 2018</div>
Iwer states the optimal straining equation for the first time in the following form:

<math>\phi_{t'} - \theta = \operatorname{arccot}(0.15\,r\,t')</math>

This is equivalent to our expression above, since <math>\operatorname{arccot}(x) = \arctan(1/x)</math>,
with, <math>r = 1/\tan(\omega)</math>, and, <math>t' = T + 1 - t</math>.
(If using this expression, we need to add 180° if the target angle is to the right of Mario, since <math>\operatorname{arccot}</math> only gives results between 0° and 180°.)

<div style="font-size:120%; font-weight:bold; margin-top:1em;">23 June 2018</div>
Pannenkoek posts an idea for collecting the “Scale the Mountain” star in TTM via a dive recover.
To find out whether it was possible, Iwer, Grassdigger, Jane, bad_boot, and DeRockProject work to plot all of Mario’s possible positions while air straining.

<div style="font-size:120%; font-weight:bold; margin-top:1em;">20 August 2018</div>
Iwer discovers the exact equations describing Mario's possible positions after <math>T</math> frames. Grassdigger and DeRockProject then show that the total shape can be well approximated by a generalised superellipse.
Pannenkoek proposes calling it the ''Iwerlipse''.

<div style="font-size:120%; font-weight:bold; margin-top:1em;">3 October 2019</div>
Silverstrawb provides an alternative proof<ref>[https://drive.google.com/file/d/1df97glqVn-cXEUmP15vNxgQtwa8jJK2w/view?usp=sharing Showing Silverstrawb's proof.]</ref> of the optimal straining relation by converting the discrete update equations into the continuous differential equations

<math>\begin{align}
\dot{x} &= 10 \sin(\phi(t)),\\
\ddot{z} &= 1.5 \cos(\phi(t)) - D,
\end{align}</math>

and using the calculus of variations.

<div style="font-size:120%; font-weight:bold; margin-top:1em;">29 July 2020</div>
Krithalith independently rediscovers Iwer’s original proof and extends it to include quartersteps.

<div style="font-size:120%; font-weight:bold; margin-top:1em;">27 November 2021</div>
sm64expert adds arctan straining to MKDasher’s input direction LUA program, making it accessible to everyone for the first time.

==See Also==
[[Straining]]

==References==
{{#ev:youtube|_yx0eutBwII}}
<references />
[[Category:Mechanics]]

Iwerlipse

2025-10-16T17:20:43Z

Aurumaker72: correct information about the lua script integration

The '''Iwerlipse''' (pronounced ee-ver-lipse /ˈivɜlɪps/) is the range of positions Mario can occupy while he is in the air and cannot turn, assuming that drag is constant. The boundary of the Iwerlipse is reached by '''Arctan Straining''' - the optimal way of air straining that gives the greatest distance along a chosen angle <math>\omega</math> for a given number of frames <math>T</math>. For a single frame <math>T=1</math>, the Iwerlipse is an ellipse with half-width 10 (in the sideways direction) and half-height 1.5 (in the forwards direction). For general <math>T</math>, it resembles an ellipse with half-width <math>10T</math> and half-height <math>3T(T+1)/4</math>, but bulges at the corners, covering more area than an ellipse with the same dimensions. As shown by ''Grassdigger'', the shape is well approximated by a generalised superellipse, and thus ''Pannenkoek2012'' proposed calling this shape the Iwerlipse - a pun on the name of ''Iwer Sonsch'', who first discoverered that Arctan Straining was optimal in April 2018.

==Basics==

Arctan Straining gives the maximum possible distance along a target angle <math>\omega</math> that differs from the facing angle <math>\theta</math>, over a finite number of frames <math>T</math>. It is performed by choosing straining angles <math>\phi_t</math> (intendedYaw) such that

<div style="background:#f9f9f9; border-left:3px solid #bbb; padding:0.4em 0.8em; margin:1em 0;">
<math>
\begin{align}
\phi_t - \theta =
\begin{cases}
\arctan \left[\dfrac{10\tan(\omega - \theta)}{1.5(T+1-t)} \right] & \text{if } \cos(\omega-\theta) > 0, \\[14pt]
\arctan \left[\dfrac{10\tan(\omega - \theta)}{1.5(T+1-t)} \right] + 180^\circ & \text{if } \cos(\omega-\theta) < 0,
\end{cases}
\end{align}
</math>
</div>

with <math>t</math> being the frame number between <math>1</math> and <math>T</math>. (Usually only the top row of this equation is given, but since the <math>\arctan</math> function only gives results between <math>\pm 90^\circ</math>, we must add <math>180^\circ</math> to the result if the target angle is behind Mario.)

Arctan straining is a result of two asymmetries in how Mario's forward velocity and sideways speed are updated

* Forward velocity accelerates gradually over time, while sideways speed is reset every frame

* Straining on a single frame has a weak effect on forward velocity (increasing velocity by a maximum of 1.5), but a strong effect on sideways speed for a single frame (setting sideways speed to a maximum of 10).

In terms of total distance acquired along some direction, forward velocity is thus more effective over long periods of time, where it has time to accelerate to large values, whereas sideways speed is more effective over short periods of time. Optimal straining over many frames then involves straining mostly along the forwards direction to build up a large forward velocity, and then towards the end of the trajectory, transitioning into sideways straining to exploit the large sideways displacement obtainable in a single frame.

==Update Equations==

When Mario is in the air and cannot turn, the function <code>update_air_without_turn</code> is responsible for updating Mario's velocity variables from one frame, <math>t-1</math>, to the next, <math>t</math>. Without loss of generality, we can choose coordinates so that Mario's facing angle is zero. In other words, he is facing along the <math>z</math>-axis, while his sideways speed is directed along the <math>x</math>-axis. Mario's forward velocity, <math>v_t</math>, and position coordinates <math>z_t</math> and <math>x_t</math> are then updated via

<div style="background:#f9f9f9; border-left:3px solid #bbb; padding:0.4em 0.8em; margin:1em 0;">
<math>\begin{align}
v_t &= v_{t-1} - D(v_{t-1}, \phi_t) + 1.5\cos(\phi_t),\\
z_t &= z_{t-1} + v_t,\\ x_t &= x_{t-1} + 10\sin(\phi_t),
\end{align}</math>
</div>

where <math>\phi_t</math> is the straining angle (intendedYaw) on frame <math>t</math>. The total effect of drag is given by the coefficient <math>D</math>, determined by

<math>
D(v_{t-1}, \phi_t) =
\begin{cases}
-2.35 & \text{if } v_{t-1} < - 16.35 - 1.5 \cos(\phi_t),\\
-0.35 & \text{if } -16.35 - 1.5 \cos(\phi_t) \leq v_{t-1} \leq -0.35,\\
v_{t-1} & \text{if } -0.35 < v_{t-1} < 0.35,\\
0.35 & \text{if } 0.35 \leq v_{t-1} \leq D_\text{cap} + 0.35 - 1.5 \cos(\phi_t),\\
1.35 & \text{if } v_{t-1} > D_\text{cap} + 0.35 - 1.5 \cos(\phi_t).
\end{cases}
</math>

where <math>D_\text{cap}</math> is a soft velocity cap equal to 48 for long jumps and 32 otherwise.

In practice, these drag boundaries are far enough apart that the drag is often constant over large periods of time. In this case we can write Mario's position after <math>T</math> frames as

<math>\begin{align}
x_T &= x_0 + 10 \sum_{t=1}^{T} \sin(\phi_t),\\
z_T &= z_0 + v_0 T - D \sum_{t=1}^T t + 1.5 \sum_{t=1}^T \sum_{n=1}^t \cos(\phi_n).
\end{align}</math>

Using <math>\sum_{t=1}^T t = T(T+1)/2</math>, and by grouping terms of <math>\cos(\phi_t)</math>, the latter can be simplified to

<math> z_T = z_0 + v_0 T - \frac{DT(T+1)}{2} + 1.5 \sum_{t=1}^T (T+1-t)\cos(\phi_t). </math>

Notice that, since forward straining produces an acceleration that is not reset between frames, earlier frames have a stronger effect on the final <math>z</math> position than later frames. The effective strength is <math>1.5(T+1-t)</math>, i.e. 1.5 multiplied by the number of frames remaining (including the current frame), since the forward velocity gained on one frame produces a displacement also on all remaining frames.

==Arctan Straining Proof==

The displacement vector after <math>T</math> frames is

<math>\mathbf{R} = (x_T - x_0)\mathbf{\hat{x}} + (z_T - z_0)\mathbf{\hat{z}}</math>,

while the unit vector along the angle <math>\omega</math> is

<math>\mathbf{\hat{n}} = \sin(\omega)\mathbf{\hat{x}} + \cos(\omega)\mathbf{\hat{z}}</math>.

The distance we move along a target angle <math>\omega</math> over <math>T</math> frames is then

<math> S = \mathbf{R} \cdot \mathbf{\hat{n}} = \langle S\rangle + \sum_{t=1}^T S_t, </math>

where

<math> \langle S \rangle = \left(v_0 T - \frac{DT(T+1)}{2}\right)\cos(\omega), </math>

is due to our initial velocity and drag, while

<math> S_t = 10\sin(\phi_t)\sin(\omega) + 1.5(T+1-t)\cos(\phi_t)\cos(\omega), </math>

is the effective contribution from straining on frame <math>t</math>.
Thanks to this separation, we can maximize the total distance <math>S</math> by individually maximizing each contribution <math>S_t</math> as a function of <math>\phi_t</math>:

<math> \frac{d S_t}{d \phi_t} = 10\cos(\phi_t)\sin(\omega) - 1.5(T+1-t)\sin(\phi_t)\cos(\omega) = 0, </math>

and finally we find

<math> \tan(\phi_t) = \frac{10\tan(\omega)}{1.5(T+1-t)}, </math>

or, rotating the coordinate system back to allow for general facing angles <math>\theta</math>,

<math> \tan(\phi_t - \theta) = \frac{10\tan(\omega - \theta)}{1.5(T+1-t)}. </math>

Since <math>\tan(x) = \tan(x\pm180^\circ)</math>, this equation has two solutions for <math>\phi_t</math> which are given above.

== Iwerlipse Equations ==

By writing <math>\sin(\phi_t)</math> and <math>\cos(\phi_t)</math> in terms of <math>\tan(\phi_t)</math>, and using the optimal straining relation, we obtain exact expressions for the boundary of the Iwerlipse after <math>T</math> frames:

<div style="background:#f9f9f9; border-left:3px solid #bbb; padding:0.4em 0.8em; margin:1em 0;">
<math> \begin{aligned} x_T - x_0 &= \pm10 \sum_{t=1}^T \frac{1}{\sqrt{1+\beta^2 t^2}},\\ z_T - \langle z \rangle &= \pm1.5 \beta \sum_{t=1}^T \frac{t^2}{\sqrt{1+\beta^2 t^2}}, \end{aligned} </math>
</div>

where

<math>\beta = \frac{1.5}{10}\tan(\omega),</math>

and

<math>\langle z \rangle = z_0 + v_0 T - \frac{DT(T+1)}{2}</math>.

We can restrict <math>0 < \omega < 90^\circ</math>, with the four combinations of plus and minus signs giving the remaining quadrants.
The Iwerlipse's half-width is <math>x_\mathrm{max} = 10T</math>, while its half-height is <math>z_\mathrm{max} = 3T(T+1)/4</math>.

=== Approximations ===

If <math>T</math> is large, the exact expressions involve large summation terms, so it may be useful to have approximate expressions that are easier to compute.
By replacing the summations from <math>t=1</math> to <math>t=T</math> with an integral from <math>t=1/2</math> to <math>t=T+1/2</math> (essentially performing the midpoint rule of numerical integration in reverse), we obtain

<div style="background:#f9f9f9; border-left:3px solid #bbb; padding:0.4em 0.8em; margin:1em 0;">
<math> \begin{aligned} x_T - x_0 &= \pm \frac{10}{\beta} \left[\operatorname{arsinh}(\beta t)\right]^{T+1/2}_{1/2},\\ z_T - \langle z \rangle &= \pm \frac{3}{4\beta^2} \left[\beta t\sqrt{1+\beta^2 t^2} - \operatorname{arsinh}(\beta t)\right]^{T+1/2}_{1/2}, \end{aligned} </math>
</div>

with the notation <math>[F(t)]_{t_1}^{t_2} = F(t_2) - F(t_1)</math>.
This approximation converges to the true result very quickly:
even for <math>T=2</math>, the RMS error (normalized by <math>x_\mathrm{max}</math> and <math>z_\mathrm{max}</math>) is <math>4.3\times10^{-3}</math>,
while for <math>T>6</math> it is less than <math>10^{-3}</math>.
Similar expressions obtained using the Euler–Maclaurin formula converge more slowly, even with first-order correction terms.

A simpler but less accurate approximation is obtained by fitting the Iwerlipse to the generalized superellipse:

<div style="background:#f9f9f9; border-left:3px solid #bbb; padding:0.4em 0.8em; margin:1em 0;">
<math> \left(\frac{x_T - x_0}{x_\mathrm{max}}\right)^{m(T)} + \left(\frac{z_T - \langle z \rangle}{x_\mathrm{max}}\right)^{n(T)} = 1. </math>
</div>

The optimal exponents <math>m(T)</math> and <math>n(T)</math> have been found up to <math>T=150</math> (5 seconds), and can be obtained from a lookup table<ref>[https://drive.google.com/file/d/1xDmgHz878qiAS1ZF1Y5M0M1eiZUdZRSl/view?usp=sharing Showing Iwer's proof and deriving the Iwerlipse expressions.]</ref>.
Unlike the integral approximation, this expression never converges to the exact result — there is always some small error.

== Quarterstep Penalty ==

If <math>q \in {0,1,2,3}</math> quartersteps are lost on the final frame,
the forward velocity gained on frame <math>t</math> no longer accumulates forward distance over <math>T+1-t</math> frames,
but instead over <math>T - q/4 + 1 - t</math> frames.
The optimal straining relation becomes:

<div style="background:#f9f9f9; border-left:3px solid #bbb; padding:0.4em 0.8em; margin:1em 0;">
<math> \tan(\phi_{t'}) = \begin{cases} \dfrac{10\tan(\omega)}{1.5(T - q/4 + 1 - t)}, & \text{if } t < T,\\[10pt] \dfrac{10\tan(\omega)}{1.5}, & \text{if } t = T. \end{cases} </math>
</div>

The optimal straining angle for the final frame is not affected, since in this case the ellipse shrinks in both directions rather than just vertically, i.e. a factor <math>1-q/4</math> cancels in the numerator and denominator.

== History ==

<div style="font-size:120%; font-weight:bold; margin-top:1em;">2 July 2017</div>
Plush discovers that during a dive recover, one can gain greater distance along an angle different from Mario's facing angle by “flinging” the control stick through different angles during the trajectory, rather than holding it at a constant angle.

Pannenkoek qualitatively explains this phenomenon that would later be known as ''arctan straining'':

<blockquote style="font-style: italic;">
I think you're supposed to hold forward-ish for most of it, then sideways at the end. Because sideways movement doesn't depend on your speed. So 5 frames of sideways holding at the start of the DR is equivalent to the 5 frames at the end. But forward distance depends on your hspeed. So let's say you start with some hspeed. If you go sideways then forwards, then you'll lose that hspeed. But if you go forward then sideways, then you'll take advantage of your starting hspeed. The best inputs would probably mix sideways and forwards somewhat.
<br /> — <b>Pannenkoek2012</b>
</blockquote>

Peter Fedak shares the correct velocity update equations, and the three of them begin to consider what the mathematically optimal inputs are.

<div style="font-size:120%; font-weight:bold; margin-top:1em;">3 September 2017</div>
Iwer Sonsch independently rediscovers the velocity update equations and realises that by facing along the hypotenuse of the forward velocity and sideways speed — a trick known in other speedrunning communities as ''vectoring'' — he can gain greater distance in a single frame.
He wonders how this would look over multiple frames, restarting the discussion of optimal straining.
However, there is no quantitative progress until it becomes relevant to the A Button Challenge the following year.

<div style="font-size:120%; font-weight:bold; margin-top:1em;">18 March 2018</div>
The “Blast to the Stone Pillar” star in JRB is collected in 0 A presses for the first time, after Tyler Kehne figures out how to use conserved speed to get from the nearby pillar to the star platform.

The community turns their attention to whether the “Treasure of the Ocean Cave” star can be collected in a similar way, again reviving the optimal straining question, as people including Iwer, bad_boot, and DeRockProject begin attempting to make the most of the limited speed they have available.

<div style="font-size:120%; font-weight:bold; margin-top:1em;">16 April 2018</div>
Iwer states the optimal straining equation for the first time in the following form:

<math>\phi_{t'} - \theta = \operatorname{arccot}(0.15\,r\,t')</math>

This is equivalent to our expression above, since <math>\operatorname{arccot}(x) = \arctan(1/x)</math>,
with, <math>r = 1/\tan(\omega)</math>, and, <math>t' = T + 1 - t</math>.
(If using this expression, we need to add 180° if the target angle is to the right of Mario, since <math>\operatorname{arccot}</math> only gives results between 0° and 180°.)

<div style="font-size:120%; font-weight:bold; margin-top:1em;">23 June 2018</div>
Pannenkoek posts an idea for collecting the “Scale the Mountain” star in TTM via a dive recover.
To find out whether it was possible, Iwer, Grassdigger, Jane, bad_boot, and DeRockProject work to plot all of Mario’s possible positions while air straining.

<div style="font-size:120%; font-weight:bold; margin-top:1em;">20 August 2018</div>
Iwer discovers the exact equations describing Mario's possible positions after <math>T</math> frames. Grassdigger and DeRockProject then show that the total shape can be well approximated by a generalised superellipse.
Pannenkoek proposes calling it the ''Iwerlipse''.

<div style="font-size:120%; font-weight:bold; margin-top:1em;">3 October 2019</div>
Silverstrawb provides an alternative proof<ref>[https://drive.google.com/file/d/1df97glqVn-cXEUmP15vNxgQtwa8jJK2w/view?usp=sharing Showing Silverstrawb's proof.]</ref> of the optimal straining relation by converting the discrete update equations into the continuous differential equations

<math>\begin{align}
\dot{x} &= 10 \sin(\phi(t)),\\
\ddot{z} &= 1.5 \cos(\phi(t)) - D,
\end{align}</math>

and using the calculus of variations.

<div style="font-size:120%; font-weight:bold; margin-top:1em;">29 July 2020</div>
Krithalith independently rediscovers Iwer’s original proof and extends it to include quartersteps.

<div style="font-size:120%; font-weight:bold; margin-top:1em;">27 November 2021</div>
sm64expert adds arctan straining to [https://github.com/mupen64/SM64LuaRedux SM64 Lua Redux], making it accessible to everyone for the first time.

==See Also==
[[Straining]]

==References==
{{#ev:youtube|_yx0eutBwII}}
<references />
[[Category:Mechanics]]

Mupen64

2024-05-15T06:36:32Z

Aurumaker72: Add info about lagless support due to clock speed control

{{stub}}
'''Mupen64''' is a [[Nintendo 64]] [[Emulators|emulator]] useful for its TASing capabilities.

There are many forks of Mupen64, the primary community-maintained one being [https://github.com/mkdasher/mupen64-rr-lua- mupen64-rr-lua], which is nearly universally used for TASing Super Mario 64
=Mupen64plus=
'''Mupen64plus''' (stylized as '''mupen64plus''') is an emulator used for real-time gameplay.

It is generally preferred in this regard over Mupen64. Mupen64plus, as well as m64p-based frontends such as OpenEMU, are also allowed for Super Mario 64 [[RTA|speedrunning]].
=mupen64-rr-lua=
'''[https://github.com/mkdasher/mupen64-rr-lua- mupen64-rr-lua]''' is an emulator used for TASing and is most commonly used to record and play back TAS movies.

It is a fork of Mupen64-RR-lua which is actively maintained by the community. It introduces the lua scripting extension, QoL features, and security patches

=== Recording movies ===
# Navigate to the `Movie` menu and select `Start Movie Recording`...
# Click "Save As" to pick the movie save location
# Select a start type.
#* Start: The movie will start from a console reset
#* Savestate: The movie will start from a savestate created upon confirming the dialog
#* Existing Savestate: The movie will start from the savestate picked by the user upon confirming the dialog
#* EEPROM: The movie will start from a console reset, but with unreset EEPROM
# (optional) Type your name and a description into the respective fields
# Confirm the dialog

=== Continuing Movies ===

# Make sure a movie is playing back
# Disable read-only mode
# Create a savestate
# Load the savestate
# The recording has begun from the frame the savestate was created at

==Features==
===Lua===
mupen64-rr-lua supports Lua scripting, which gives it much more power for testing and brute forcing<ref>http://adelikat.tasvideos.org/emulatordownloads/mupen64-rr/LuaExtension_r34_bin.zip</ref>. It is used for TASing, as well as for testing and preparing.
===Emulate Float Crashes===
mupen64-rr-lua supports crashing during certain float-to-short exceptions just like the [[Nintendo 64]] console does. This is a useful alternative to [[TASBot#Console Verification|console verification]], but not as reliable, because there are still some [[Crash#Unknown cause|unknown crashes]].

=== Clock Speed Control ===
mupen64-rr-lua supports changing the emulated CPU's clock speed with a multiplier, allowing lagless emulation.

===WiiVC Rounding===
mupen64-rr-lua supports emulating the [[Wii VC Round-To-Zero]] oversight<ref>https://www.mediafire.com/file/p2qpz0u39fhub8k/mupen64-wiivc.exe/file</ref>. It has been used, among other things, by pannenkoek2012 to TAS the [[Bowser in the Fire Sea#A Press Counts|Bowser in the Fire Sea 0x A presses]] run<ref>https://www.youtube.com/watch?v=Aa_CciaM4aM</ref>.

=References=
<references />

FAQ

2024-04-10T13:59:51Z

Aurumaker72: Put mupen-related questions in new category, improve wording, add new info

'''FAQ (Frequently Asked Questions)'''
==How do I TAS?==
[https://www.youtube.com/watch?v=GVQW_GuOKQg Basic Mupen64 TAS Tutorial]
==What is STROOP?==
{{main|STROOP}}
STROOP ('''S'''uperMario64 '''T'''echnical '''R'''untime '''O'''bserver and '''O'''bject '''P'''rocessor) is a diagnostic tool for Super Mario 64 which displays and allows for simple editing of various game values and information. It can connect to a running emulator and update values in real time. Some core features include views of loaded/unloaded objects, Mario structure variables, camera + HUD values, an overhead map display, and many more.
==What is Mupen?==
{{main|Mupen64}}
Mupen64 (Mupen for short) is an N64 emulator. A variant of Mupen64, Mupen64-rr, is most commonly used for TASing Super Mario 64. This is what most people in the TAS community mean when they say "Mupen". There is also an emulator known as Mupen64Plus, which does not have TASing capabilities, but is commonly used for [[RTA]].
==Why Mupen over BizHawk?==
Most TASes of Super Mario 64 are done on [[Mupen64-rr]]. This is for one main reason: .m64 files can be played back on console, known as [[TASBot#Console Verification|Console Verification]], whereas bk2 files cannot, due to the way they handle input during lag frames. BizHawk polls inputs on lag frames, as opposed to Mupen64, which does not, and SM64 doesn't either. BK2 files (BizHawk movie files) can still be converted to m64 files, however, so some still use Bizhawk.
==Where can I get an SM64 ROM?==
A quick google search can help you with that. Unfortunately we cannot provide links here because of copyright.
==What different challenges are there?==
As of now, there are 13 challenges that have gained decent popularity, along with many minor ones. Some of the more well-known include:
*The [[UBER Challenge]]
*The [[Pacifist Challenge]]
*The [[A Button Challenge]]
*The [[B Button Challenge]]
*The [[Z Button Challenge]]
*The [[Coinless Challenge]]
*The [[Capless/Cannonless Challenge]]
*The [[CCC Challenge]]
*The [[ABZ Button Challenge]]
*The [[Low Doors Challenge]]
*The [[No Joystick Allowed Challenge]]
*The [[Floor is Lava Challenge]]
*The [[Same Input Challenge]]
See the [[Challenge]] and [[Other Single Button Challenges]] pages for further info on these and others.
==How many A presses are left?==
An any% run takes 0 A presses when performed on Wii VC. A 120 star run currently takes 13 A presses when performed on the original Japanese N64 version. Here's a table showing these counts on all game versions:
{| class="wikitable" style="text-align: center; width: 200px; height: 200px;"
|-
!
! [[Super Mario 64#Japanese|N64 JP (Original)]]
! [[Super Mario 64#English|N64 US]]
! [[Super Mario 64#PAL|N64 PAL]]
! [[Super Mario 64#Shindou|N64 JP (Shindou)]]
! [[Super Mario 64#iQue_.28Chinese.29|iQue]]
! [[Super Mario 64#Japanese_2|Wii VC JP]]
! [[Super Mario 64#English_2|Wii VC US]]
! [[Super Mario 64#PAL_2|Wii VC PAL]]
! [[Super Mario 64#Japanese_3|Wii U VC JP]]
! [[Super Mario 64#English_3|Wii U VC US]]
! [[Super Mario 64#PAL_3|Wii U VC PAL]]
! [[Super_Mario_64#64DD_Version|64DD Version]]
|-
! Any%
| 1 || 1 || 1 || 1 || 1 || 0 || 0 || 0 || 1 || 1 || 1 || 1
|-
! 120 Star
| 13 || 16 || 16 || 17 || 17 || 16 || 15 || 15 || 17 || 16 || 16 || Impossible
|}
==Is a 70 Star 0 A press run being developed?==
Yes; though it is not yet confirmed to be possible, the run is being TASed until [[BitFS]]. This is because we have a good blueprint for how to do BitFS on the N64. There is currently no plan to make a 70 star no A press run on [[Wii VC]] because [[console Verification|verifying these runs]] is difficult.
==What's the next A press save going to be?==
Currently, the next A press in line to be saved is Bowser in the Fire Sea on the N64, which would bring the A press count from 13 to 12, using [[Bully Battery]] and a [[Squish Cancel]] combined together.
==How are you decompiling the game?==
After we discovered the compiler that Nintendo used for Super Mario 64, we obtained the raw assembly from the ROM, and reverse engineered C code that compiles into it. This was a long and tedious process, but after a couple years, the game has been fully decompiled.
==Why does Mario lose his hat when he dies from going out-of-bounds (OoB)?==
Mario's default state is, surprisingly, with no hat on, and on each frame it checks whether he's wearing the hat and sets the proper graphics flag. However, when Mario goes OoB, a large portion of the central Mario code stops running, including that check. Hence, Mario doesn't actually lose his hat; he just forgets he's wearing it.
==I just got through the 8 Star Door to Bowser 1 by grabbing onto it with a ledge grab! Is this useful?==
No. Clipping through the door with a ledge grab is a side effect of the patch in the SM64 Editor program that "improves collision". It is not actually possible in the original game.
==Mario's animation doesn't update when you dive recover against a wall. Is this useful?==
No. It is a purely visual glitch and has no effect on gameplay.
==I was doing a BLJ on the endless stairs and warped straight to Wet-Dry World. Is this new?==
No. You clipped through the wall and went above the painting. The game checks whether or not you entered paintings by checking whether or not you are above floor triangles behind them, even when you are really high up.

== Mupen ==

=== How do you continue off of a TAS you created earlier? ===

# Play it to where you want to continue, then save a state.
# Disable read-only mode and reload the state.
# The file will now start recording inputs from that point, erasing any you had previously made after that point.

=== Mupen is open, but the Mupen window disappeared and won’t come back, even when I restart. What do I do? ===
This is a glitch that occurs on old versions of Mupen when it is closed while minimized.

To fix it, you must maximize the Mupen window and then drag down the top of the window, which will restore it to a normal window. To maximize the window without it actually being present, you can do one of the following:
* [Windows 7 Only] Open task manager, right click on the Mupen program, click maximize
* Right click on the Mupen icon in the task bar with shift held, click maximize
* Hover over the Mupen icon in the task bar, right click on the preview, click maximize
Deleting Mupen’s config file also works.

=== Recording an AVI on mupen produces a blackscreen with sound. What do I do? ===
This is a bug that occurs when you use the gl64 video plugin when aero is enabled on your computer. One fix is to use another video plugin, or to disable aero on your computer. The latter is only possible on Windows 7, but unfortunately not on later versions.

The same bug can manifest when capturing with the "Video" synchronization mode on new versions of Mupen.

=== Mupen's TAS Input Plugin window doesn't stay focused when clicking on the main emulator window. What do I do? ===
This is a bug that was introduced in Windows 10 Version 1809, but has been patched in the latest versions of TASInput.

Some solutions have been provided using macros, but the easiest solution is to simply click on the joystick area and hold the click outside of the tas input window. When you release the click it should still follow the mouse. Then click on Mupen, and from now until you close the rom, it will behave normally.

[[Category:Help]]

Mupen64

2024-03-10T18:41:58Z

Aurumaker72: Add clock speed control feature info

{{stub}}
'''Mupen64''' is a [[Nintendo 64]] [[Emulators|emulator]] useful for its TASing capabilities.

There are many forks of Mupen64, the primary community-maintained one being [https://github.com/mkdasher/mupen64-rr-lua- mupen64-rr-lua], which is nearly universally used for TASing Super Mario 64
=Mupen64plus=
'''Mupen64plus''' (stylized as '''mupen64plus''') is an emulator used for real-time gameplay.

It is generally preferred in this regard over Mupen64. Mupen64plus, as well as m64p-based frontends such as OpenEMU, are also allowed for Super Mario 64 [[RTA|speedrunning]].
=mupen64-rr-lua=
'''[https://github.com/mkdasher/mupen64-rr-lua- mupen64-rr-lua]''' is an emulator used for TASing and is most commonly used to record and play back TAS movies.

It is a fork of Mupen64-RR-lua which is actively maintained by the community. It introduces the lua scripting extension, QoL features, and security patches

=== Recording movies ===
# Navigate to the `Movie` menu and select `Start Movie Recording`...
# Click "Save As" to pick the movie save location
# Select a start type.
#* Start: The movie will start from a console reset
#* Savestate: The movie will start from a savestate created upon confirming the dialog
#* Existing Savestate: The movie will start from the savestate picked by the user upon confirming the dialog
#* EEPROM: The movie will start from a console reset, but with unreset EEPROM
# (optional) Type your name and a description into the respective fields
# Confirm the dialog

=== Continuing Movies ===

# Make sure a movie is playing back
# Disable read-only mode
# Create a savestate
# Load the savestate
# The recording has begun from the frame the savestate was created at

==Features==
===Lua===
mupen64-rr-lua supports Lua scripting, which gives it much more power for testing and brute forcing<ref>http://adelikat.tasvideos.org/emulatordownloads/mupen64-rr/LuaExtension_r34_bin.zip</ref>. It is used for TASing, as well as for testing and preparing.
===Emulate Float Crashes===
mupen64-rr-lua supports crashing during certain float-to-short exceptions just like the [[Nintendo 64]] console does. This is a useful alternative to [[TASBot#Console Verification|console verification]], but not as reliable, because there are still some [[Crash#Unknown cause|unknown crashes]].

=== Clock Speed Control ===
mupen64-rr-lua supports changing the emulated CPU's clock speed with a multiplier.

===WiiVC Rounding===
mupen64-rr-lua supports emulating the [[Wii VC Round-To-Zero]] oversight<ref>https://www.mediafire.com/file/p2qpz0u39fhub8k/mupen64-wiivc.exe/file</ref>. It has been used, among other things, by pannenkoek2012 to TAS the [[Bowser in the Fire Sea#A Press Counts|Bowser in the Fire Sea 0x A presses]] run<ref>https://www.youtube.com/watch?v=Aa_CciaM4aM</ref>.

=References=
<references />

Abbreviations

2024-02-17T20:16:06Z

Aurumaker72: /* Software Terminology */

The following tables summarize abbreviations commonly used in the context of Super Mario 64.
==Courses/Stages/Star Names==
=== Course Names ===
{| class="wikitable sortable"
!Abbreviation
!Meaning
|-
|BBH
|[[Big Boo's Haunt]]
|-
|BoB
|[[Bob-omb Battlefield]]
|-
|CCM
|[[Cool, Cool Mountain]]
|-
|DDD
|[[Dire, Dire Docks]]
|-
|HMC
|[[Hazy Maze Cave]]
|-
|JRB
|[[Jolly Roger Bay]]
|-
|LLL
|[[Lethal Lava Land]]
|-
|RR
|[[Rainbow Ride]]
Rerecord
|-
|SL
|[[Snowman's Land]]
|-
|SSL
|[[Shifting Sand Land]]
|-
|THI
|[[Tiny-Huge Island]]
|-
|TTC
|[[Tick Tock Clock]]
|-
|TTM
|[[Tall, Tall Mountain]]
|-
|WDW
|[[Wet-Dry World]]
|-
|WF
|[[Whomp's Fortress]]
|}
=== Cap Stages ===
{| class="wikitable sortable"
!Abbreviation
!Meaning
|-
|CotMC
|[[Cavern of the Metal Cap]]
|-
|TotWC
|[[Tower of the Wing Cap]]
|-
|VCutM
|[[Vanish Cap under the Moat]]
|}
=== Bowser Stages ===
{| class="wikitable sortable"
!Abbreviation
!Meaning
|-
|BitDW
|[[Bowser in the Dark World]]
|-
|BitFS
|[[Bowser in the Fire Sea]]
|-
|BitS
|[[Bowser in the Sky]]
|}
=== Castle Secret Stages ===
{| class="wikitable sortable"
!Abbreviation
!Meaning
|-
|PSS
|[[The Princess's Secret Slide]]
|-
|SA
|[[Secret Aquarium]]
|-
|WMotR
|[[Wing Mario over the Rainbow]]
|}
=== Star Names ===
{| class="wikitable sortable"
!Abbreviation
!Meaning
|-
|CAiaM
| [[Coins Amassed in a Maze]]
|-
|ItAP
|[[Inside the Ancient Pyramid]]
|-
|MHMCM
|[[Metal-Head Mario Can Move!]]
|-
|MWttS
|[[Mario Wings to the Sky]]
|-
|RitC
|[[Roll into the Cage]]
|-
|SotT
|[[Stomp on the Thwomp]]
|-
|TJoMB
|[[Timed Jumps on Moving Bars]]
|-
|TotOC
|[[Treasure of the Ocean Cave]]
|-
|TotT
|[[Top O' the Town]]
|-
|TPatP
P&P
|[[The Pit and the Pendulums]]
|-
|WfRR
|[[Watch for Rolling Rocks]]
|-
|WKWW
|[[Wall Kicks Will Work]]
|-
|WRC
|[[Wiggler's Red Coins]]
|}
== Game Mechanics & Terminology ==
{| class="wikitable sortable"
!Abbreviation
!Meaning
|-
|100c
|[[100 Coins]]
|-
|DJ
|[[Double Jump]]
|-
|DR
|[[Dive Recover]]
|-
|DSS
|Double Star Spawn
|-
|GP
|Ground Pound
|-
|HAU
|Hexadecimal Angle Unit
|-
|HOLP
|[[Held Object's Last Position]]
|-
|KtQ
|[[Koopa the Quick]]
|-
|LJ
|[[Long Jump]]
|-
|MC
|[[Metal Cap]]
|-
|NUT
|Nonstatic Unit Truncation
|-
|OoB
|Out of Bounds
|-
|PU
|[[Parallel Universe]]
|-
|QPU
|[[Quadruple Parallel Universe]]
|-
|RNG
|[[RNG|Random Number Generation]]
[[RNG|Random Number Generator]]
|-
|SM64
|[[Super Mario 64]]
|-
|VC
|[[Virtual Console]]
[[Vanish Cap]]
|-
|VS
|[[Vertical Speed]]
Vacant Slot
|-
|WC
|[[Wing Cap]]
|-
|WK
|Wall Kick
|}
== Technical Tricks & Glitches ==
{| class="wikitable sortable"
!Abbreviation
!Meaning
|-
|BCA
|[[Behind Camera Anywhere]]
|-
|BLJ
|[[Backwards Long Jump]]
|-
|BSH
|[[Backward Shell Hyperspeed]]
|-
|CT
|Cannon Teleportation
|-
|CWT
|[[Chuckya Wrong Throw]]
|-
|DSG
|Death Star Glitch
|-
|FBB
|[[Bully battery|Fast Bully Battery]]
|-
|FSH
|[[Forward Shell Hyperspeed]]
|-
|GLG
|[[Glitchy Ledge Grab]]
|-
|GWK
|[[Glitchy Wall Kick]]
|-
|HSB
|Hyperspeed Bouncing
Hyperspeed Braking
|-
|HSC
|Horizontal Speed Conservation
Hyperspeed Crawling
|-
|HSF
|[[Hyperspeed Flying]]
|-
|HSG
|[[Hyperspeed Grinding]]
|-
|HSJK
|[[Hyperspeed Jump Kicking]]
|-
|HSP
|[[Hyperspeed Punching]]
|-
|HSSK
|[[Hyperspeed Slide Kicking]]
|-
|HSTA
|[[Hyperspeed Turnaround]]
|-
|HSW
|[[Hyperspeed Walking]]
|-
|HSWK
|[[Hyperspeed Wall Kicking]]
|-
|HSWS
|[[Hyperspeed Water Sliding]]
|-
|LBLJ
|[[Lobby Backwards Long Jump]]
|-
|MDS
|[[Moat Door Skip]]
|-
|MPA
|[[Mario's Platform Adventure]]
|-
|NJ
|Negative Jump
|-
|OJ
|Overflow Jump
|-
|PBH
|[[Pause Buffered Hitstun]]
|-
|PRD
|[[Platform Release Displacement]]
[[Platform Rotation Displacement]]
|-
|PT
|Pole Teleportation
|-
|RLB
|[[Remote Lava Boost]]
|-
|SBB
|[[Bully battery|Slow Bully Battery]]
|-
|SBC
|[[Star Bounce Cancel]]
[[Other_single_button_challenges#The_Start_Button_Challenge|Start Button Challenge]]
|-
|SBLJ
|[[SBLJ|Side Backwards Long Jump]]
|-
|SCGP
|[[Squish cancel|Squish Cancel Ground Pound]]
|-
|SDC
|[[Star Dance Clip]]
|-
|VHSC
|[[Vertical and Horizontal Speed Conservation]]
|-
|VSC
|[[Vertical Speed Conservation]]
|-
|VSCC
|[[VSC Conservation]]
|-
|WHS
|Wind Hyperspeed
|}
== Other ==
=== Challenges ===
{| class="wikitable sortable"
!Abbreviation
!Meaning
|-
|0xA
|[[A Button Challenge|Zero A Presses]]
|-
|ABC
|[[A Button Challenge]]
|-
|BBC
|[[B Button Challenge]]
|-
|CC
|[[Capless/Cannonless Challenge|Capless Cannonless]]
|-
|CCC
|[[Coinless Capless Cannonless]]
|-
|RBC
|[[Other_single_button_challenges#The_R_Button_Challenge|R Button Challenge]]
|-
|SBC
|[[Star Bounce Cancel]]
[[Other_single_button_challenges#The_Start_Button_Challenge|Start Button Challenge]]
|-
|ZBC
|[[Z Button Challenge]]
|}
=== Software Terminology ===
{| class="wikitable sortable"
!Abbreviation
!Meaning
|-
|M64
|[[Mupen64]], .m64 (Mupen64 movie file)
|-
|MHS
|Memory Hacking Software
|-
|N64
|[[Nintendo 64]]
|-
|PJ64
|[[Emulators|Project64]]
|-
|RR
|[[Rainbow Ride]]
Rerecord
|-
|SM64SR
SMSR
|Super Mario Star Road
|-
|ST
|Savestate
|-
|STROOP
|[[STROOP|SuperMario64 Technical Runtime Observer and Object Processor]]
|-
|TAS
|[[Tool Assisted Speedrun]]
[[Tool Assisted Superplay]]
|-
|TT64
|Toad’s Tool 64
|}
[[Category:Help]]
[[Category:Resources]]

Mupen64

2024-02-17T20:14:41Z

Aurumaker72: Fix "recording movies" formatting

{{stub}}
'''Mupen64''' is a [[Nintendo 64]] [[Emulators|emulator]] useful for its TASing capabilities.

There are many forks of Mupen64, the primary community-maintained one being [https://github.com/mkdasher/mupen64-rr-lua- mupen64-rr-lua], which is nearly universally used for TASing Super Mario 64
=Mupen64plus=
'''Mupen64plus''' (stylized as '''mupen64plus''') is an emulator used for real-time gameplay.

It is generally preferred in this regard over Mupen64. Mupen64plus, as well as m64p-based frontends such as OpenEMU, are also allowed for Super Mario 64 [[RTA|speedrunning]].
=mupen64-rr-lua=
'''[https://github.com/mkdasher/mupen64-rr-lua- mupen64-rr-lua]''' is an emulator used for TASing and is most commonly used to record and play back TAS movies.

It is a fork of Mupen64-RR-lua which is actively maintained by the community. It introduces the lua scripting extension, QoL features, and security patches

=== Recording movies ===
# Navigate to the `Movie` menu and select `Start Movie Recording`...
# Click "Save As" to pick the movie save location
# Select a start type.
#* Start: The movie will start from a console reset
#* Savestate: The movie will start from a savestate created upon confirming the dialog
#* Existing Savestate: The movie will start from the savestate picked by the user upon confirming the dialog
#* EEPROM: The movie will start from a console reset, but with unreset EEPROM
# (optional) Type your name and a description into the respective fields
# Confirm the dialog

=== Continuing Movies ===

# Make sure a movie is playing back
# Disable read-only mode
# Create a savestate
# Load the savestate
# The recording has begun from the frame the savestate was created at

==Features==
===Lua===
mupen64-rr-lua supports Lua scripting, which gives it much more power for testing and brute forcing<ref>http://adelikat.tasvideos.org/emulatordownloads/mupen64-rr/LuaExtension_r34_bin.zip</ref>. It is used for TASing, as well as for testing and preparing.
===Emulate Float Crashes===
mupen64-rr-lua supports crashing during certain float-to-short exceptions just like the [[Nintendo 64]] console does. This is a useful alternative to [[TASBot#Console Verification|console verification]], but not as reliable, because there are still some [[Crash#Unknown cause|unknown crashes]].
===WiiVC Rounding===
mupen64-rr-lua supports emulating the [[Wii VC Round-To-Zero]] oversight<ref>https://www.mediafire.com/file/p2qpz0u39fhub8k/mupen64-wiivc.exe/file</ref>. It has been used, among other things, by pannenkoek2012 to TAS the [[Bowser in the Fire Sea#A Press Counts|Bowser in the Fire Sea 0x A presses]] run<ref>https://www.youtube.com/watch?v=Aa_CciaM4aM</ref>.

=References=
<references />

Mupen64

2024-02-17T20:13:33Z

Aurumaker72: Clean up and consolidate info

{{stub}}
'''Mupen64''' is a [[Nintendo 64]] [[Emulators|emulator]] useful for its TASing capabilities.

There are many forks of Mupen64, the primary community-maintained one being [https://github.com/mkdasher/mupen64-rr-lua- mupen64-rr-lua], which is nearly universally used for TASing Super Mario 64
=Mupen64plus=
'''Mupen64plus''' (stylized as '''mupen64plus''') is an emulator used for real-time gameplay.

It is generally preferred in this regard over Mupen64. Mupen64plus, as well as m64p-based frontends such as OpenEMU, are also allowed for Super Mario 64 [[RTA|speedrunning]].
=mupen64-rr-lua=
'''[https://github.com/mkdasher/mupen64-rr-lua- mupen64-rr-lua]''' is an emulator used for TASing and is most commonly used to record and play back TAS movies.

It is a fork of Mupen64-RR-lua which is actively maintained by the community. It introduces the lua scripting extension, QoL features, and security patches
==Recording movies==

# Navigate to the `Movie` menu and select `Start Movie Recording`...
# Click "Save As" to pick the movie save location
# Select a start type.
#* Start: The movie will start from a console reset
#* Savestate: The movie will start from a savestate created upon confirming the dialog
#* Existing Savestate: The movie will start from the savestate picked by the user upon confirming the dialog
#* EEPROM: The movie will start from a console reset, but with unreset EEPROM
# (optional) Type your name and a description into the respective fields
# Confirm the dialog

=== Continuing Movies ===

# Make sure a movie is playing back
# Disable read-only mode
# Create a savestate
# Load the savestate
# The recording has begun from the frame the savestate was created at

==Features==
===Lua===
mupen64-rr-lua supports Lua scripting, which gives it much more power for testing and brute forcing<ref>http://adelikat.tasvideos.org/emulatordownloads/mupen64-rr/LuaExtension_r34_bin.zip</ref>. It is used for TASing, as well as for testing and preparing.
===Emulate Float Crashes===
mupen64-rr-lua supports crashing during certain float-to-short exceptions just like the [[Nintendo 64]] console does. This is a useful alternative to [[TASBot#Console Verification|console verification]], but not as reliable, because there are still some [[Crash#Unknown cause|unknown crashes]].
===WiiVC Rounding===
mupen64-rr-lua supports emulating the [[Wii VC Round-To-Zero]] oversight<ref>https://www.mediafire.com/file/p2qpz0u39fhub8k/mupen64-wiivc.exe/file</ref>. It has been used, among other things, by pannenkoek2012 to TAS the [[Bowser in the Fire Sea#A Press Counts|Bowser in the Fire Sea 0x A presses]] run<ref>https://www.youtube.com/watch?v=Aa_CciaM4aM</ref>.

=References=
<references />

Mupen64

2024-02-15T05:43:21Z

Aurumaker72: Add usage - continuation of movie explanation

{{stub}}
'''Mupen64''' is a [[Nintendo 64]] [[Emulators|emulator]] useful for its TASing capabilities.

There are many forks of Mupen64, the primary community-maintained one being [https://github.com/mkdasher/mupen64-rr-lua- mupen64-rr-lua], which is nearly universally used for TASing Super Mario 64
=Mupen64plus=
'''Mupen64plus''' (stylized as '''mupen64plus''') is an emulator used for standard gameplay. It is generally preferred in this regard over Mupen64. Mupen64plus (and OpenEMU, a multiconsole emulator that uses the Mupen64plus core) is also allowed for Super Mario 64 [[RTA|speedrunning]].
=Mupen64-RR=
'''Mupen64-RR''' (stylized as '''mupen64-rr''') is an emulator used for TASing. It is most commonly used to record TAS movies. The file type used for the movies are: ".m64" and ".st", m64 is the movie, which can be launched if you go to "Playback Movie" but if you have started from snapshot, you will need a .st file in order to make the movie work, otherwise the movie will not start.
==TASing with Mupen64-RR==
Open a Super Mario 64 ROM in Mupen64. Go to Utilities --> Movie --> Start Movie Recording. Type in a name, author, and/or description if you wish. You can also choose to start from the start (when you boot it up), or you can choose the star from a snapshot you have made. Click on OK, and your TAS will start. Press - or + to speed up or down whilst recording. You can also press \ (the slash usually above RETURN) to advance a single frame. To unpause/pause, press Pause. If you don't have a Pause button on your keyboard, go to the settings, and change the hotkey from Pause to something else. To continue from a TAS, put the movie settings in "read only" mode. Then when the TAS stops at the time you want to continue, then turn off the "read only" mode. After that, save a state and reload it to continue a TAS.
==Hacked versions of Mupen64-RR==
Because Mupen64 does not have perfect emulation accuracy, there are several hacked versions of Mupen to deal with this, as well as to allow for additional functionality.
===Mupen64-Lua===
'''Mupen64-Lua''' supports Lua scripting, which gives Mupen64-rr much more power for testing and brute forcing<ref>http://adelikat.tasvideos.org/emulatordownloads/mupen64-rr/LuaExtension_r34_bin.zip</ref>. It is used for TASing, as well as for testing and preparing.
===Mupen64-PUs===
'''Mupen64-PUs''' is a modified version of Mupen that crashes during certain float-to-short exceptions just like the [[Nintendo 64]] console does. This is a useful alternative to [[TASBot#Console Verification|console verification]], but not as reliable, because there are still some [[Crash#Unknown cause|unknown crashes]].
===Mupen64-WiiVC-RTZ===
'''Mupen64-WiiVC-RTZ''' is a version of Mupen that emulates the [[Wii VC Round-To-Zero]] oversight<ref>https://www.mediafire.com/file/p2qpz0u39fhub8k/mupen64-wiivc.exe/file</ref>. It has been used, among other things, by pannenkoek2012 to TAS the [[Bowser in the Fire Sea#A Press Counts|Bowser in the Fire Sea 0x A presses]] run<ref>https://www.youtube.com/watch?v=Aa_CciaM4aM</ref>.

== mupen64-rr-lua ==
'''mupen64-rr-lua''' is a fork of Mupen64-RR which is actively maintained by the community. It introduces the lua scripting extension, QoL features, and security patches

== Usage ==

=== Continuation of movie ===

# Make sure a movie is playing back
# Disable read-only mode
# Create a savestate
# Load the savestate
# The recording has begun from the frame the savestate was created at

=References=
<references />

File:Mupen-continue-movie.png

2024-02-15T05:41:28Z

Aurumaker72:

A screenshot of a discord chat which describes how to continue a movie in mupen64

Mupen64

2023-12-15T21:34:08Z

Aurumaker72: Rewrite introduction, add info regarding new mupen

{{stub}}
'''Mupen64''' is a [[Nintendo 64]] [[Emulators|emulator]] useful for its TASing capabilities.

There are many forks of Mupen64, the primary community-maintained one being [https://github.com/mkdasher/mupen64-rr-lua- mupen64-rr-lua], which is nearly universally used for TASing Super Mario 64
=Mupen64plus=
'''Mupen64plus''' (stylized as '''mupen64plus''') is an emulator used for standard gameplay. It is generally preferred in this regard over Mupen64. Mupen64plus (and OpenEMU, a multiconsole emulator that uses the Mupen64plus core) is also allowed for Super Mario 64 [[RTA|speedrunning]].
=Mupen64-RR=
'''Mupen64-RR''' (stylized as '''mupen64-rr''') is an emulator used for TASing. It is most commonly used to record TAS movies. The file type used for the movies are: ".m64" and ".st", m64 is the movie, which can be launched if you go to "Playback Movie" but if you have started from snapshot, you will need a .st file in order to make the movie work, otherwise the movie will not start.
==TASing with Mupen64-RR==
Open a Super Mario 64 ROM in Mupen64. Go to Utilities --> Movie --> Start Movie Recording. Type in a name, author, and/or description if you wish. You can also choose to start from the start (when you boot it up), or you can choose the star from a snapshot you have made. Click on OK, and your TAS will start. Press - or + to speed up or down whilst recording. You can also press \ (the slash usually above RETURN) to advance a single frame. To unpause/pause, press Pause. If you don't have a Pause button on your keyboard, go to the settings, and change the hotkey from Pause to something else. To continue from a TAS, put the movie settings in "read only" mode. Then when the TAS stops at the time you want to continue, then turn off the "read only" mode. After that, save a state and reload it to continue a TAS.
==Hacked versions of Mupen64-RR==
Because Mupen64 does not have perfect emulation accuracy, there are several hacked versions of Mupen to deal with this, as well as to allow for additional functionality.
===Mupen64-Lua===
'''Mupen64-Lua''' supports Lua scripting, which gives Mupen64-rr much more power for testing and brute forcing<ref>http://adelikat.tasvideos.org/emulatordownloads/mupen64-rr/LuaExtension_r34_bin.zip</ref>. It is used for TASing, as well as for testing and preparing.
===Mupen64-PUs===
'''Mupen64-PUs''' is a modified version of Mupen that crashes during certain float-to-short exceptions just like the [[Nintendo 64]] console does. This is a useful alternative to [[TASBot#Console Verification|console verification]], but not as reliable, because there are still some [[Crash#Unknown cause|unknown crashes]].
===Mupen64-WiiVC-RTZ===
'''Mupen64-WiiVC-RTZ''' is a version of Mupen that emulates the [[Wii VC Round-To-Zero]] oversight<ref>https://www.mediafire.com/file/p2qpz0u39fhub8k/mupen64-wiivc.exe/file</ref>. It has been used, among other things, by pannenkoek2012 to TAS the [[Bowser in the Fire Sea#A Press Counts|Bowser in the Fire Sea 0x A presses]] run<ref>https://www.youtube.com/watch?v=Aa_CciaM4aM</ref>.

== mupen64-rr-lua ==
'''mupen64-rr-lua''' is a fork of Mupen64-RR which is actively maintained by the community. It introduces the lua scripting extension, QoL features, and security patches.

=References=
<references />

User talk:Aurumaker72

2023-06-30T13:10:49Z

Aurumaker72: Blanked the page

User:Aurumaker72

2023-06-30T13:09:54Z

Aurumaker72: Blanked the page

Whomp

2022-03-12T11:25:15Z

Aurumaker72:

{{stub}}
[[File:Whomp.png|link=link=Special:FilePath/Whomp|alt=|thumb|326x326px]]

Whomps/Slab Beasts are large, vertical enemies.

=== Attack Patterns ===
They move along a predefined path until detecting [[Mario]] in a frontal radius. Upon detection, they will fall towards Mario and attempt to crush him.

=== Defeating ===
They can be defeated by ground-pounding on their back whilst laying horizontally.

=== Appearance ===

* Whomp's Fortress
* Bowser In The Sky

STROOP

2020-08-06T17:39:55Z

Aurumaker72: /* Controllers */Remove tranman's useless todo

'''S'''uperMario64 '''T'''echnical '''R'''untime '''O'''bserver and '''O'''bject '''P'''rocessor, or '''STROOP''' for short, is a '''diagnostic tool''' for [[Super Mario 64]] which displays and allows for simple editing of various game values and information. It can connect to a running emulator and update values in real time. Some core features include views of loaded/unloaded objects, Mario structure variables, [[Camera|camera]] + [[HUD]] values, an overhead map display, and many more. An up-to-date version of STROOP can be downloaded from [https://github.com/SM64-TAS-ABC/STROOP/releases/download/vDev/STROOP.zip here].
[[File:STROOP.jpg|350px|thumb|STROOP on [https://en.wikipedia.org/wiki/Windows_10 Windows 10]]]
[[File:ObjectSlotHack.png|350px|thumb|Tyler's ROM hack that displayed the object slots in text form]]
[[File:Blueprint.png|350px|thumb|A blueprint of what Pannenkoek2012 suggested the program should look like]]
[[File:SM64_diagnostic.png|350px|thumb|The SM64 Diagnostic]]

== History ==
After [[User:Pannenkoek2012|Pannenkoek2012]] discussed [[Object Slot|object slots]] in his [https://youtu.be/9xE2otZ-9os Science of Cloning] video, there had been a desire to view the object slots of the game in real time. Pannenkoek2012 discussed this desire with Tyler Kehne. Tyler then proceeded to make a ROM hack that could display the object slot behaviors in text form, overlaid onto the screen. Pannenkoek2012 was not pleased with this implementation, as he wanted a separate program that would show the slots visually with images of the objects. Thus, Tyler then proceeded to make a program that would do just that, which he named the SM64 Diagnostic. Tyler wrote the code for it, and Pannenkoek2012 provided the [[Object|object]] images and names. The SM64 Diagnostic was a major breakthrough, as it showed the object slots, the process groups, the held object, object variables, and Mario variables. However, it also had some annoyances, such as it couldn't connect to an already open Mupen (it had to open Mupen itself), it would occasionally crash Mupen, the [[Angle|angle]] variables (yaw/pitch/roll) had confusing names, the variables couldn't be edited, and the checkbox variables used a confusing system.

Some time later, Dane Bouchie created a new program called STROOP, which was based on the SM64 Diagnostic, but with many more features and improved functionality. Later, Pannenkoek2012 also began coding for STROOP, adding even more features and functionality. As of today, STROOP has object slots, object variables, Mario variables, [[HUD]] variables, camera variables, triangle variables, water variables, an input display, a file display, a map that can display objects in real time, an M64 editor, and savable options so that the user can customize their experience.

== Loading Screen ==
[[File:STROOP loading screen.gif|350px|thumb|STROOP Loading Screen]]
When first opening STROOP, you'll be greeted with a loading screen. This displays what is currently being initialized, as well as a random helpful hint.
You can right click the text field and a context menu will appear. Upon clicking it, a list of all helpful hints will appear.

== Connection Screen ==
[[File:Connection Screen.jpg|475px|thumb|STROOP Connection Screen]]
After STROOP finishes loading, you'll encounter a screen where you can choose what process or savestate to connect to. There are various buttons to use:
* '''Refresh''': Refreshes the list of processes to choose from.
* '''Connect''': Connects STROOP to the currently selected process.
* '''Bypass''': Bypasses the start screen. Note that most functionality won't work if you press this, as most functionality relies on having a data stream to interact with. But this could be useful if you only want to use the M64 editor, for example.
* '''Refresh & Connect''': Refreshes the list of processes to choose from, and then connects STROOP to the currently selected process. This can save a button press in the case that you need to press both Refresh and Connect.
* '''Open Savestate''': Connects STROOP to a savestate, chosen from the File Manager. This can be useful if you want to modify values in a savestate, such as global timer or RNG. If you've edited a savestate and want to save it, then right click on the Disconnect button on the top left of STROOP, and you'll see an option to save the savestate.

== Top-Level Controls ==
On the top of STROOP are several controls that may be of use. These are:
* '''Disconnect Button''': Disconnects from the current process or savestate. Right click on this for the option to save a savestate after it's been modified.
* '''FPS Counter''': Displays the number of frames per second that STROOP is running at. By default, STROOP aims for 30 FPS. However, this can be changed in the Options tab.
* '''Connected To''': Displays the process that STROOP is currently connected to.
* '''Left/Right Arrow Buttons''': These can be used to reorder tabs. Simply click on one of the arrow buttons and the currently selected tab will move one spot over in that direction. Right click on these buttons for an option to restore the tabs to the recommended tab order. Separately, you can click on the arrow buttons while holding control, and this will move the currently selected object slots over one spot in that direction. Furthermore, you can click on the arrow buttons while holding a number n, and this will move the currently selected object slots over n spots in that direction.
* '''Add Tab Button''': Click on this button to see a list of tabs that have been hidden. Click on one of these tabs to restore that tab. Alternatively, click on "Restore All Tabs" to restore all of the tabs.
* '''ROM Version''': This displays the ROM version that STROOP is currently operating under. By default, it tries to auto-detect what ROM version is being used. However, if you want to use a specific ROM version instead of the auto-detected one, then choose one of the ROM version options without the "AUTO" prefix.
* '''ReadWrite/ReadOnly Mode''': This displays whether STROOP is is ReadWrite mode or ReadOnly mode. By default, it will be in ReadWrite mode, allowing the user to modify variables. In ReadOnly mode, modifying variables won't work.
* '''Panel Hide/Show Buttons''': These 6 buttons allow you to adjust which panels are hidden/shown in any tab of STROOP. In order from left to right, these are: Left Only, Left + Right, Right Only, Bottom Only, Bottom + Top, Top Only. By default, these buttons will only affect the outermost panels. However, for situations where there are nested panels (e.g. the Memory Tab), you can control which set of panels is being targeted by holding down a number key. Specifically, holding down the number n will target the nth set of panels, where panels are indexed from outermost to innermost. Thus, holding down the number 1 is equivalent to not holding down any number, since it automatically targets the outermost pair of panels. Holding down 2 or higher will affect other panels, assuming they're on screen.
* '''Cog''': The cog can be used to quickly and easily toggle savable options, to reset saved options, or to go directly to the Options tab. For more information about the savable options, see the Options Tab section.
* '''Version Number''': This displays the current version number of STROOP. Right clicking on this provides debugging/developer options, most of which aren't intended for the casual user. Nevertheless, some useful options include:
** '''Enable [[TAS]]er Settings''': Switches to the TAS tab, hides the left panel, filters variables to show only the TAS variables, and enables the STROOP ROM hack. This setting was created for Plush's convenience.
** '''Show MHS Vars''': Opens a Pop Out with variables commonly found in MHS. This is a convenience for users that are used to using MHS.
** '''Download Latest STROOP Release''': Downloads the latest STROOP release. This downloads as a separate file, instead of replacing the currently-being-used STROOP file.
** '''Show All Helpful Hints''': Shows a list of all helpful hints from the loading screen.
** '''Show Skribblio Words''': Shows a list of all Skribbl.io words in a randomized order.

== Tabs ==

STROOP has several tabs, each of which manages one specific domain. For example, there's a Mario tab, Triangles tab, M64 tab, Map tab, etc. In fact, there are so many tabs that it's recommended that you customize which tabs are shown and their order, for your own convenience. To reorder tabs, use the left/right arrow buttons on the top right of STROOP, which will move the current tab one space over in the arrow's direction. To hide a tab, click on the tab while holding control. Using these 2 techniques, you should be able to reduce the number of tabs to a reasonable amount as well as put the tabs in the order most convenient to you. If you ever need to use a tab that you've hidden, then simply add it back using the Add Tab button on the top right of STROOP. Note that the order of tabs and which tabs are hidden are saved, so you only need to do this once, as these settings will stay the same on subsequent STROOP opens. However, if you ever download a new version of STROOP, the settings will be back to their original state. Nevertheless, you can always copy the saved settings file (STROOP\Config\SavedSettings.xml) from the older version of STROOP and replace that corresponding file in the newer version of STROOP.
{{STROOP_Tabs}}

== Object Slot Panel ==

The lower half of STROOP is the [[Object Slot]] Panel. This shows all 240 object slots in the game. There are various controls to use at the top of the panel:
* '''Lock Labels Checkbox''': This locks the labels on the slots so that they'll no longer change. The labels will also turn blue to indicate that they are no longer changing. This can be useful if you want to see how the object slots change from one point in time to another, as you can know what positions the slots used to be in.
* '''Slot Size Slider''': This controls the size of the object slots.
* '''Label Method''': This controls what label method is used to determine the label for the object slots.
** '''Recommended''': This uses the recommended label method for the current Sort Method. Specifically, it will use SlotPosVs for ProcessingOrder, SlotIndex for MemoryOrder, and SlotPosVs for DistanceToMario.
** '''SlotPosVs''': Loaded object slots will use their processing index, and unloaded object slots will use their processing index prefixed with "VS".
** '''SlotPos''': Loaded object slots will use their processing index, and unloaded object slots will continue the indexing from where the loaded slots left off.
** '''SlotIndex''': Object slots will use their memory index.
* '''Sort Method''': This controls how the object slots are sorted.
** '''ProcessingOrder''': The object slots are sorted by their processing order. In other words, the loaded object slots are in the order by which they are processed (i.e. updated), and the unloaded object slots are in the order by which they would take on more objects.
** '''MemoryOrder''': The object slots are sorted by their memory order. In other words, they are sorted by the memory addresses of the object structs that each object slot represents.
** '''DistanceToMario''': The object slots are sorted by their distance to Mario, from closest to farthest. Note that the loaded object slots are presented first, then followed by the unloaded object slots.

You can also right click on the Object Slot Panel for the option to select the object slot corresponding to the value that you've copied (i.e. what's on the clipboard).

== Object Slots ==

The object slots are found in the Object Slot Panel. An object slot has 4 parts to it: an image, a label, a background color, and zero or more overlays.
* '''Image''': The image shows what object is represented by the object slot. The image is transparent when the object is unloaded or set to be unloaded.
* '''Label''': The label represents the index of the slot by some indexing system (see Label Method under Object Slot Panel).
* '''Background Color''': The background color represents what Process Group the object belongs to.
** Process Group 0x0B (Spawner) is Pink
** Process Group 0x09 (Surface) is Red
** Process Group 0x0A (Usable) is Red-Orange
** Process Group 0x00 (Player) is Orange
** Process Group 0x05 (Pushable) is Yellow
** Process Group 0x04 (Actor) is Green
** Process Group 0x02 (Respawning) is Light Blue
** Process Group 0x06 (Level) is Dark Blue
** Process Group 0x08 (Default) is Purple
** Process Group 0x0C (Unimportant) is Brown
** Vacant Group is Grey
[[File:Object Slot Overlays.png|350px|thumb|The object slot overlays]]
* '''Overlays''': The overlays are images overlaid onto certain object slots to provide additional information. The object slots are as follows:
** '''Selected''': The object(s) selected in the Object Tab.
** '''Map''': The object(s) that are shown on the map in the Map Tab and Map2 Tab.
** '''Map Home''': The object(s) whose home(s) are shown on the map in the Map2 Tab.
** '''Model''': The object that's shown in the Model Tab.
** '''Marked''': The object(s) that are marked. Click on an object slot while holding Alt to mark it.
** '''Closest''': The loaded object that's closest to Mario.
** '''Held''': The object that Mario's holding.
** '''Stood On''': The object that Mario's standing on.
** '''Interaction''': The object that Mario's interacting with.
** '''Used''': The object that Mario's using.
** '''Ridden''': The object that Mario's riding on.
** '''Camera''': The secondary object that the camera is set to focus on.
** '''Camera Hack''': The object that is being focused on using the Camera Hack.
** '''Floor''': The object that Mario's [[Surface#Floors|floor]] triangle belongs to.
** '''Wall''': The object that Mario's [[Surface#Walls|wall]] triangle belongs to.
** '''Ceiling''': The object that Mario's [[Surface#Ceilings|ceiling]] triangle belongs to.
** '''Parent''': The parent of the currently hovered object.
** '''Parent Unused''': The currently hovered object when the currently hovered object's parent is the unused slot.
** '''Parent None''': The currently hovered object when the currently hovered object has no parent.
** '''Child''': A child of the currently hovered object.
** '''Collision 1''': The 1st collision object of the Mario object.
** '''Collision 2''': The 2nd collision object of the Mario object.
** '''Collision 3''': The 3rd collision object of the Mario object.
** '''Collision 4''': The 4th collision object of the Mario object.
* Some additional notes on the overlays:
** Which overlays are displayed can be changed in the Options tab. By default, all overlays are displayed except for Parent and Child ones, as these are the only ones dependent on the currently hovered object. Nevertheless, there's a shortcut to quickly and temporarily see an object's parent/child, which is to hold down P while hovering over an object slot.
** By default, the collision objects are in reference to the Mario object. However, if you want to see the collision objects for a different object, then simply hold down C while hovering over that object's slot.
** The Selected, Map, Map Home, Marked, Model, and Camera Hack overlays represent overlays that the user can modify themselves by clicking on the object slots when under certain circumstances. For some of these, multi-selection is available, meaning that multiple slots can be selected at the same time. In these cases, the shortcut of holding shift can be used to select the range of object slots between the previously selected object slot and the currently selected object slot. When multi-selection is available, there's also the concept of toggle-ability, explained as follows. In some cases (e.g. Selected), clicking on an object slot will select that object slot and unselect all other object slots. In these cases, holding control will make it so that clicking on an object slot will toggle that slot's selectedness while leaving all other slots' selectednesses unchanged. In other cases (e.g. Map, Marked), the situation is reversed. That is, clicking on an object slot will toggle that slot's selectedness while leaving all other slots' selectednesses unchanged, whereas holding control will make it so that clicking on an object slot will select that object slot and unselect all other object slots. We say that these cases are toggle-able by default. In both situations, holding control will toggle whether we're in toggle-mode or not, but it's just that the default mode may or may not be toggle-able. Here is more information:
*** '''Selected''': Modifiable when clicking on an object slot. Multi-selection allowed.
*** '''Map''': Modifiable when clicking on an object slot in the Map Tab or Map2 Tab. Multi-selection allowed. Toggle-able by default.
*** '''Map Home''': Modifiable when clicking on an object slot in the Map2 Tab with H held. Multi-selection allowed. Toggle-able by default.
*** '''Model''': Modifiable when clicking on an object slot in the Model Tab.
*** '''Marked''': Modifiable when clicking on an object slot with Alt held. Multi-selection allowed. Toggle-able by default.
*** '''Camera Hack''': Modifiable when clicking on an object slot in the Cam Hack Tab.

You can right click on an object slot for even more options. Note that the option will by default only affect the object slot that was right clicked on. If instead you want to have the option affect all slots that are selected, then click the option while holding control. The options are as follows:
* '''Select in Object Tab''': Selects the object slot in the Object Tab, and switches to the Object Tab.
* '''Select in Memory Tab''': Selects the object slot in the Memory Tab, and switches to the Memory Tab.
* '''Go to''': Sends Mario to the object, offset by the "Go to offset" in the Options Tab.
* '''Retrieve''': Sends the object to Mario, offset by the "Retrieve offset" in the Options Tab.
* '''Go to Home''': Sends Mario to the object's home, offset by the "Go to offset" in the Options Tab.
* '''Retrieve Home''': Sends the object's home to Mario, offset by the "Retrieve offset" in the Options Tab.
* '''Release''': Releases the object by settings its Release Status. This is identical to releasing a clone of an object that isn't meant to be released.
* '''UnRelease''': Undoes the releasing of an object.
* '''Interact''': Interacts with an object by setting its Interaction Status to 0xFFFFFFFF. This can be useful if you don't want to interact with a [[Cloning|clone]], e.g. making a fire clone inert.
* '''UnInteract''': Undoes the interacting of an object by setting its Interaction Status to 0x00000000.
* '''Clone''': Clones the object into Mario's hands.
* '''UnClone''': Undoes the cloning of the object by clearing what's in Mario's hands. This doesn't actually release the object.
* '''Unload''': Sets the object to be unloaded.
* '''Revive''': Revives an unloaded object into a loaded state.
* '''Ride''': Has Mario ride on the object. Specifically, sets Mario's ridden object to that object and puts Mario into a riding state.
* '''UnRide''': Undoes the riding of an object.
* '''Ukikipedia''': Opens up the Ukikipedia page for an object.
* '''Copy Address''': Copies the object's address to the clipboard.
* '''Copy Position''': Copies the object's position to the clipboard.
* '''Paste Position''': Pastes the clipboard data onto an object's position.
* '''Copy Graphics''': Copies the object's graphics value to the clipboard.
* '''Paste Graphics''': Pastes the clipboard data onto an object's graphics value.
* '''Copy Object''': Copies the object's bytes to a custom clipboard in STROOP.
* '''Paste Object''': Pastes STROOP's custom clipboard data onto the object. Note that this doesn't overwrite the object's next/previous memory/processed object slots references, since that would corrupt the linked list structure.

== Variable Panel ==

== Variables ==

Variables are found in a Variable Panel. A variable has 2 parts to it: a name (on the left) and a value (on the right). On every STROOP update, the value updates. You can set a variable's value by double clicking on the value, entering text, and then pressing enter. Some variables are values in memory, while other variables are calculated manually (referred to as special variables). While memory variables can always be set, special variables may or may not be able to be set. If you try to set a variable and it doesn't go through (either because the variable can't be set or because you entered an illegal value), then the variable will flash red to indicate this.

All variables come with the following options when right clicked:
* '''Highlight''': Highlights the variable by giving it a red outline.
* '''Lock''': Locks the variable's value. Note that the variable's value can still be edited while it's locked.
* '''Copy''': Copies the variable's value (with no rounding) to the clipboard.
* '''Paste''': Pastes the clipboard value to the variable.
* '''Panel Options''': Opens up the Variable Panel options.
* '''Open Controller''': Opens up an Advanced Controller for the variable.
* '''Add to Custom Tab''': Adds the variable to the Custom Tab.
* '''Fix Address''': Fixes the address of the variable.
* '''Rename''': Allows you to rename the variable.
* '''Remove''': Removes the variable from the Variable Panel.

Number variables come with the following additional options when right clicked:
* '''Round to ...''': Sets how many digits to round the variable to.
* '''Display as Hex''': Toggles whether the variable is displayed as hex or decimal.

Angle variables come with the following additional options when right clicked:
* '''Signed''': Toggles whether the variable is displayed as signed or not.
* '''Units...''': Sets the units for the angle variable. The unit options are:
** '''In-Game Units''': These are the units that the game uses. One revolution is 65536 in-game units.
** '''HAU''': Standing for hexadecimal angle units, these are in-game units divided by 16. Thus, one revolution is 4096 HAU. These are useful because angles that fall under the same HAU value use the same entry in the game's trig table, since angles are truncated to the closest multiple of 16 before accessing the table.
** '''Degrees''': One revolution is 360 degrees.
** '''Radians''': One revolution is 2*pi radians.
** '''Revolutions''': One revolution is one revolution.
* '''Truncate to Multiple of 16''': Toggles whether the angle's value is truncated to a multiple of 16. This is useful since angles that truncated to same the closest multiple of 16 use the same entry in the game's trig table.
* '''Constrain to One Revolution''': Toggles whether the angle's value is constrained to one revolution. For example, an angle that's unsigned and in angle units would be constrained to the range [0, 65535], whereas an angle that's signed and in angle units would be constrained to the range [-32768, 32767].
* '''Reverse''': Toggles whether the angle is displayed as the reverse of what it actually is.

Address variables come with the following additional options when right clicked:
* '''View Address''': Views the variable's value as an address in the Memory Tab.

Object variables come with the following additional options when right clicked:
* '''Display as Object''': Displays the variable's value as an Object. Values include:
** '''Slot n''': The nth loaded slot.
** '''Slot VSn''': The nth vacant slot.
** '''PG n''': Process Group n's node.
** '''(none)''': The value 0.
** '''(unused object)''': The unused object slot.
** '''(unknown object)''': A value that's not recognized as a valid object reference.
* '''Select Object''': Selects the object slot whose object's address equals the variable's value.

Triangle variables come with the following additional options when right clicked:
* '''Select Triangle''': Selects a custom triangle in the Triangle Tab whose address equals the variable's value.

Boolean variables are unique in that instead of having a text value, they have a checkbox value. The checkbox is checked if the underlying number value (after possibly masking) is non-zero. In the case that the variable represents multiple values with different checked states, the checkbox will be indeterminant. Boolean variables come with the following additional options when right clicked:
* '''Display as Checkbox''': Toggles whether the variable is displayed as a checkbox.
* '''Display as Inverted''': Toggles whether the checkbox's checked state is inverted.

Variables can be selected by clicking on them. You can hold shift and click on a variable to select the range of variables from the previously selected variable to the currently selected variable. To toggle whether a variable is selected or not without unselecting all variable, click on the variable while holding control. To unselect all variables, click on the variable panel. If you right click on a variable that's selected, then you'll see a different set of options from normal, and these options will affect all selected variables. Options prefixed with "Angle:" only affect angles. Choosing the "Default" value for an option (e.g. Display as Hex) will set that option to how the variable was originally (e.g. its original status of whether it was displaying as hex). Here are these options:
* '''Highlight...''': Highlights the variables with a red or custom-colored outline.
* '''Lock...''': Locks the variables' values.
* '''Fix Address...''': Fixes the addresses of the variables.
* '''Copy...''': Copies the variable's value (with no rounding) to the clipboard. This can be done with commas, tabs, or line breaks separating the variable values. Separately, you can copy the variable values for code, which will copy instantiation statements for each of the variables, e.g. "float X = 100f". For more control over what the variables are named, hold control while clicking this option. This will open up a dialog where you can enter text, where the $ represents the variables' original names. For example, entering "my$Value" will result in "float myXValue = 100f" being copied to the clipboard.
* '''Paste''': Pastes the clipboard value to the variables. The values for the variables will be parsed from the clipboard value, which will work so long as the values are separated by whitespace (e.g. spaces, tabs, line breaks) or commas.
* '''Round to...''': Sets how many digits to round the variables to.
* '''Display as Hex...''': Sets whether the variables are displayed as hex or decimal.
* '''Angle: Signed...''': Sets whether the variables are displayed as signed or not.
* '''Angle: Units...''': Sets the units for the angle variables. See above for more information on the unit options.
* '''Angle: Truncate to Multiple of 16...''': Sets whether the angles' values are truncated to a multiple of 16.
* '''Angle: Constrain to One Revolution...''': Sets whether the angles' values are constrained to one revolution.
* '''Angle: Reverse...''': Sets whether the angles are displayed as the reverse of what it actually is.
* '''Angle: Display as Hex...''': Sets whether the angle variables are displayed as hex or decimal.
* '''Show Variable XML''': Shows the XML that represents the variables.
* '''Show Variable Info''': Shows info on the variables in table form, including Name, Type, Base + Offset, N64 Address, and Emulator Address.
* '''Background Color...''': Changes the variables background color.
* '''Move...''': Options for moving variables.
** '''Start Move''': Adds the selected variables to the moving-variables-clipboard.
** '''End Move''': Moves the variables on the moving-variables-clipboard to the location of the selected variables.
** '''Clear Move''': Clears the selected-variables-clipboard.
* '''Remove''': Removes the variables from the Variable Panel.
* '''Rename''': Allows you to rename the variables. This will open up a dialog where you can enter text, where the $ represents the variables' original names. For example, entering "my$Value" will result in renaming "X" to "myXValue".
* '''Open Controller''': Opens up an Advanced Controller for the variables.
* '''Open Triplet Controller''': Opens up a Triplet Controller for the variables.
* '''Open Pop Out''': Opens up a Pop Out for the variables.
* '''Add to Tab...''': Adds the variables to a tab of your choosing.
* '''Add to Custom Tab''': Adds the variables to the Custom Tab.

There are also many keyboard shortcuts that can be performed on variables, namely by clicking on a variable when holding one or more keys. These are:
* '''Double Click''': Opens up the Variable Viewer form for the variable, which shows the variable's Name, Type, Base + Offset, N64 Address, and Emulator Address.
* '''Click + Shift + Number''': Sets the variable's background color to different colors, depending on the number.
* '''Click + Number''': Sets the variable's highlight color to different colors, depending on the number.
* '''Click + S''': Adds the variable to the Custom Tab.
* '''Click + T''': Adds the variable to the TAS Tab.
* '''Click + M''': Adds the variable to the Memory Tab.
* '''Click + P''': Adds the variable to a tab of your choosing.
* '''Click + N''': Views the variable's value as an address in the Memory Tab.
* '''Click + F''': Fixes the address of the variable.
* '''Click + H''': Highlights the variable with a red outline.
* '''Click + L''': Locks the variable's value.
* '''Click + D''': Toggles whether the variable is displayed as hex or decimal.
* '''Click + R''': Allows you to rename the variable.
* '''Click + C''': Opens up an Advanced Controller for the variable.
* '''Click + B''': Opens up an Bit Controller for the variable.
* '''Click + Escape''': Removes the variable from the Variable Panel.
* '''Click + Backspace''': Removes the variable from the Variable Panel.
* '''Click + Delete''': Removes the variable from the Variable Panel.
* '''Click + X''': Does an action related to moving a variable. Specifically: If the moving-variables-clipboard is empty, then adds the variable to the moving-variables-clipboard. If the moving-variables-clipboard is non-empty, then moves the variables of the moving-variables-clipboard to the clicked variable's current location.
* '''Click + Backtick''': Adds the variable to the Var Hack tab.
* '''Click + Z''': Sets the variable value to zero.
* '''Click + Minus''': Decrements the variable value.
* '''Click + Plus''': Increments the variable value.
* '''Click + Q''': Sets the variable's background color to a custom color.
* '''Click + O''': Sets the variable's background color to the last custom color.

== Controllers ==

[[File:STROOP Controllers.png|350px|thumb|The various kinds of controllers]]
Controllers are a set of controls used for manipulating one or more variables. There are various kinds of controllers:

* '''Simple Controller''': A Simple Controller is in charge of manipulating one variable. It consists of 2 buttons and a textbox. The buttons are used for subtracting from and adding to the variable using the value that's in the textbox. Right clicking on one of the buttons shows the option to toggle whether the buttons are inverted, i.e. swapping whether subtraction is on the left and addition is on the right or vice versa. Simple Controllers are found on the left panel of several tabs of STROOP.

* '''Triplet Controller''': A Triplet Controller is in charge of manipulating a triplet of variables, usually a set of (x,y,z) Euler coordinates or (theta,phi,radius) spherical coordinates. It consists of 2 sets of controls:
** '''Square Controls''': On the left are the Square Controls, consisting of 8 buttons and a textbox arranged in square formation. For Euler coordinates, these controls manipulate the x and z coordinates. For spherical coordinates, these controls manipulate the theta and phi coordinates. In both cases, the buttons will add to or subtract from the corresponding variable(s) by the amount in the textbox. Note that you can right click on the buttons for more options so that you can customize the orientation of the buttons. Specifically, this allows you to rotate the buttons any one of eight ways, as well as invert the orientation (i.e. flip it).
** '''Line Controls''': One the right are the Line Controls, consisting of 2 buttons and a textbox arranged in a vertical line formation. For Euler coordinates, these controls manipulate the y coordinate. For spherical coordinates, these controls manipulate the radius coordinate. In both cases, the buttons will add to or subtract from the corresponding variable by the amount in the textbox. Note that you can right click on the buttons for options to invert the buttons.
: Triplet controllers also frequently have a Relative Checkbox in the upper right, which toggles whether the controls manipulate the variables absolutely or relative to some angle. When in relative mode, the labels on the buttons will change to emphasize this. Specifically, F = forward, B = backward, L = left, R = right, U = up, D = down. Triplet Controllers are found on the left panel of several tabs of STROOP. However, you can also create your own Triplet Controller by selecting 3 or 4 variables to represent the x,y,z and optional angle variables, right clicking, and choosing to open a Triplet Controller.

* '''Advanced Controller''': An advanced controller is in charge of manipulating one or more variables. It consists of the following controls:
** '''Name Textbox''': This shows the name(s) of the variable(s) being manipulated. Note that this can be edited.
** '''Fix Address Checkbox''': This is used to toggle whether the variable(s) are using fixed addresses.
** '''Value Textbox''': This displays the current value(s) of the variable(s). The background color is red if the variable(s) have fixed addresses, blue if the variable(s) don't have fixed addresses, and purple if some variables do and some variables don't have fixed addresses.
** '''Lock Checkbox''': This is used to toggle whether the variable(s) are locked.
** '''Subtraction Button''': This is used to subtract a value from the variable(s).
** '''Addition/Subtraction Textbox''': This is the value that's used by the Addition Button and Subtraction Button.
** '''Addition Button''': This is used to add a value to the variable(s).
** '''Get Button''': This gets the value(s) of the variable(s).
** '''Get/Set Textbox''': This is the value used by the Get Button and Set Button.
** '''Set Button''': This sets the value(s) of the variable(s).
: Additional notes:
:* In the case of setting multiple variables, you can set all of the variables to different values by separating the values in the textbox with commas. Alternatively, leave just one value in the textbox to set all variables to that one value. The same applies to adding and subtracting values.
:* The add and subtract buttons can be inverted by right clicking on them and choosing to invert.
:* You can click on the add/subtract button and hold the mouse down while holding control in order to continuously add to or subtract from the variables. Alternatively, right click on either button and choose to Start Continuous Add (or Subtract) and then later choose to Stop Continuous Add (or Subtract).
: You can create an Advanced Controller for a variable by clicking on the variable while holding C. Alternatively, you can create an Advanced Controller for multiple variables by selecting multiple variables, right clicking, and choosing to open a controller.

* '''Bit Controller''': A Bit Controller is in charge of manipulating one variable. It consists of the following controls:
** '''Name Textbox''': This shows the name of the variable being manipulated. Note that this can be edited.
** '''Decimal Value''': This shows the decimal value of the variable.
** '''Hex Value''': This shows the hex value of the variable.
** '''Binary Value''': This shows the binary value of the variable.
** '''Value Table''': This shows various representations of the bytes of the variable, including the decimal representation, hex representation, and binary representation. It also provides a set of checkboxes that can be used to toggle each bit of the variable. For floats, these checkboxes are colored according to the bits' role in the float, as blue represents sign, red represents exponent, and green represents mantissa.
: Note that for floats, you can right click on the empty space of the controller, and change what the textboxes display. Specifically, they can be set to display the sign, exponent, and mantissa values of the float. You can create a Bit Controller for a variable by clicking on the variable while holding B.

== Object Tab ==

== Mario Tab ==

== HUD Tab ==

== Camera Tab ==

== Triangles Tab ==

== Actions Tab ==

== File Tab ==

== Input Tab ==

== Water Tab ==

== Misc Tab ==

== M64 Tab ==

== Custom Tab ==

== TAS Tab ==

== Map Tab ==

== Options Tab ==

== Memory Tab ==

== PU Tab ==

== Area Tab ==

== Model Tab ==

== Gfx Tab ==

== Debug Tab ==

== Hacks Tab ==

== Cam Hack Tab ==

== Q Frames Tab ==

== Var Hack Tab ==

== Coin Tab ==

== Disassembly Tab ==

== Decompiler Tab ==

== Scripts Tab ==

== Testing Tab ==

== Painting Tab ==
[[Category:STROOP]]
[[Category:Resources]]

User talk:Aurumaker72

2020-05-21T15:17:19Z

Aurumaker72: discussion page

What is this discussion page what
I guess post stuff about me here(?)

Ukikipedia:Todo

2020-05-20T13:38:20Z

Aurumaker72: added my own suggestion

This is a TODO list, feel free to add things you feel are necessary to be added but make sure '''you add your name at the end of your edit statement'''.

* Add object lists for every course
* Create Navigation templates for objects, stars, tases, and similar pages
* Create pages for every object<small>---[[User:JoshDuMan|JoshDuMan]]</small>

Proper CSS to change some fonts (like the buttons for edit, history, and more) to be the Mario font and to make the wiki look more unique

Some of the SM64 Experts should make a list of possible states Mario can be in (with pictures).

Someone should make something like [[Template:Level courses]] for glitches, challenges and mechanics. Then we can put all those on the front page <small>---[[User:Thestickman391|Thestickman391]]</small>
:Hi, I tried my best on one for the challenges: [[Template:Challenges]] and [[Template:Glitches]] now <small>---[[User:Anderium|Anderium]]</small>

Video references sound like a concept worth looking into (mostly for explanatory and/or listing videos) <small>---[[User:Iwer Sonsch|Iwer Sonsch]]</small>

*Finish all the hyperspeed methods
*Create all wanted pages
*Finish all stubs
<small>---[[User:Sunky|SunkSimp]]</small>

*Elaborate on [[TASBot]] page
<small>---[[User:Barry|Barry]]</small>

A page for every action <small>---[[User:MMMMMMMMMMMMM|MMMMMMMMMMMMM]]</small>

Put everything into a category, for easy navigation <small>---[[User:Anderium|Anderium]]</small>

Add all information about the Super Mario Video Quiz(zes) ---[[User:Quate|Quate]]

There should be some way to separate JP/US/Shindou and singlestar/with 100c in TAS history and star infobox, also a better way to use references there - [[User:Galoomba|Galoomba]] ([[User talk:Galoomba|talk]]) 13:17, 26 March 2020 (UTC)

Fix dark mode inverting Ukikipedia logo colors and maybe another button placement for dark mode. <small>---[[User:Aurumaker72||Aurumaker72]]</small>

User:Aurumaker72

2020-05-20T13:36:36Z

Aurumaker72:

Hey, i'm auru. I make freeruns and tases

User:Aurumaker72

2020-05-20T13:36:07Z

Aurumaker72: Created page with "Hey, i'm."

Hey, i'm.

STROOP

2020-04-13T09:31:28Z

Aurumaker72: Informs that when clicking the loading menu, it shows a list of all hints