Closed kjbranch closed 4 months ago
I think I will do this differently going forward; almost all of the strats are trivial to think about, but they're occupying a lot of space. So I'm planning one PR for all the CF, one for leave/enter shinecharged, etc. so that it can be easier to review.
It's the
canShinespark
that I don't know if are covered because they don't have anoFlashSuit
.
When gaining a spikesuit, there's a shinespark that happens and you have the flash suit afterward, so I was thinking that a shinespark itself might not take away the flash suit. That was my thinking for not including noFlashSuit
on it. Though maybe there's something special going on here with spikesuit, and it could just be modeled by having the gainFlashSuit
come after that shinespark.
Either way, I think shinespark
requirements should never appear on their own; they should always be preceded by either a canShinecharge
, a useFlashSuit
, or some entrance condition that implies carrying in a shinecharge or shinespark. That's maybe something that would be worth adding as a test. And as long as that is true, I guess it would be redundant to include a noFlashSuit
into shinespark
because it should already be covered by the shinecharge or other preceding action?
I imagine there could be scenarios where you use the initial shinespark from a spikesuit to spark out a room while having the flash suit afterward. So by not including noFlashSuit
in shinespark
, those strats can be represented naturally with the current schema. Otherwise we would have to do something special to be able to represent them.
There are cases where you want to get a shinecharge without needing to spark, e.g. for the purposes of getting temporary blue while falling off a ledge, and this will cause a flash suit to be lost.
This is mostly just the easier strats which were easy to test. More will come later.