Helpers for more refined separation of Speed Booster effects

[blkerby]

This introduces two new helpers h_speedJump and h_blueJump for using Speed Booster to jump with high horizontal speed or with blue speed, respectively. These will be useful in Map Rando in order to support the upcoming "Split Speed Booster" feature: the abilities represented by these helpers will be possible with "Blue Booster" but not "Spark Booster".

This PR includes example uses of the helpers. To implement them fully, we'll need to make a full pass through the logic to check all occurrences of the following (at least):

• h_speedDash
• getBlueSpeed
• comeInRunning cases with "speedBooster": true
• comeInGettingBlueSpeed

Closely related, the tech canSpeedyJump is for cases that use Speed Booster to modify Samus' jump height; for now, we're not interested in trying to separate out which instances of canSpeedyJump also rely on high horizontal speed. So canSpeedyJump uses can remain how they are.

I added uses of the new helpers to the tech requirements where applicable. A test is used to validate that blue speed is gained (e.g. with getBlueSpeed) before a h_blueJump requirement. A similar test is added for "canBlueSpaceJump" as well, and the tech is updated to remove its redundant requirements. To satisfy the test, this meant that uses of "canBlueSpaceJump" had to be moved to follow rather than precede getBlueSpeed; this uncovered a couple errors in East Ocean which are fixed here. A similar cleanup could be done for "canSlowShortCharge" -- saving that for later to avoid cluttering up this PR too much.

[kjbranch]

this puts a speedbooster requirement on mockball

[blkerby]

Good catch. Yeah it's easy to forget that "h_speedJump" is only for jumps with Speed Booster speed (greater than $2.0 dash speed). For regular dash speed, we're not currently interested in modeling whether or not you have to jump while maintaining it.

[kjbranch]

Looking at the commits one at a time was very helpful here.

[osse101]

Now there is no Speedbooster requirement?
Is this a BlueSpeedbooster action?

[kjbranch]

This is because there is supposed to be a "getBlueSpeed" or "canShinecharge" before uses of it, which he said is checked by the tests, so it shouldnt be too risky.

[osse101]

Ah I see. I would like a devNote saying the requirements are enforced by tests.

1. This diverges from the use of techs and looks more fragile
2. The item requirement is no longer here grouped in the data making it harder to list tech requirements in the logic page.

[kjbranch]

This is because there is supposed to be a "getBlueSpeed" or "canShinecharge" before uses of it, which he said is checked by the tests, so it shouldnt be too risky.

[kjbranch]

• h_speedDash
• getBlueSpeed
• comeInRunning cases with "speedBooster": true
• comeInGettingBlueSpeed

• comeInJumping and check all other entrance conditions with "speedBooster": true
• any strat with a shinespark, especially ones that rely on HiJump (most others will not use 7+ tiles of run speed to take benefit from speedbooster)

[osse101]

There is a lot of language that is unclear about if there is a division on or any changes to run speed acceleration and speed cap, here and in the Map Rando feature explination.

I still prefer if canTemporaryBlue has a SpeedBooster requirement. Almost every situation will be initiated with a dash too.

[blkerby]

There is a lot of language that is unclear about if there is a division on or any changes to run speed acceleration and speed cap, here and in the Map Rando feature explination.

With either Blue Booster or Spark Booster, the acceleration and cap would be the same as Speed Booster. It's only that with Spark Booster the dash speed gets capped to $2.0 if you jump or run off a ledge, the same cap as dashing without Speed Booster.

I still prefer if canTemporaryBlue has a SpeedBooster requirement. Almost every situation will be initiated with a dash too.

It will always need a dash, the requirement was only removed because of the redundancy with the getBlueSpeed, canShineCharge, etc. But there's no real harm in keeping it there if there's a concern about it; so I put the canDash and SpeedBooster requirements back on it now.