Summary
“[…] By using this structure, you will be guaranteed that the Server has the desired RPC data prior to calling the Gameplay Ability’s activation function.”
Sounds great on paper, but the opposite actually happens. You only get the target data AFTER the activation of the ability. Why? Because when the destructor of the scoped RPC gets called and performs the batching + RPC to the server, the ability activation happens FIRST and the setting of the target data sent from client happens SECOND. Just simply changing the order of the execution isn’t gonna help in this case because the [ServerTryActivateAbility] function actually consumes the client target data prior to activating the ability on the server.
Please select what you are reporting on:
Creative
What Type of Bug are you experiencing?
Documentation
Steps to Reproduce
- In your UAbilitySystemComponent-derived class, override ShouldDoServerAbilityRPCBatch to return true.
- In native code, Create an FScopedServerAbilityRPCBatcher on the stack.
- Activate your Ability through your desired function (e.g. TryActivateAbility).
- During the initial Activation of your ability, perform any CallServerSetReplicatedTargetData call.
- When the destructor of the FScopedServerAbilityRPCBatcher executes (by going out of scope), it will call a batched RPC that contains both the Activation and the ReplicatedTargetData.
Expected Result
To have client target data on server side ability before activation time.
Observed Result
Server ability does not yet have the client target data before activation time.
Platform(s)
Windows