Crateria remote runway strats

[blkerby]

• Setups and applications of remote runways in Crateria
• One application in East Sand Hall
• Update comeInWithSpringBallBounce docs to clarify it can also match with leaveWithRunway
• New entrance condition comeInWithBlueSpringBallBounce (like comeInWithSpringBallJump but with blue speed).
• Add startingDownTiles in (remote) runway schema.

[blkerby]

I made a little table to help with measuring effective runway lengths: https://docs.google.com/spreadsheets/d/1b2hP3lt-AOWfas38jbwZ1ySehpKwSjDp7GmGBeUTYAg/edit?usp=sharing. These show the horizontal speed you get by running and jumping from a runway with one open end (closed at the beginning, open at the end) with a last-frame jump, and then performing other actions like aiming down, going into a mockball (or controlled bounce) or an airball (uncontrolled bounce). I didn't include the max run speed before the jump because you would only see that for 1 frame, making it less convenient to measure. All the columns of the table end up being related by adding/subtracting a constant; I did verify them all individually to be sure.

The idea is to use the "Horizontal Speed" Infohud mode in the Practice Hack and then convert the speed value into a runway length. The table only gives integer-valued runway lengths; this could be refined, but it's not clear yet if more precision would actually be needed for the applications. To be conservative, I've been rounding down the setup runway lengths and rounding up the applications.

For the mockball setups with little horizontal distance between the end of the remote runway and the start of the landing, there can be a trade-off between how much remote runway is used and how much of the landing is used. For mockballs, for now I've been using a small enough amount of runway that the full landing can be used (or enough of it to ensure a mockball reaches its max speed before the transition, in cases where this is possible). For uncontrolled spring ball bounces, I've been doing the opposite, using as much of the runway as possible, leaving just 1 tile of landing, since I'm not yet aware of applications where you would need more landing space. If it ends up mattering, we could refine this to give multiple possible combinations of lengths for these exit conditions, similar to what we did for the entrance conditions with remoteAndLandingMinTiles.

[blkerby]

• Added minExtraRunSpeed and maxExtraRunSpeed properties so that we can now properly express speed constraints in exit/entrance conditions. At least for now, this is only being applied to entrance conditions that involve blue speed, since without blue speed I think the existing method is still working fine, of using tile counts as a proxy for speed.
• Worked out docs/tables describing essentials of how run speed works and what ranges can be achieved with different combinations of runway lengths and short-charging techniques.
• Added a "speedBall" logical requirement, which can be used to represent in-room speedballs (instead of using "canShineCharge"); this makes it possible to properly account for the interaction between the two skills of short-charging and short-hop mockball. I'm planning on adding "short-hop mockball frames" as a new difficulty parameter in Map Rando.
• Updated the docs for "comeInSpeedballing" to describe how it gets resolved in the same way as "speedBall" on the combined runway. This should be quite a bit more accurate than what we were doing before here.

One thing that came up with the blue run speed table is that there are several types of actions which could be required after gaining blue speed, and I don't think we've yet worked out how to account for them completely accurately:

• running through speed blocks (e.g. like in PCJR)
• jumping before the end of the runway (e.g. to go into a speedball, spring ball bounce, blue space jump, etc.)
• gaining a shinecharge without falling off
• gaining a shinecharge while falling off

So that's stuff that should maybe be sorted out later as part of a larger issue. The blue speed run table that I made is based on an assumption of jumping before the end of the runway, but it assumes a last-frame jump, not directly accounting for lenience that should maybe be there. So it could probably be refined.

[blkerby]

The main hangup is that hex speed values are hard to parse. As a strat writer and someone reading the logic, you can't look at the strat and then execute it. It's looking up the table and doing hex math first.

I don't disagree, but for these strats that involve getting blue speed while also getting a certain amount of momentum, I don't really see a better alternative? A tile count also wouldn't tell you how to execute it and would seem even more unclear. At least with the speed values you have something to compare against, by using the Practice Hack Infohud to see if your speed is high or low. I wish the Infohud had a built-in mode to show the extra run speed; I normally use either the RAM Watch Infohud mode or a debugger to see it. Using hexadecimal here I think makes sense, because that is what you're going to see in the Infohud or a debugger; also it makes it so the subspeed can be represented with 1 digit whereas if we converted to decimal then it would need 4 digits. For testing strats that requiring coming in with blue speed, I usually make a save state in the transition and then use either a debugger or the Customize RAM Watch to write and test different speed values.

When I'm measuring remote runway lengths where you have to jump before a closed end, I'm looking at the extra run speed that I can get and then using the table to convert that to a tile length.

[osse101]

I think the main requirement is to be able to broadly tell if the strat is possible or not.
For a tricky dash jump, you tell someone to stand on a certain pixel.

To exit with some speed value, you point to a runway, and say you need at least some level of shortcharging. The tables may fill that role, and remote runways have a runway length listed. Knowing if a strat is in logic takes a table look up to find how much speed I can leave with at my skill. Hex values can be directly compared between entrance and exit conditions, and maybe that's trivial but its also more confusing to general readers.

I think the number of strats using a shortcharge and have limits on your speed are few and you could maybe ignore the problem for a while. Strats with a max/min speed are a little harder to read but not really that different.

And maintainers can work out a system for writing strats since I don't see a better way either.

[blkerby]

I think the main requirement is to be able to broadly tell if the strat is possible or not. For a tricky dash jump, you tell someone to stand on a certain pixel.

To exit with some speed value, you point to a runway, and say you need at least some level of shortcharging. The tables may fill that role, and remote runways have a runway length listed. Knowing if a strat is in logic takes a table look up to find how much speed I can leave with at my skill. Hex values can be directly compared between entrance and exit conditions, and maybe that's trivial but its also more confusing to general readers.

I think the number of strats using a shortcharge and have limits on your speed are few and you could maybe ignore the problem for a while. Strats with a max/min speed are a little harder to read but not really that different.

And maintainers can work out a system for writing strats since I don't see a better way either.

Yeah the logic for these strats is not going to be easy to interpret, as far as telling if something is in logic or not with a specific room configuration. I just don't see a way around it because it does depend on an interaction between the runway lengths and the shortcharging ability in a way that is fundamentally not straightforward. I think maybe the answer is that eventually we need to have "logic calculator" tools that could help players answer questions like this. There are other things like adding up heat frames across a room path (to find total energy needed) that are more conceptually simple but in practice also not easy for players to do.

[blkerby]

By the way, I also added a couple more columns to the run speed table, to show the initial vertical speeds for jumping (with/without HiJump), since that's something that's fairly important for tricky dash jumps. I never realized before that it's only 2-frame windows to get the extra tricky dash jump height without HiJump.