WEBVTT 00:06.950 --> 00:08.090 Welcome back. 00:08.270 --> 00:15.110 Now, we've already seen one type of custom calculation for our gameplay effects, and that's the mod 00:15.140 --> 00:21.200 mag calc or modifier magnitude calculations commonly called MKs. 00:21.230 --> 00:26.040 Now, there's another type of custom calculation, the execution calculation. 00:26.060 --> 00:31.580 Now, this is a class of type U gameplay effect execution calculation. 00:31.580 --> 00:37.100 And this is the most powerful way to modify attributes in a gameplay effect. 00:37.100 --> 00:39.110 And it's the most custom way. 00:39.470 --> 00:47.480 Now, this class allows us to perform calculations using the values of captured attributes so they can 00:47.480 --> 00:52.520 capture attribute values and they can change more than one attribute. 00:52.550 --> 00:59.210 This makes it more powerful than the MK, which can only change a single attribute. 00:59.210 --> 01:05.510 But a custom calculation can really do any kind of programmer logic that we code in it. 01:05.540 --> 01:07.770 We have complete flexibility. 01:07.800 --> 01:13.230 Now the gameplay effect execution calculation does come with a few caveats. 01:13.260 --> 01:16.590 For one, it does not support prediction. 01:16.590 --> 01:22.280 For another, only instant or periodic gameplay effects can use one of these. 01:22.290 --> 01:28.260 This is not something that can be run with an infinite gameplay effect or a duration based gameplay 01:28.260 --> 01:28.620 effect. 01:28.620 --> 01:36.450 For that matter, unless it executes periodically as those periodic executions are treated like instant 01:36.450 --> 01:37.710 gameplay effects. 01:38.390 --> 01:43.520 Now capturing these attributes does not run pre attribute change. 01:43.520 --> 01:50.660 So any clamping done there in pre attribute change must be done again here if we want that clamp to 01:50.660 --> 01:51.650 be effective. 01:51.680 --> 01:58.550 Now this execution calculation is only run on the server if we're applying this from a gameplay ability 01:58.550 --> 02:05.780 with the local predicted server initiated and server only net execution policies. 02:05.810 --> 02:06.950 Now this makes sense. 02:06.950 --> 02:13.250 If we activate an ability and apply a gameplay effect locally with a local predicted gameplay ability, 02:13.280 --> 02:16.250 then that ability will be predicted. 02:16.250 --> 02:23.840 But the execution calculation resulting from an applied gameplay effect will only run on the server. 02:23.840 --> 02:31.340 So we're relying on changing things that replicate in and of themselves, i.e. other attributes, for 02:31.340 --> 02:32.150 example. 02:32.150 --> 02:38.100 So we treat this execution calculation pretty much as something that runs on the server. 02:38.100 --> 02:45.040 And if we keep that understanding in mind, then the execution calculation will run as we expect. 02:45.060 --> 02:49.650 Now, when capturing attributes, we can choose whether or not to snapshot. 02:49.740 --> 02:55.050 And this really only matters when we're capturing attributes from the source, the thing that's applying 02:55.050 --> 02:57.210 the effect, not the target. 02:57.360 --> 03:04.260 When snapshotting those attribute values are captured, when the gameplay effect spec is created. 03:04.260 --> 03:10.410 So remember, this execution calculation is being used on a gameplay effect, and when that spec is 03:10.410 --> 03:16.620 created, if those attributes are set to be snapshotted, then those values of the attributes will be 03:16.620 --> 03:19.710 captured then and there when we create that spec. 03:19.740 --> 03:23.400 So in the case of our fireball, for example, we create the effect spec. 03:23.400 --> 03:27.360 When we spawn the fireball, we're not applying it then and there. 03:27.360 --> 03:29.820 We're waiting until the fireball hits something, right? 03:30.030 --> 03:36.120 Well, if we were to snapshot and capture attributes in that damage gameplay effect on the fireball, 03:36.120 --> 03:38.430 they'd be captured right then and there. 03:38.430 --> 03:40.340 When the effect spec is created. 03:40.350 --> 03:43.260 Now contrast this with not snapshotting. 03:43.260 --> 03:48.750 If we choose not to snapshot, then those attribute values are captured when the gameplay effect is 03:48.750 --> 03:54.800 applied, i.e. when the fireball hits something and we apply the gameplay effect spec. 03:54.810 --> 03:57.390 Now this really only matters for the source. 03:57.390 --> 03:57.900 Why? 03:57.930 --> 04:04.110 Because we don't necessarily know who the target is going to be when we create that effect spec. 04:04.140 --> 04:07.830 In the case of the fireball, we don't know who the fireball is going to hit, right? 04:07.830 --> 04:14.580 So it doesn't make sense to capture the target's attributes when we don't know who the target is. 04:14.580 --> 04:22.350 So for the target, the values of those captured attributes are captured on effect application. 04:22.350 --> 04:28.830 So as soon as we apply that effect, that's when we capture attribute values from the target, even 04:28.830 --> 04:30.750 if we set those to be snapshotted. 04:30.750 --> 04:33.450 So that's another thing to be aware of. 04:34.230 --> 04:38.160 Now, execution calculations are extremely powerful. 04:38.460 --> 04:45.930 Let's say we have an effect spec and in the gameplay effect class for this effect spec we're using a 04:45.930 --> 04:50.650 execution calculation class for our custom calculation class. 04:50.670 --> 04:56.430 Now we know that this execution calculation is capable of capturing attributes. 04:56.670 --> 05:01.530 Well, it's also capable of capturing set by color magnitudes. 05:01.530 --> 05:08.970 In other words, we can set a key value pair where the key is a gameplay tag and the value is some magnitude 05:08.970 --> 05:13.080 a float value, and we can set that on the gameplay effect spec. 05:13.080 --> 05:20.310 Once we create it, we can assign a tag set by color magnitude and when the gameplay effect is applied, 05:20.340 --> 05:26.320 the execution calculation is capable of retrieving that set by color magnitude. 05:26.340 --> 05:33.660 Now, in the gameplay effect itself, we can also add calculation modifiers that are backed by attributes. 05:33.660 --> 05:41.260 So we can take an attribute either on the source or the target and we can modify it from the gameplay 05:41.260 --> 05:42.460 effect itself. 05:42.460 --> 05:44.050 Now this will be applied. 05:44.170 --> 05:48.190 Let's say we want to override, add, subtract, multiply. 05:48.190 --> 05:52.030 Anything we'd like to do to a captured attribute. 05:52.060 --> 05:54.610 We can do that directly on the gameplay effect. 05:54.610 --> 06:01.300 And once we get to the execution calculation, if we're capturing that attribute, we'll get that captured 06:01.300 --> 06:05.580 value after the calculation modifier has changed it. 06:05.590 --> 06:13.990 So as you can see, the gameplay effect execution calculation class is quite powerful and a common use 06:13.990 --> 06:21.280 case for one of these is complex damage calculations that need to take lots of attributes and other 06:21.280 --> 06:23.020 values into account. 06:23.050 --> 06:27.310 That's what we're going to use one for and we'll do that next. 06:27.760 --> 06:28.900 I'll see you soon.