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

[0th1ng1 (Thing)]

Im trying to create a dash ability that dashes character in direction of movement input.
when using Get last input vector like i did in the following image, i expected the vector would print out the string on server when triggered on the client… but it doesnt

can someone tell me why this is not server printing the vector but the client, even though the custom event jukejuke is run on server?

[Rev0verDrive]

Is Locally Controlled!

Is Locally Controlled

Server isn’t executing the logic, because “Authoritative and Simulated” proxies are not “Locally Controlled”.

[jongore]

First, check the replication settings of variables and functions involved, ensuring they are set to replicate to the server. Secondly, ensure that the dash ability is triggered only on the client that owns the character and validate it on the server to replicate the action to other clients. Properly handle input on the client and send it to the server for execution.

Add debugging information, such as printing the “Get Last Input Vector” value, to identify any transmission issues. Confirm the authority (client or server) when triggering the “jukejuke” event. Lastly, consider network conditions and latency as potential factors affecting replication and execution. By addressing these points, you can resolve the issue and ensure the dash ability works correctly on both the client and server sides.

[Ta_e]

500×500 2.84 KB

context: I was recreating a “dash” ability from Jett in Valorant. [image] This code is a directional dash ability based on last player input, if the last input is 0 then the character will automatically dash forward. Issue: when i check “use pawn controller yaw input” the value always returns 0. this issue only occurs when the player is a client not the server. when i check this off then the ability works just fine. i don’t understand where to look to resolve this issue. but since it is just…

Check this out

[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.