Fix regression: Escape from conveyor spikes #1178
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes a regression from 2.3. Consider the following diagram:
"C" indicates one tile of a checkpoint entity, "X" indicates a spike tile, and "<" indicates one tile of a conveyor entity that has the default speed (4 pixels per frame) going leftwards.
Now consider if the player were to touch the checkpoint and die. In 2.2, they would be able to escape from the spike by holding right. But in 2.3, they would not be able to, and would die from the spike continuously with no escape.
This happens because in 2.2, the player would spawn a couple pixels off the surface, and this gained them an extra frame of movement to move away from the conveyor. 2.3 places the player directly on the ground, moving them one frame earlier and thus forcing them to their doom.
Now consider the following diagram:
The difference with the previous diagram is that this time, the spike is one tile closer. This time, there is no escape in 2.2 and you will always die no matter what.
By the way, both diagrams have the same behavior if the conveyor is rightwards and if everything is flipped upside-down. Thankfully, it doesn't seem to be direction-dependent.
The reason 2.3 lowered the player onto the surface was for consistency (see PR #502), and I don't want to undo that. So I think the best solution here is to re-add the extra frame of control by conveyors only moving the player after lifeseq has advanced enough.
Legal Stuff:
By submitting this pull request, I confirm that...
CONTRIBUTORS
file and the "GitHub Friends"section of the credits for all of said releases, but will NOT be compensated
for these changes unless there is a prior written agreement