Model general stored vertical speed to be

[kjbranch]

Stored vertical speed is currently represented as 1 or 2 tiles of downward speed, but different amounts of speed can be important, as well as stored upward speed:

• Freefall clips may require specific ranges of non-integer fall speed
• Stored spring ball jumps and super jumps can store upward speed with a wide range of values
• Super sinks may also use this?

We need a way to comeInWithStoredVerticalSpeed and leaveWithStoredVerticalSpeed without having to specify each possible value -this is necessary to prevent having a dozen strats added in each direction while crossing a flat room. Some rooms will need specific stored speed values still, such as breaking a bomb wall with screw and grapple.

Much of the work for modeling uses of stored speed has been done, but the schema needs to be improved before they can be incorporated:
#2865

[blkerby]

I think super sinks would probably not share the same exit/entrance conditions, because

1. In a super sink state, you are forced to remain morphed, so you wouldn't be able to open doors (except I guess a PB door).
2. In a super sink, you uncontrollably continue to gain fall speed while on the ground. From the setup in Indiana Jones, you can generally only move a few tiles into the next room before you clip into the floor. Slopes and/or water physics can make it possible to delay it to some extent, but it's very limited.
3. there's essentially only one known cross-room setup for super sink, from Indiana Jones, and the existing schema currently seems able to model everything with it. If we had more setups then we'd have more need to distinguish them by how much speed or time remaining you have. I remember there being something crazy you could do from Everest down into Crab Shaft, to chain the super sink or something, but it seemed TAS only so probably not worth modeling?

[blkerby]

But yeah, in general for stored vertical speed (excluding super sink) I think it probably needs to be modeled in the randomizer as a new resource type, ideally probably using two dimensions to specify a min and max fall speed. So that has non-trivial performance implications, but we also want other similar things like cross-room horizontal momentum (for 3-room strats); we'll want to deal with it eventually. With the rework of obstacles planned for the randomizer, there will be a lot fewer vertices in the graph, so it can make it less of an issue to store more states (or richer states) at the vertices

[osse101]

From what I recall, there are extendedMoondance clips tested on the minimum 2-tile fall speed where you only need to do the moonfalls, but if you add more moonfalls it changes the stored speed value and becomes a freefallClip; or is uncertain. And you could be made to moonfall with screw to pass through dachora room or landing site.

Stored springball jumps can usually reduce your max height if needed with turnaround aim cancels, but you can't see your stored speed value normally. I looked at transitioning with forward momentum and you don't need many tiles in most cases and you either have runway or ice and springball in all cases. Temp blue to main street item is the main one that also had comeInShinecharging.

And super sink is limited enough that it shouldn't really be included.