This lays down the schema support needed to encode flash suit logic, along with some examples:
New logical requirements gainFlashSuit, useFlashSuit, and noFlashSuit for describing how to obtain, apply, and carry around (or rather, not be able to carry around) a flash suit, respectively.
New logical requirement getBlueSpeed, similar to canShineCharge but without the shinecharge. This is an important distinction since a shinecharge will cause a flash suit to be lost while blue speed won't. In the future, these could also possibly have slightly different shortcharge difficulty requirements from each other, since the crouching animation to gain a shinecharge may require a little more space than just getting blue speed.
Similarly, a new entrance condition comeInGettingBlueSpeed similar to comeInShinecharging.
A new tech canSpikesuit.
A new strat property flashSuitChecked, to help us (and the randomizer) keep track of which strats have been checked for logical soundness, as far as their requirements for carrying around a flash suit.
A new helper h_canMidAirShootUp. Just one example application is included. Other applications and more helpers like this will be needed later.
noFlashSuit requirements added to tech/helpers that imply doing actions incompatible with preserving a flash suit. Some of these may end up having exceptions, which we could deal with later.
The idea is that adding flash suit logic will be a long-term project, but thanks to the property flashSuitChecked it can start safely being used before it is complete. @kjbranch is planning on starting to go through room-by-room and check strats one-by-one. In the near term, I plan to treat canSpikesuit as an ignored tech in Map Rando, until there are enough strats in logic that it would have a significant chance of being used.
Ceiling clips are an example where we'll need to be careful. In most cases they seem incompatible with preserving a flash suit. The only exception I'm aware of is the type of clip used with Mochtroids in Botwoon Hallway, where the enemy must be in a pixel-perfect very high position (compared to other ice clip setups), you jump + aim-down to get on it, and then stand with up or forward; angle-down jump can then clip through. I think we'll want to define a helper specifically for that type of ice clip, as it can be applied in many places but is more difficult than clipping either with X-Ray or a regular canPreciseCeilingClip (with the exception of Botwoon Hallway where the setup happens to be trivial).
If I remember, there is some way to do gate glitching while preserving a flash suit, but I assume this will need a new tech, and this could be handled later, so I put {"noFlashSuit": {}} on it for now.
Gate glitching with flash suit would most easily be done with springball. Jump to the ceiling and unmorph, then the shot isn't too different on the way down. Without springball, you do a super hard jump morph.
This lays down the schema support needed to encode flash suit logic, along with some examples:
gainFlashSuit
,useFlashSuit
, andnoFlashSuit
for describing how to obtain, apply, and carry around (or rather, not be able to carry around) a flash suit, respectively.getBlueSpeed
, similar tocanShineCharge
but without the shinecharge. This is an important distinction since a shinecharge will cause a flash suit to be lost while blue speed won't. In the future, these could also possibly have slightly different shortcharge difficulty requirements from each other, since the crouching animation to gain a shinecharge may require a little more space than just getting blue speed.comeInGettingBlueSpeed
similar tocomeInShinecharging
.canSpikesuit
.flashSuitChecked
, to help us (and the randomizer) keep track of which strats have been checked for logical soundness, as far as their requirements for carrying around a flash suit.h_canMidAirShootUp
. Just one example application is included. Other applications and more helpers like this will be needed later.noFlashSuit
requirements added to tech/helpers that imply doing actions incompatible with preserving a flash suit. Some of these may end up having exceptions, which we could deal with later.The idea is that adding flash suit logic will be a long-term project, but thanks to the property
flashSuitChecked
it can start safely being used before it is complete. @kjbranch is planning on starting to go through room-by-room and check strats one-by-one. In the near term, I plan to treatcanSpikesuit
as an ignored tech in Map Rando, until there are enough strats in logic that it would have a significant chance of being used.Ceiling clips are an example where we'll need to be careful. In most cases they seem incompatible with preserving a flash suit. The only exception I'm aware of is the type of clip used with Mochtroids in Botwoon Hallway, where the enemy must be in a pixel-perfect very high position (compared to other ice clip setups), you jump + aim-down to get on it, and then stand with up or forward; angle-down jump can then clip through. I think we'll want to define a helper specifically for that type of ice clip, as it can be applied in many places but is more difficult than clipping either with X-Ray or a regular
canPreciseCeilingClip
(with the exception of Botwoon Hallway where the setup happens to be trivial).If I remember, there is some way to do gate glitching while preserving a flash suit, but I assume this will need a new tech, and this could be handled later, so I put
{"noFlashSuit": {}}
on it for now.