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
Originally goBack looked at which way a Character was facing and simply had them move in the opposite direction. With the addition of diagonal movement this became insufficient.
goBack currently only permits one "step" in that it moves the Character back to its last known position, regardless of what might now be there.
If instead the Character stored its last known delta, goBack could be called several times to move the character "further" back. Hit checking could also be re-added to this behaviour.
As it stands goBack's desired use only really requires one "step", as it's intended to get a Character out of a hitbox it just entered. If we wanted to also perform hit checking to ensure they're not now moving into an invalid location (highly recommended if it will be called multiple times), we would have to store the "raw" pre-motionMapping delta, or perform an inverseMotionMapping to the delta they stored so that when the motionMap was factored in they actually end up where they were.
The text was updated successfully, but these errors were encountered:
Originally goBack looked at which way a Character was facing and simply had them move in the opposite direction. With the addition of diagonal movement this became insufficient.
goBack currently only permits one "step" in that it moves the Character back to its last known position, regardless of what might now be there.
If instead the Character stored its last known delta, goBack could be called several times to move the character "further" back. Hit checking could also be re-added to this behaviour.
As it stands goBack's desired use only really requires one "step", as it's intended to get a Character out of a hitbox it just entered. If we wanted to also perform hit checking to ensure they're not now moving into an invalid location (highly recommended if it will be called multiple times), we would have to store the "raw" pre-motionMapping delta, or perform an inverseMotionMapping to the delta they stored so that when the motionMap was factored in they actually end up where they were.
The text was updated successfully, but these errors were encountered: