Why isnt Get Last Input Vector not being sent to host in gameplay ability?

[Samathan]

The player’s input vector is not replicated. It only exists on the client, so it can’t be retrieved on the server. There are three ways to handle this in GAS (listed from worst to best):

1. Use GetCurrentAcceleration instead. The movement system works by reading the player’s input vector (which tells them the direction the player wants to move) and applying acceleration in that direction, which is what actually gets replicated. If you normalize the player’s current 2D acceleration, you’ll likely get their input vector. However, this is more of a hack than a solution. If your game, for example, has any kind of knockback system, this code will break, since the player’s acceleration will instead be InputVector + CurrentKnockback.
2. Replicate InputVector. This is a pretty obvious solution. Just create a new replicated variable in your character class, and set it to LastControlInputVector every frame. This way, your input vector is available on the server. But this still isn’t the best option: if the server only needs to know the input vector when you activate this one ability, you’re wasting bandwidth by replicating it every single tick.
3. Fire an RPC in the ability. Since you only need to know the input vector when this ability is activated, you can just have the client tell the server what it is. Here’s what that looks like:
   
   
   
   
   On the client, this will grab the input vector, dash in the desired direction locally, and send an RPC to the server’s instance of this ability (assuming the execution policy is Local Predicted). On the server, it will wait for that RPC, then perform the same dash with authority using the received data. If this is executed on a listen server, it will skip over the RPC and just perform the dash using the local data, since it’s available. This is by far the best solution. Epic even does this themselves in the Lyra sample project.

Note that option 3 only works because root motion is locally predicted. If you were executing any kind of logic that isn’t locally predicted (basically anything besides the built-in GAS features), you’d need to hook into GAS’s prediction system to handle the client’s prediction. Otherwise, there might be synchronization issues (rubberbanding, missed predictions, etc.) caused by the delay between when the client executes the logic and when the server receives the RPC to do the same.