Welcome back.
Now we've created our own ability task, and that task is capable of finding the hit results under the
cursor.
But we've quickly discovered a limitation of that because we're only doing this locally, there's no
way that the server can know what that location is when the client clicks for reasons like this.
Gas has a built in mechanism for sending target data to and from the server.
Now, let's say on the client, we have an ability and it's executing an ability task.
So it's activate function has been called.
Now this means that the activate function is going to be called on the server at some point later in
time.
We'll call the amount of time that it takes for the server's ability task to activate Epsilon.
This represents the amount of time that the data travels across the network.
Now we need our data to reach the server and we know that when our ability task activates, then the
ability task will automatically be activated on the server as soon as the server knows about it.
But as soon as we activate our task, we want to get some data, a vector representing a location in
the world and we want to send it to the server.
So the only way that we really know how to send things to the server is through Rpcs.
We make a server RPC, we send the data up to the server and after some amount of time we'll call it
Delta.
The server receives that RPC and thus receives the data.
Now the question is which gets there first?
Does the server version of the ability task have its activate function called first before that RPC
reaches the server?
Or does the RPC get there first?
In other words, is Epsilon less than Delta?
If the amount of time that it takes for Activate to be called on the server is less than the amount
of time it takes for the RPC to get there, then on the server activate will be called and the server
will not have any valid data.
Now on the other hand, if Delta is less than epsilon, in other words the RPC reaches the server first,
then the RPC will be implemented on the server and the server will get the valid data, after which
activate will be called.
So which will happen first, will activate, be called on the server or will the RPC get there?
And the truth is that this is undeterminable.
We can't be guaranteed that one will always be executed after the other.
For this reason, gas has a built in target data system.
You see, there are a number of types of target data built into gas and they all are based on a struct
called F gameplay ability target data.
That's a parent class and there are ways to send target data up to the server.
For example, there's a function called server set replicated target data.
And what this does is sends data up to the server, at which point the server receives it and then takes
its target set, which is a delegate and broadcasts that delegate.
So if any callbacks are bound to this target set delegate on the server, they can be called in response
and receive that target data.
Now a map is maintained called ability target data map, and it maps ability specs to target data.
Now, this is a simplification along with the ability spec.
It also keeps track of other things such as the prediction key.
We haven't talked about prediction keys yet.
We'll talk about those in the future, but prediction keys have to do with prediction and how gas has
the built in capability to predict things.
So what we can do is from our ability task, as soon as we have the activate function called, we can
use this function server set replicated target data.
This allows us to send target data to the server and on the server.
When the server is activate function gets called.
We still don't know if the replicated target data has reached the server yet or not.
So what we can do is bind to that target set delegate.
But if we've done this before, that replicated target data has reached the server.
In other words, the time that it took for Activate to be called on the server epsilon was less than
Delta.
The time that it took for the RPC to get there.
Then if that's the case, then no problem.
Once the target data gets there, then the target set delegate will be broadcast and the server will
receive it.
Now, on the other hand, let's say that the replicated target data reaches the server first, at which
point that target set delegate broadcast is made, and then after that the servers activate function
gets called and that means it's too late.
The broadcast had already happened before we bound to it.
We missed it.
Right?
So what we can do in that case is call this function call replicated target data delegate if set.
So this is going to provide a safeguard for us if the replicated target data gets there first and the
delegate is broadcast before the server can bind to the target set delegate, it will force the broadcast
of that delegate again and retrieve that target data.
So this is the approach that we can make with our ability task so that we can get some target data up
to the server.
So we'll be doing that in the videos to come.
Excellent job and I'll see you in the next video.