Welcome back.
Now we have our electrocute effect.
So far it's looking pretty good.
We don't have the beam yet.
It's also quite silent.
I'd like to play a sound, and I'd like to use a gameplay cue for that.
And in doing so, I'd like to take a little bit of a deeper dive into how our project handles gameplay
cues in general.
So here in The electrocute, I'm going to make a new blueprint, and we're going to choose Gameplay
Cue notify, and we're going to choose static, just like we have for the cue that we're using for the
blood particles and sound on the enemy.
We're going to select that and we're going to call this GC underscore shock burst.
Now shock burst is a static gameplay cue.
And for static gameplay cues we override the function on execute, and we can plug in target and parameters
into the parent function as we're overriding this.
But really, I just like to get my target, get the location of it.
And this is of course Ora.
I'm going to get actor location.
And I'd like to play a sound at this location, so I'm going to use play sound at location.
And the sound I'd like to play.
Well, we can take a look at content, assets, sounds.
And abilities and there's a shock with SFX shock.
There's also a shock loop and we'll get to that later, but I'm going to use SFX shock right here.
It's just going to be hardcoded right in and I'm going to hook up.
On, execute and hook up, play sound at location two, the return node and we have a basic shock burst
gameplay queue.
Now this queue needs to be associated with the gameplay queue tag.
So if we look in class defaults, we can choose a gameplay queue tag.
I don't have a gameplay queue for Shock Burst, so I'm going to go to Project Settings and just add
one here in the editor.
So going to gameplay tags, we have our gameplay queue, we have melee impact.
I'm going to add a new one.
Gameplay queue dot shock burst.
Now our gameplay cue tag has shock burst, and if we go back to Shock Burst, we can give it the shock
burst tag.
Notice we can't choose anything else that's not a gameplay cue tag.
So now that this has the shock burst tag, we can activate this gameplay cue.
I'd like to go back to electrocute, so let's go into a electrocute.
I'd like to make this on execute.
Get called.
So here in electrocute, as soon as we've updated the facing target.
We can do this even before just before playing the montage.
We can execute a gameplay cue by using execute gameplay cue on owner.
And if we do this, of course, Shock Burst has this.
My target, which will be the owner or the owning avatar.
This function handles setting that for us.
We do have to choose the gameplay cue.
We're going to choose Shock Burst for this, and we can go ahead and just call this function like this.
And if we go into shock burst and we just print the name of my target so we can use get object name.
And we can use a print string.
We can print the name of this.
My target.
So if we go back now, we hear that sound.
We're printing the name if we try this in multiplayer.
Setting it to number of players to two.
And we try this on the client.
It works as well.
That's the magic of gameplay cues.
So now we have a gameplay queue to handle that starting sound great.
Now if you take a look at your output log, you may notice that there's a warning pretty far up somewhere.
Looking for yellow text here.
Warning.
No gameplay.
Notify paths were specified in default game ini.
Under and it even tells you.
Script.
Gameplay.
Abilities.
Ability.
System.
Globals.
It says falling back to using all of game.
It even goes on to say this may be slow on large projects.
Consider specifying which paths are to be searched.
You see, we're executing a gameplay queue by gameplay tag, and the gameplay queue manager has to search
our entire project for the gameplay queue notify Shock Burst that has this gameplay queue tag, but
we can make this a little bit more optimized by keeping our gameplay cue notifies in one folder or a
small number of folders.
So we could go into ability system and just have one folder for our gameplay cue notifies.
This is an optimization that allows the gameplay queue manager to not have to search all of these folders.
So what we would do is create a new folder.
I'm going to put it in blueprints ability system and call this gameplay queue.
Notify size.
And we can move all of our gameplay cues into this.
So if I have my blueprints ability system, gameplay cue notifies folder available here, then I can
browse to GC Shock Burst.
And I can drag that into my gameplay cue.
Notifies.
And I can move it there.
Now we also have another gameplay cue if we go to Ability System Enemy cuz we have GC melee impact.
Now if you don't want them all in the same folder, we can specify multiple paths and we'll see how.
But if we want one path and we want it to be as optimized as possible, we can put all of our gameplay
cue notifies right there in gameplay cue notifies.
We can move that there.
I can delete that, cuz.
And now we know all of our gameplay cue notifies are here, and we can tell the gameplay cue manager
look, you don't have to search the whole project.
Start here.
So how do we tell it that?
Well, that warning told us where to go.
We're going to close our project.
We're going to find our config folder.
And where did that warning tell us to look.
It told us to go to default gaming and I.
And to add something here under ability system globals.
Now we already have it here because we set our aura ability system globals as the ability system globals
class to use.
Here is also where we can specify our gameplay cue notifies path so we can add that path with plus and
we can say gameplay cue, notify paths equals and we can provide the path we start with game.
This takes the place of the content folder.
So our folder is what comes after that.
We had blueprints ability system slash gameplay cue notifies.
Now if we had say kept that other folder where we had our enemies gameplay cue, we could have added
that too.
We could add blueprints, ability, system, and whatever other path here that we want.
We can have multiple paths here, that's fine, but we can also have them all in the same folder right
here.
Gameplay cue notifies.
That works too.
So that's the first thing I'd like to do a deep dive on.
Now we have our cue notifies set.
Now there's another thing I want to bring to your attention.
I'm going to hit debug.
I'll go ahead and let those asset editors open again.
And I'm going to execute a gameplay queue.
But first I'm going to come back into rider and do a project wide search for max RPC per net update
and go into Gameplay Queue manager CP and place a breakpoint right here and check for too many Rpcs.
You see, there's a max number of rpcs, and our gameplay queues are replicated as rpcs, and there's
a limit to how many that can be sent per net update.
I'd like to see what that limit is by placing a breakpoint and coming back in here and right clicking
now that's going to execute that gameplay queue.
And if we check out this variable, we see that it's an eye console variable.
Right here we see two.
So if we expand it and show data we see shadowed value.
There's two elements in it.
And they're both set to two.
That's the number of rpcs that can be sent.
That's the number of gameplay queues that can be sent per net update.
And that's kind of low.
And we can override that.
Now we don't want to override it to a huge number like a thousand, but two is a bit low.
We can go up to about ten.
The Lyra game project sets it to ten.
Well, how do we set it?
Well, notice that this is a console variable and we can set console variables for our project.
So what I'm going to do is hit stop and back to our config folder.
This time I'm going to go into default engine ini.
And we can set console variables by using square brackets and typing console variables.
And we can add one that's.
Net all lowercase dot max rpc per net update.
We can set that to a value.
Now like I said Lyra uses ten.
We can use ten, and ten is plenty.
You really don't need more than ten, trust me.
And if you do need more than ten, you should rethink your strategy and your design, right?
Because that's too many rpcs per net update.
We've got to be kind of sparing with them.
That's kind of why we don't use gameplay cues for just everything that we could.
We use them for things that we have to use them for.
So now that we've set this to ten, we can save and close that and we can run in debug mode again.
And we can press play and we can activate our ability by right clicking.
And I removed my break point.
So I'm going to put it back and right click.
And take a look at the value here.
Now we see that we have ten instead of two went from 2 to 10.
Great.
So now we can accommodate for more gameplay cues.
But again this is per net update.
Net updates are not as often as say, the tick function by any means, but they're not slow either,
right?
We could be receiving net updates 60 to 100 times per second, depending on bandwidth and what's going
on in the game.
So you don't need more than ten.
Ten is actually probably overkill, but at least now we don't have it set to two, which is kind of
ridiculously low.
Okay, so I'm going to go ahead and go into gameplay.
Cue notifies open my shock burst, and I don't want to print a string anymore.
I just want to hear that sound.
And that sound is sounding great.
And the sound takes a little bit longer than my montage seems to.
Allow.
So I think I am going to go into my cast electrocute montage and set the rate scale a little bit slower.
Not much 0.75 should do it.
Maybe even 0.6.
Yeah.
That's better.
And now that it's a little slower, we can blend in a little slower, we can blend in even 0.2 or 0.3.
Yeah, that looks good.
I might even go back down to 0.5 for the rate scale.
And I'm going to zero in on 0.55.
I think that is good.
That's the sweet spot.
Let's hear it.
Yep, that sounds great.
Okay, so now we have another gameplay cue in our project and we're using it in our electrocute ability.
Things are sounding good.
It's time to start making things look good too.
And we'll do that next.
I'll see you soon.