Example applications that we may want to be able to model:
Running or jumping through a door (horizontal or vertical) with a shinecharge:
Entering bottom-right of Colosseum with a cross-room jump and shinecharge, to spark left across the room.
Entering right of Aqueduct with a cross-room jump and shinecharge, to spark up to collect the items.
Entering bottom right of Everest with a wall jump and then sparking to the top right.
Grapple teleport with a shinecharge
Mockballing, Spring Ball bouncing, or Space Jumping through a door with a shinecharge
There are at least a couple options for how we could go about this:
Allow "comeInShinecharged" entrance condition to be combined with certain other conditions like "comeInJumping".
Use a specialized combined condition like "comeInShinechargedJumping".
Option 2 could be simpler for randomizers (and other clients) to deal with, by keeping the structure of exit/entrance conditions more rigid (i.e. at most one entrance/exit condition per strat), but it's also less flexible, meaning we'd need to create a new pair of conditions for every combination that we want to consider, e.g. "comeInShinechargedWithGrappleTeleport". It's maybe fine if it's only a handful of new conditions, but if we end up combining it with basically every other condition then that's maybe a sign that they should be separated out. In the game physics, holding a shinecharge is independent of other properties such as Samus' position and momentum in the door, which is an argument in favor of separating them out, i.e. allowing "comeInShinecharged"/"leaveShinecharged" to combine broadly with other conditions.
Either way, it requires new strats and new matching rules to be able to support this. We did already create a "comeInShinechargedJumping" entrance condition, but it would need an additional property or two to be able to represent the required run speed. And then we need a way to make it match with "leaveWithRunway". Probably we also want to add runway lengths to "leaveShinecharged" conditions so that it can match with those as well. The runway exit conditions can get tricky to model, because there is a bit of a complicated trade-off between run speed vs. shinecharge frames remaining; you can gain the shinecharge by running either toward or away from the door, and stop to gain the shinecharge at different possible distances from the door. Shortcharge skill also comes into play in constraining where you could get the shinecharge. Fortunately that stuff is mostly just math which can be worked out one time, documented, and then automatically applied everywhere.
With remote runways things can get more complicated. The amount of shinecharge frames remaining through the transition depends on both the remaining amount of remote runway used after gaining the shinecharge (which determines the run speed) as well as the distance to travel after jumping from the remote runway before reaching the door; again you can gain the shinecharge by running either toward or away from the door. It can also depend on how much time is spent spinning vs. other poses such as controlled or uncontrolled bounce (which have different horizontal speeds). The amount of scenarios where you can use a remote runway and reach the door with a useful amount of frames remaining is maybe limited though; probably the bulk of applications would be covered by leaveWithRunway or leaveShinecharged already. So it might not be important to support, given amount of complexity it would require. On the other hand, timing information about remote runway strats (along with all other strats) can be useful for other purposes, e.g. in heated rooms (or rooms that we might want to convert to become heated) or for escape timings. So it could be worth thinking more about someday, if there could be some reasonable way to model it that doesn't blow up the amount of work required.
Likewise, grapple teleporting with a shinecharge would require a fair bit of complexity and extra work to model, for something that is rarely applicable and possibly "not fun" to do.
Example applications that we may want to be able to model:
There are at least a couple options for how we could go about this:
Option 2 could be simpler for randomizers (and other clients) to deal with, by keeping the structure of exit/entrance conditions more rigid (i.e. at most one entrance/exit condition per strat), but it's also less flexible, meaning we'd need to create a new pair of conditions for every combination that we want to consider, e.g. "comeInShinechargedWithGrappleTeleport". It's maybe fine if it's only a handful of new conditions, but if we end up combining it with basically every other condition then that's maybe a sign that they should be separated out. In the game physics, holding a shinecharge is independent of other properties such as Samus' position and momentum in the door, which is an argument in favor of separating them out, i.e. allowing "comeInShinecharged"/"leaveShinecharged" to combine broadly with other conditions.
Either way, it requires new strats and new matching rules to be able to support this. We did already create a "comeInShinechargedJumping" entrance condition, but it would need an additional property or two to be able to represent the required run speed. And then we need a way to make it match with "leaveWithRunway". Probably we also want to add runway lengths to "leaveShinecharged" conditions so that it can match with those as well. The runway exit conditions can get tricky to model, because there is a bit of a complicated trade-off between run speed vs. shinecharge frames remaining; you can gain the shinecharge by running either toward or away from the door, and stop to gain the shinecharge at different possible distances from the door. Shortcharge skill also comes into play in constraining where you could get the shinecharge. Fortunately that stuff is mostly just math which can be worked out one time, documented, and then automatically applied everywhere.
With remote runways things can get more complicated. The amount of shinecharge frames remaining through the transition depends on both the remaining amount of remote runway used after gaining the shinecharge (which determines the run speed) as well as the distance to travel after jumping from the remote runway before reaching the door; again you can gain the shinecharge by running either toward or away from the door. It can also depend on how much time is spent spinning vs. other poses such as controlled or uncontrolled bounce (which have different horizontal speeds). The amount of scenarios where you can use a remote runway and reach the door with a useful amount of frames remaining is maybe limited though; probably the bulk of applications would be covered by leaveWithRunway or leaveShinecharged already. So it might not be important to support, given amount of complexity it would require. On the other hand, timing information about remote runway strats (along with all other strats) can be useful for other purposes, e.g. in heated rooms (or rooms that we might want to convert to become heated) or for escape timings. So it could be worth thinking more about someday, if there could be some reasonable way to model it that doesn't blow up the amount of work required.
Likewise, grapple teleporting with a shinecharge would require a fair bit of complexity and extra work to model, for something that is rarely applicable and possibly "not fun" to do.