You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The order in which shinespark requirements appear in relation to other energy requirements (for example heatFrames) can affect how the logic works. If a shinespark requirement is placed later than it actually occurs, then it can result in logic that is more lenient/conservative than it has to be, since it increases the possibility of hitting 29 energy and hence not being able to satisfy the shinespark requirement. On the other hand, with excessFrames it can also go the other way around. The ideal would be if we could put the requirements in chronological order of what happens in the strat.
The situations most likely to have problems is shinesparks in heated rooms. There are a number of heated rooms where the heat frames before and after the spark should possibly be split apart from each other in order to make the logic fully accurate. If the endpoint of the shinespark is in a part of the room that requires more than 29 energy afterward to reach safety (i.e., a door, a farm, or an item which could possibly be an ETank) then probably none of this matters. But if the endpoint is within 29 energy of reaching safety then it can make a difference.
The text was updated successfully, but these errors were encountered:
Here's what I think the new grouping would look like:
heatFrames used while shinesparking {shinespark: frames, excess} heatFrames used in crash animation and when running to next node
Most of the time excess is under 10 frames. And we can try to ignore the extra run distance on heatFrame count. But LN pillar room has some long ExcessShinesparkFrame counts. So it may need an additional {"or": shinespark, heatFrames} to cover running to the door after stopping early.
With the complexity of excess frames, heat frames, and the possibility of adding energy free shinesparks, would it make more sense to add a heated shinespark option?
Should cover most of the cases. Maybe we need to think about how to divide the heat frames. More initial heatFrames would trigger the excessFrames so you need to be sure that the secondary heatframes is a proper number for reaching the door.
The order in which shinespark requirements appear in relation to other energy requirements (for example heatFrames) can affect how the logic works. If a shinespark requirement is placed later than it actually occurs, then it can result in logic that is more lenient/conservative than it has to be, since it increases the possibility of hitting 29 energy and hence not being able to satisfy the shinespark requirement. On the other hand, with excessFrames it can also go the other way around. The ideal would be if we could put the requirements in chronological order of what happens in the strat.
The situations most likely to have problems is shinesparks in heated rooms. There are a number of heated rooms where the heat frames before and after the spark should possibly be split apart from each other in order to make the logic fully accurate. If the endpoint of the shinespark is in a part of the room that requires more than 29 energy afterward to reach safety (i.e., a door, a farm, or an item which could possibly be an ETank) then probably none of this matters. But if the endpoint is within 29 energy of reaching safety then it can make a difference.
The text was updated successfully, but these errors were encountered: