Skip to content

Fix loops so that they are omnidirectional

Summary

This MR fixes loops so that they can be built and function on all directions, both cardinals and intercardinals.

Explanation

Loops weren't working correctly in all directions because of two bugs:

  • origin_shift.x and y would have an enormous offset on various circumstances, like on 90º to 270º loops.
    • I could not fix the underlying issue behind with incercept function, but I worked around it by giving the player a small offset towards their direction. The intention of intercept was to give a small offset to the player anyway based on their momentum, so this should work about the same.
  • X coordinate calculations during P_PlayerOrbit would use FSIN.
    • This was fixed so they use FCOS. Y coordinates still use FSIN with a negative 90º offset.

Because of underlying calculation changes, there will be a small change in results when the player is put on the same situation between 2.3 and this MR. While it's mostly imperceptible (single digit fracunits), it could affect dev ghosts in-dev, if any. This can be tested in Test Run and running this command devmode 1; teleport 2300 390 0; angle 0; give sneaker, then using the Sneaker.

Picture shows left as MR results, and right as 2.3 results. ringracers_exposeLoopVars_jDEYV74JZQ

Nevertheless, functioning loops in any direction is good addition to the game, and I hope the small change in results doesn't discourage it being merged into the game.

Testing

Demonstration:

ringracers0650

I made a testing level, JUG_LOOPTEST.pk3, that has loop entrances in 0º, 45º, 90º, 135º, 180º, 225º, 270º and 315º degrees. All but the horizontal loop entrances would break in 2.3, but work instead in this version. The test level can be accessed by map JUG_LOOPTEST -force -match in the developer console or found in Lost & Found.

Changelog

  • Fixed loops so that they function in all directions, not just from 0º to 180º and viceversa.

Merge request reports

Loading