[Gingerbeard5773]

Type of change

• Bug fix
• New feature

Description

This is a rewrite of meteor's rotation manager. But the rewrite is secondary, as the main purpose of the PR is to implement Grіm MoveFix, which meteor has been missing for years.

'MoveFix' is referring to necessary player input corrections in order for Rotations to work fully on Grіm servers. Without it, modules that depend on rotation will be severely limited or cease to function.

This PR fixes this major problem.

Changes

• Adds a new config setting Rotation Movement Correction which is used to toggle movefix on/off.
• Fixed kill aura applying rotations incorrectly.

Yapping about technical stuff (edit: no longer relevant)

A new TickEvent.Rotate is added in this PR. This is kind of a strange feature for developers, but it was somewhat necessary in order for there to be a seamless way for modules to synchronize to rotations easier. Movefix messes with ordering heavily, which is why this TickEvent has been added in order to navigate those timings better and easier. If there is a better solution, I would like to see it.

Why it matters:
Meteor has been suffering from a bug that affects every module that uses rotations.
What happens when a module puts out a rotation?
The calculation by the module and the rotation are desynchronized. Because of this, the information in the rotation can get outdated by the time the Rotation does its function callback.
Heres a real example of how this happens chronologically using meteor's existing kill aura :

1. Kill aura calculates a rotation to hit a target. A rotation is sent out holding an 'attack' callback.
2. The player moves 1 tick worth in the middle of the tick.
3. The rotation is called and executed right after the player moves. Problem is: The rotation was for an outdated player's position, so the end result's rotation may be facing off from the intended target. For servers with strict AC, this causes a miss. This is why kill aura does not hit anything when you are moving too fast (flying etc).

The good news is that this can be fixed. A module's calculations just have to come after the player moves in the tick. The bad news is that it cannot be fixed if the player has to use movefix. So a compromise has been made.
By using TickEvent.Rotate instead of TickEvent.Pre, modules can automatically set the right timings to their module- depending on if the player is using movefix or not.

If none of that made sense, just copy and paste it into an LLM and let it explain better than I can for you 💀

EDIT: THIS IS NO LONGER RELEVANT IN THIS PR AS OF NOV 8, 2026.
I have elected to remove TickEvent.Rotate from this PR in order to keep things simple. If it should be readded, it will be done so in a future pr.

Related issues

closes #4858
closes #3565

How Has This Been Tested?

Heres a basic showcase of the changes from this PR.
In the video, I show what it looks like when a player attempts to use rotations on a server running Grіm AC. There is rubberbanding. Enabling movefix removes the rubberbanding and stops the flags.

2026-11-06.23-00-23.mp4

Video filmed on Constantiam.net.

Checklist:

• My code follows the style guidelines of this project.
• I have added comments to my code in more complex areas.
• I have tested the code in both development and production environments.