WEBVTT 00:06.990 --> 00:08.160 Welcome back. 00:08.340 --> 00:15.210 Now we've created our own ability task, and that task is capable of finding the hit results under the 00:15.210 --> 00:16.050 cursor. 00:16.350 --> 00:22.800 But we've quickly discovered a limitation of that because we're only doing this locally, there's no 00:22.800 --> 00:29.610 way that the server can know what that location is when the client clicks for reasons like this. 00:29.640 --> 00:36.480 Gas has a built in mechanism for sending target data to and from the server. 00:38.050 --> 00:44.520 Now, let's say on the client, we have an ability and it's executing an ability task. 00:44.530 --> 00:47.830 So it's activate function has been called. 00:47.860 --> 00:55.780 Now this means that the activate function is going to be called on the server at some point later in 00:55.780 --> 00:56.440 time. 00:56.440 --> 01:03.580 We'll call the amount of time that it takes for the server's ability task to activate Epsilon. 01:03.700 --> 01:09.040 This represents the amount of time that the data travels across the network. 01:09.490 --> 01:16.360 Now we need our data to reach the server and we know that when our ability task activates, then the 01:16.360 --> 01:22.480 ability task will automatically be activated on the server as soon as the server knows about it. 01:22.690 --> 01:30.310 But as soon as we activate our task, we want to get some data, a vector representing a location in 01:30.310 --> 01:33.610 the world and we want to send it to the server. 01:33.610 --> 01:39.680 So the only way that we really know how to send things to the server is through Rpcs. 01:39.710 --> 01:47.480 We make a server RPC, we send the data up to the server and after some amount of time we'll call it 01:47.510 --> 01:48.350 Delta. 01:48.470 --> 01:53.240 The server receives that RPC and thus receives the data. 01:53.240 --> 01:56.320 Now the question is which gets there first? 01:56.330 --> 02:03.140 Does the server version of the ability task have its activate function called first before that RPC 02:03.140 --> 02:04.250 reaches the server? 02:04.280 --> 02:06.920 Or does the RPC get there first? 02:06.920 --> 02:09.980 In other words, is Epsilon less than Delta? 02:10.010 --> 02:15.890 If the amount of time that it takes for Activate to be called on the server is less than the amount 02:15.890 --> 02:23.150 of time it takes for the RPC to get there, then on the server activate will be called and the server 02:23.150 --> 02:25.490 will not have any valid data. 02:25.610 --> 02:33.080 Now on the other hand, if Delta is less than epsilon, in other words the RPC reaches the server first, 02:33.110 --> 02:39.800 then the RPC will be implemented on the server and the server will get the valid data, after which 02:39.830 --> 02:41.180 activate will be called. 02:41.180 --> 02:47.360 So which will happen first, will activate, be called on the server or will the RPC get there? 02:47.360 --> 02:50.750 And the truth is that this is undeterminable. 02:50.750 --> 02:55.760 We can't be guaranteed that one will always be executed after the other. 02:56.270 --> 03:00.890 For this reason, gas has a built in target data system. 03:00.980 --> 03:09.620 You see, there are a number of types of target data built into gas and they all are based on a struct 03:09.620 --> 03:12.710 called F gameplay ability target data. 03:12.740 --> 03:18.260 That's a parent class and there are ways to send target data up to the server. 03:18.590 --> 03:23.150 For example, there's a function called server set replicated target data. 03:23.300 --> 03:32.090 And what this does is sends data up to the server, at which point the server receives it and then takes 03:32.090 --> 03:37.160 its target set, which is a delegate and broadcasts that delegate. 03:37.160 --> 03:43.700 So if any callbacks are bound to this target set delegate on the server, they can be called in response 03:43.700 --> 03:45.590 and receive that target data. 03:46.070 --> 03:53.810 Now a map is maintained called ability target data map, and it maps ability specs to target data. 03:53.840 --> 03:57.410 Now, this is a simplification along with the ability spec. 03:57.410 --> 04:01.430 It also keeps track of other things such as the prediction key. 04:01.460 --> 04:03.710 We haven't talked about prediction keys yet. 04:03.740 --> 04:10.070 We'll talk about those in the future, but prediction keys have to do with prediction and how gas has 04:10.070 --> 04:12.960 the built in capability to predict things. 04:12.980 --> 04:20.090 So what we can do is from our ability task, as soon as we have the activate function called, we can 04:20.090 --> 04:23.690 use this function server set replicated target data. 04:23.720 --> 04:28.280 This allows us to send target data to the server and on the server. 04:28.280 --> 04:31.010 When the server is activate function gets called. 04:31.100 --> 04:37.130 We still don't know if the replicated target data has reached the server yet or not. 04:37.250 --> 04:41.120 So what we can do is bind to that target set delegate. 04:41.120 --> 04:46.710 But if we've done this before, that replicated target data has reached the server. 04:46.710 --> 04:53.010 In other words, the time that it took for Activate to be called on the server epsilon was less than 04:53.010 --> 04:53.490 Delta. 04:53.520 --> 04:57.530 The time that it took for the RPC to get there. 04:57.540 --> 05:00.900 Then if that's the case, then no problem. 05:00.900 --> 05:06.180 Once the target data gets there, then the target set delegate will be broadcast and the server will 05:06.180 --> 05:07.110 receive it. 05:07.560 --> 05:14.010 Now, on the other hand, let's say that the replicated target data reaches the server first, at which 05:14.010 --> 05:21.570 point that target set delegate broadcast is made, and then after that the servers activate function 05:21.570 --> 05:24.900 gets called and that means it's too late. 05:24.900 --> 05:28.320 The broadcast had already happened before we bound to it. 05:28.350 --> 05:29.190 We missed it. 05:29.190 --> 05:29.780 Right? 05:29.790 --> 05:37.440 So what we can do in that case is call this function call replicated target data delegate if set. 05:37.740 --> 05:44.760 So this is going to provide a safeguard for us if the replicated target data gets there first and the 05:44.760 --> 05:52.260 delegate is broadcast before the server can bind to the target set delegate, it will force the broadcast 05:52.290 --> 05:55.800 of that delegate again and retrieve that target data. 05:56.040 --> 06:02.310 So this is the approach that we can make with our ability task so that we can get some target data up 06:02.310 --> 06:03.390 to the server. 06:03.630 --> 06:06.630 So we'll be doing that in the videos to come. 06:06.990 --> 06:09.690 Excellent job and I'll see you in the next video.