Welcome back.
Now, we've already seen one type of custom calculation for our gameplay effects, and that's the mod
mag calc or modifier magnitude calculations commonly called MKs.
Now, there's another type of custom calculation, the execution calculation.
Now, this is a class of type U gameplay effect execution calculation.
And this is the most powerful way to modify attributes in a gameplay effect.
And it's the most custom way.
Now, this class allows us to perform calculations using the values of captured attributes so they can
capture attribute values and they can change more than one attribute.
This makes it more powerful than the MK, which can only change a single attribute.
But a custom calculation can really do any kind of programmer logic that we code in it.
We have complete flexibility.
Now the gameplay effect execution calculation does come with a few caveats.
For one, it does not support prediction.
For another, only instant or periodic gameplay effects can use one of these.
This is not something that can be run with an infinite gameplay effect or a duration based gameplay
effect.
For that matter, unless it executes periodically as those periodic executions are treated like instant
gameplay effects.
Now capturing these attributes does not run pre attribute change.
So any clamping done there in pre attribute change must be done again here if we want that clamp to
be effective.
Now this execution calculation is only run on the server if we're applying this from a gameplay ability
with the local predicted server initiated and server only net execution policies.
Now this makes sense.
If we activate an ability and apply a gameplay effect locally with a local predicted gameplay ability,
then that ability will be predicted.
But the execution calculation resulting from an applied gameplay effect will only run on the server.
So we're relying on changing things that replicate in and of themselves, i.e. other attributes, for
example.
So we treat this execution calculation pretty much as something that runs on the server.
And if we keep that understanding in mind, then the execution calculation will run as we expect.
Now, when capturing attributes, we can choose whether or not to snapshot.
And this really only matters when we're capturing attributes from the source, the thing that's applying
the effect, not the target.
When snapshotting those attribute values are captured, when the gameplay effect spec is created.
So remember, this execution calculation is being used on a gameplay effect, and when that spec is
created, if those attributes are set to be snapshotted, then those values of the attributes will be
captured then and there when we create that spec.
So in the case of our fireball, for example, we create the effect spec.
When we spawn the fireball, we're not applying it then and there.
We're waiting until the fireball hits something, right?
Well, if we were to snapshot and capture attributes in that damage gameplay effect on the fireball,
they'd be captured right then and there.
When the effect spec is created.
Now contrast this with not snapshotting.
If we choose not to snapshot, then those attribute values are captured when the gameplay effect is
applied, i.e. when the fireball hits something and we apply the gameplay effect spec.
Now this really only matters for the source.
Why?
Because we don't necessarily know who the target is going to be when we create that effect spec.
In the case of the fireball, we don't know who the fireball is going to hit, right?
So it doesn't make sense to capture the target's attributes when we don't know who the target is.
So for the target, the values of those captured attributes are captured on effect application.
So as soon as we apply that effect, that's when we capture attribute values from the target, even
if we set those to be snapshotted.
So that's another thing to be aware of.
Now, execution calculations are extremely powerful.
Let's say we have an effect spec and in the gameplay effect class for this effect spec we're using a
execution calculation class for our custom calculation class.
Now we know that this execution calculation is capable of capturing attributes.
Well, it's also capable of capturing set by color magnitudes.
In other words, we can set a key value pair where the key is a gameplay tag and the value is some magnitude
a float value, and we can set that on the gameplay effect spec.
Once we create it, we can assign a tag set by color magnitude and when the gameplay effect is applied,
the execution calculation is capable of retrieving that set by color magnitude.
Now, in the gameplay effect itself, we can also add calculation modifiers that are backed by attributes.
So we can take an attribute either on the source or the target and we can modify it from the gameplay
effect itself.
Now this will be applied.
Let's say we want to override, add, subtract, multiply.
Anything we'd like to do to a captured attribute.
We can do that directly on the gameplay effect.
And once we get to the execution calculation, if we're capturing that attribute, we'll get that captured
value after the calculation modifier has changed it.
So as you can see, the gameplay effect execution calculation class is quite powerful and a common use
case for one of these is complex damage calculations that need to take lots of attributes and other
values into account.
That's what we're going to use one for and we'll do that next.
I'll see you soon.