Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix regression: Escape from conveyor spikes #1178

Merged
merged 1 commit into from
Aug 1, 2024

Conversation

InfoTeddy
Copy link
Collaborator

@InfoTeddy InfoTeddy commented Jun 27, 2024

This fixes a regression from 2.3. Consider the following diagram:

   CC
X  CC
  <<<<

"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:

  CC
X CC
 <<<<

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...

  • My changes may be used in a future commercial release of VVVVVV
  • I will be credited in a 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

This fixes a regression from 2.3. Consider the following diagram:

       CC
    X  CC
      <<<<

"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:

      CC
    X CC
     <<<<

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 TerryCavanagh#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.
@InfoTeddy InfoTeddy merged commit 345eca5 into TerryCavanagh:master Aug 1, 2024
3 checks passed
@InfoTeddy InfoTeddy deleted the general-bug-fixes branch August 1, 2024 05:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant