Blue suit schema and examples

[blkerby]

This sets up the schema for modeling blue suit and include examples of setups, applications, and carrying blue suit in 3 rooms.

New logical requirements:

• gainBlueSuit: Represents that a blue suit is gained. This should normally be used inside of a tech or helper, not directly.
• haveBlueSuit: Represents that a blue suit is needed (but not consumed). This is used in applications, for passing through or destroying bomb blocks, Speed blocks, and/or enemies.
• blueSuitShinecharge: Represents that a blue suit is used to gain a shinecharge. It then becomes consumed in the shinespark requirement that should always follow. This is used in applications, including implicitly in strats with a comeInShinecharged or comeInWithSpark entrance condition. We will probably want to create a helper around this to handle cases where using a stored shinespark will work wth either a flash suit or blue suit, which I imagine will be quite common.
• noBlueSuit: Represents that the strat cannot be performed while carrying a blue suit. This is mainly used in tech (most notably canDash) but can also be used directly in strats where needed. It also implicitly occurs as a requirement of many entrance/exit conditions that involve crossing the room with momentum.

New strat property:

• blueSuitChecked: This is a boolean indicating if the strat has been checked for logical soundness with respect to carrying a blue suit. If false or not present, then the strat implicitly has a {"noBlueSuit": {}} requirement appended.

New tech:

• canCarryBlueSuit: The base tech for being able to carry a blue suit around. I'm not sure if this would be Expert or Extreme. Carrying around blue suit is easier than flash suit in that there's not much risk of accidentally losing it; on the other hand it's slower. Overall probably fine though for Expert ?
• canDash: This will be the most common reason that a blue suit cannot be carried. By having its own tech (rather than using {"noBlueSuit": {}} directly, we make the logic extensible to handle other situations where you may not be able to dash (e.g. in case the dash ability becomes gated by an item). I expect this will be an Implicit-level tech.
• canSpeedyJump: This is a lower-level analogue of canTrickyDashJump, requiring both Speed Booster and the ability to dash in order to jump higher. I'm imagining this will be a Medium-level tech.
• canRModeSparkInterrupt: Interrupting a shinespark wind-up with an R-mode forced standup, which is a broadly applicable ways of gaining a blue suit. I'm imagining this will be Expert (assuming canCarryBlueSuit is) and that we will also move down canRMode to Expert as a result.
• canCrystalSpark: Interrupting a shinespark wind-up with a Crystal Flash, another broadly applicable way of gaining a blue suit. I'm imagining this will be Expert, with extra Power Bomb lenience.
• canBlueSuitGModeSetup: Getting a G-mode setup while carrying a blue suit, by positioning 1 pixel from the door. Using X-ray to buffer the positioning makes this not too bad. I'm imagining this will be Extreme.

Room examples (including setups, applications, and carrying):

• Final Missile Bombway
• Rising Tide
• Spore Spawn Farming Room

I think that the schema that we set up for flash suits has been successful, so I'm trying to follow the same pattern for blue suits here. The biggest challenge will be in heated rooms, because there the requirement of not being able to dash is fairly disruptive in how it affects heat frames. There are two problems that I am trying to minimize: 1) cluttering up basic strats with requirements related to dashless/blue-suit traversal, 2) excessive duplication of whole strats with dashless/blue-suit versions where the bulk of the requirements and notes would be redundant. There's some tension between these two things, so my goal is to try to strike a good balance to keep things overall as clean, understandable, and maintainable as possible. Some of the strategies for achieving this include

• As much as possible, include requirements like canDash inside of dependent tech and as part of entrance/exit conditions, to minimize the need to clutter up individual strats; this also reduces the potential for error by forgetting such requirements.
• If a strat has complex requirements and the blue suit or inability to dash interacts significantly with them (e.g. rendering some requirements irrelevant, or necessitating additional requirements) then it's probably better to just have a separate dashless/blue-suit strat rather than making the existing strat's requirements much more complex.
• If a strat has complex requirements and the blue suit or inability to dash has minimal interaction with them (e.g. just adding some frames at the beginning or end) then it's probably better to just include an adjustment like{"or": [canDash, {"heatFrames": 60}]} rather than duplicating the entire strat. This can especially make sense for high-level strats where the cost to interpretability of including an extra requirement may be more tolerable than further proliferating the already-large amount of strats.
• If a strat has simple requirements (e.g. representing a "Base" traversal of the room), I'm not sure which is better, but I lean toward creating a separate strat, just to keep the basic strats cleaner. There's not really too many of these strats, and since they are simple and don't usually have notes attached, the cost of making a separate strat is not high, in that it's not really creating much duplication.

Overall I was fairly happy with how things turned out in Rising Tide. It turned out that most strats either didn't require dash or already implicitly required it due to entrance/exit conditions. And it wasn't too bad working out dashless/blue-suit versions of the strats that needed them. The Crystal Spark strats are going to be kind of everywhere, but they're fairly trivial to add.

I think at some point it would make sense to add a dashless strat property to mark strats that are only useful in a dashless context (including if carrying a blue suit); it's a similar idea to wallJumpAvoid, allowing the logic pages to filter out the dashless strats unless playing on a difficulty that includes canCarryBlueSuit or unless having opted in by selecting a "Show dashless strats" setting or something along those lines. But because this isn't an essential part of the new schema, I left it out for now.

Something that I'm treating as out-of-scope for a first pass is converting between flash suit and blue suit: e.g. with a flash suit you can do a Crystal Spark basically anywhere without needing a runway. These won't be that hard to add, and it might be easier later if we add support for treating entrance conditions like logical requirements (e.g. allowing a comeInShinecharging to go into an or with useFlashSuit). For now, I don't think they would be impactful enough to worry about, as they would just create a bit of a distraction.

[osse101]

Rising Tide 8, 37, 9 Missing blueSuitChecked

It looks like a good system. canDash and using entranceConditions takes care of a large bulk of strats. And the remainder are reviewed similarly to how we did with flashSuitChecked.

[osse101]

While morphed you still get boosted. So it may be more commonly applicable than not.

[blkerby]

Right, looks like it's dependent on being in a "falling state", e.g. after a mid-air morph. If you are in a jumping state like after using Spring Ball (either mid-air or from the ground) then there's no boost. I'm thinking maybe it's safer to keep the {"noBlueSuit": {}} on the tech and then we can make a helper (or helpers) to override the requirement for cases that work?

[osse101]

Leaving {"noBlueSuit": {}} here feels safer initially while checkingBlueSuits and clearer when there is a difference in the strat.