I don't know what your network code looks like, but assuming you use something like a traditional "command" model, the best solution I know if is to have your "play ability X" command carry the state necessary to sync up the presentation of the relevant actor.

That's a mouthful, so here's a concrete example:

• You have an ability "lunge" which starts with a rapid forward movement and then ends with a damage-dealing blast.
• Player One is at position x0,y0,z0 at frame N
• Player One sends an input packet from their PC to the server stating they wish to use the lunge
• Server validates the ability as normal (e.g. is it off cooldown, whatever)
• Assuming the input is valid, the server issues a command packet back to all the relevant players
• The command contains the actual ability (lunge), combined with any position, velocity, acceleration, etc. necessary to describe the server's perspective of where Player One was at the time of frame N
• Other players apply latency compensation as desired
• Player Two's machine will now interpolate from "Player Two's idea of where One is at" -> "Server authoritative state of One" over suitable number of frames

Note that some parts of this may vary depending on your netcode, your simulation model, and your desired tradeoffs (e.g. is it ok to trade accurate positions for faster response times? etc.)

First, make sure your simulation runs at a fixed step rate (whatever -- 30 Hz, 60 Hz, 120 Hz, 1000 Hz, ...)

You can run graphics asynchronously from physics -- check out the canonical game loop for one way of doing that. (On the server, there's no graphics, but time still needs to advance using a real clock.)

Then, timestamp both movement, and action commands, using "this takes effect at physics step X."

Then, you should be able to make positions and actions sync up, because you can play actions and positions back at the same timestep. Now, whether that timestep is the "global" time step X, or the "local" time step X for the viewer, or some time step X+Q where the lag from sender to receiver is Q, depends on the specifics of your networking and simulation models.