WEBVTT 00:07.280 --> 00:08.690 Welcome back. 00:09.440 --> 00:16.490 Now my enemies can get burned, which is cool, but I also would like to see something while that's 00:16.490 --> 00:17.300 happening. 00:17.300 --> 00:24.650 So while the enemies are sitting there roasting, I want to see a fire effect similar to my pillars 00:24.650 --> 00:25.580 of flame here. 00:25.580 --> 00:30.800 So I'm going to create a Niagara component for that. 00:30.830 --> 00:33.620 Now notice I didn't say add a Niagara component. 00:33.620 --> 00:35.090 I said create one. 00:35.090 --> 00:35.660 Why? 00:35.690 --> 00:41.450 Because the Niagara system component is a component like our other components. 00:41.450 --> 00:43.430 It just has a Niagara system on it. 00:43.430 --> 00:49.970 But if we derive a new C plus plus class from Niagara component, we can have a Niagara component that 00:49.970 --> 00:55.220 can activate and deactivate itself depending on stuff that's going on with its owner. 00:55.250 --> 01:00.330 That is a clever solution, if I do say so myself. 01:00.330 --> 01:07.140 So I'm going to create a new Cplusplus class in the Ability system folder right there. 01:07.140 --> 01:12.060 And it's going to be based on Niagara component. 01:12.990 --> 01:15.240 So I'm going to choose Niagara component. 01:15.240 --> 01:20.820 And in the Ability system folder I'm going to make a new folder called debuff because I want to stay 01:20.850 --> 01:21.810 organized. 01:21.810 --> 01:32.250 And this is going to be a debuff Niagara component a special subclass of Niagara component with additional 01:32.250 --> 01:33.330 capabilities. 01:33.360 --> 01:35.010 We're going to create this class. 01:35.010 --> 01:38.310 We're going to close the editor and we're going to open up this class. 01:38.310 --> 01:43.800 So I'm going to go ahead and close all tabs and open up my public folder. 01:43.830 --> 01:47.820 Go to Ability System and wait for it. 01:49.140 --> 01:49.770 There it is. 01:49.770 --> 01:51.990 Debuff got a little nervous there. 01:52.020 --> 01:56.040 It took a little longer than normal okay. 01:56.040 --> 02:01.180 So we have a Niagara component Specifically for debuffs. 02:01.210 --> 02:02.230 Now, what does that mean? 02:02.230 --> 02:04.180 What are we going to use this for? 02:04.390 --> 02:10.150 Well, for one, a debuff Niagara component should be identified by a gameplay tag. 02:10.240 --> 02:17.290 I'm going to go ahead and make a public section and add an F gameplay tag called Debuff Tag. 02:19.960 --> 02:27.340 Now debuff Tag gets a new property and we'll make it edit defaults only. 02:27.460 --> 02:35.140 And in addition to a gameplay tag, I'm going to declare and define a constructor for one reason and 02:35.140 --> 02:41.860 one reason only, and that is to set be auto activate to false. 02:41.920 --> 02:47.620 So the Niagara system on this component would auto activate if this were true. 02:47.650 --> 02:53.110 Now we won't have goblins sprouting up with flaming heads, although that would be cool. 02:53.140 --> 02:59.390 So now that we have this Niagara component, we need to know when to activate and when to deactivate 02:59.390 --> 03:06.920 it, and the Niagara component has activate, which you can use to activate its Niagara system. 03:06.920 --> 03:10.670 And it also has deactivate to deactivate it. 03:10.670 --> 03:17.660 And I'd like to activate and deactivate this when the owner of this Niagara component gets the debuff 03:17.690 --> 03:18.470 tag. 03:19.430 --> 03:21.560 And that's going to be your quest. 03:21.560 --> 03:28.790 Responding to debuff tags, I'd like you to activate the Niagara component when the owner of the Niagara 03:28.790 --> 03:36.170 component gets the debuff tag, and then deactivate the Niagara component when the owner loses that 03:36.170 --> 03:36.920 tag. 03:36.950 --> 03:41.390 That way, we'll be able to see visually if that owner has a debuff. 03:41.390 --> 03:44.750 So pause the video and give this one a try. 03:47.960 --> 03:51.140 Okay, so we need to do a few things here. 03:51.140 --> 03:53.390 For one we're going to need Beginplay. 03:53.390 --> 03:57.920 So I'm going to add a protected section and override began. 03:57.920 --> 03:59.930 Play virtual void. 03:59.930 --> 04:00.470 Begin. 04:00.470 --> 04:01.430 Play. 04:01.460 --> 04:02.750 Override. 04:02.840 --> 04:11.270 Now I'm also going to create a debuff tag changed callback so that we can bind it to a delegate on the 04:11.270 --> 04:15.470 ability system component for when a debuff tag has changed. 04:15.620 --> 04:21.020 So I'm going to make a void function called debuff tag changed. 04:21.350 --> 04:27.320 Now the signature is going to be a const f gameplay tag, not a const reference. 04:27.320 --> 04:32.720 And it's called callback tag and an int32 called New Count. 04:32.720 --> 04:40.100 And you probably went and checked out your other tag change callbacks because we have those two elsewhere 04:40.100 --> 04:41.210 in our project. 04:41.240 --> 04:45.710 Well, let's go ahead and generate definitions for these. 04:45.710 --> 04:48.380 And we can call super Beginplay. 04:48.410 --> 04:52.070 We can get our debuff tag changed function there. 04:52.070 --> 04:55.580 And debuff tag change is going to be quite simple. 04:55.580 --> 05:05.040 We're going to check if new count is greater than zero, then we can activate if it's not. 05:05.070 --> 05:08.610 In other words, we have an else case we can deactivate. 05:09.450 --> 05:11.370 So that's pretty simple. 05:11.430 --> 05:16.020 So we're going to need debuff tag changed bound to a delegate. 05:16.020 --> 05:18.300 And we're going to do that in Beginplay. 05:18.780 --> 05:20.700 So how do we do that. 05:20.970 --> 05:25.350 Well we need the ability system component of our owner. 05:25.350 --> 05:29.790 So we can use you ability system blueprint library. 05:29.820 --> 05:31.950 We'll get that auto include there. 05:31.950 --> 05:36.510 We'll call get ability system component of well our owner. 05:36.510 --> 05:37.950 So we're going to call get owner. 05:37.950 --> 05:44.700 That'll give us whoever owns this Niagara component which is going to be whoever we add one of these 05:44.700 --> 05:45.540 to. 05:45.570 --> 05:52.560 Once we have that ability system component which we can store in a local pointer, let's do that new 05:52.560 --> 05:54.480 ability system component ASC. 05:54.960 --> 05:57.790 Once we have that, then we can use it. 05:57.790 --> 06:05.470 But the thing is, the ASC might not be initialized yet at this point in time. 06:05.470 --> 06:12.310 So what we'll do is check if ASC and if it is then we can take ASC. 06:12.310 --> 06:17.350 And what we're looking for is register gameplay tag event. 06:17.350 --> 06:19.090 And this requires the tag. 06:19.090 --> 06:23.290 Well we have the debuff tag that member variable. 06:23.290 --> 06:29.230 And we're going to use E gameplay tag event type new or removed. 06:29.560 --> 06:37.480 Now this gets us the delegate we're going to use add Uobject passing in this and our function callback 06:37.480 --> 06:39.190 debuff tag changed. 06:39.190 --> 06:45.400 So at you debuff Niagara component debuff tag changed. 06:46.450 --> 06:51.550 Now what about the situation where asc is a null pointer? 06:51.580 --> 06:55.390 The owner may not have a valid ability system component yet. 06:55.820 --> 06:59.930 Now that's okay if you didn't take this into account, but I'm going to. 06:59.960 --> 07:03.950 So how do we know if our ask becomes valid? 07:03.980 --> 07:11.570 Well, the easiest way is to create a delegate and broadcast it from the owner as soon as that ability 07:11.600 --> 07:13.520 system component is valid. 07:13.610 --> 07:17.630 So I'd like to make a delegate that we can broadcast when that happens. 07:17.630 --> 07:25.250 But I don't want my debuff component dependent on the aura character or aura character base. 07:25.250 --> 07:31.430 So we're going to make a function on our combat interface that can return that delegate. 07:31.430 --> 07:37.040 And for that matter, we can declare that delegate on the combat interface itself. 07:37.040 --> 07:42.020 So I'm going to open my combat interface and declare a new type of delegate. 07:42.290 --> 07:45.380 It's going to be a declare multicast delegate one param. 07:45.380 --> 07:49.370 And I'm going to call it F on ASC registered. 07:49.550 --> 07:55.800 And the reason I'd like it to be one param is I'd like to broadcast that ability system component as 07:55.800 --> 07:57.120 soon as it's valid. 07:57.330 --> 08:00.690 So I'm going to broadcast a usability system component. 08:01.830 --> 08:07.170 I'll go ahead and add a forward declaration for it, and we'll pass it through by pointer. 08:07.170 --> 08:11.160 And now our combat interface can have a function to retrieve it. 08:11.160 --> 08:21.420 So a function that returns an F on ASC registered and we can call it get on ASC registered. 08:21.690 --> 08:24.030 We could call it delegate if we want to. 08:24.060 --> 08:27.630 And I'm going to make this a virtual function. 08:29.550 --> 08:31.740 In fact I'd like it to be pure virtual. 08:31.740 --> 08:35.460 So I'll set it equal to zero there and make it pure virtual. 08:35.460 --> 08:38.760 So it's forced upon anything that implements this. 08:38.760 --> 08:40.530 They have to override it. 08:40.530 --> 08:46.350 And I'm not going to expose it to blueprint just here in C plus plus. 08:46.350 --> 08:54.760 And I'm going to open my aura character base and add one of these delegates an F on ASC registered called 08:54.790 --> 08:56.830 on ASC registered. 08:56.830 --> 09:00.730 And we'll implement that pure virtual function. 09:00.730 --> 09:02.320 Get on ASC registered. 09:02.320 --> 09:06.850 We'll add override to it and implement this function. 09:06.850 --> 09:12.370 And all we're going to do in this function is return on ASC register. 09:12.400 --> 09:17.980 Now that we have an easy way to get that delegate on the owner, we'll do it here. 09:17.980 --> 09:19.450 So we'll have an else case. 09:19.450 --> 09:26.830 But I'm going to make it an else if so that I can check if the owner implements the combat interface. 09:26.830 --> 09:31.870 So that resulted in combat interface being added. 09:32.260 --> 09:35.680 When I created this pointer I'm going to call it Combat interface. 09:35.680 --> 09:40.150 And I'm going to cast it to combat interface I combat interface. 09:40.150 --> 09:41.170 What am I casting? 09:41.170 --> 09:42.880 I'm casting get owner. 09:42.940 --> 09:50.950 So if the owner implements this interface then I can call combat interface, get on ASC registered delegate 09:50.950 --> 09:53.150 and I can bind something to it. 09:53.810 --> 09:55.820 Now we can bind a function. 09:55.820 --> 09:57.380 We can bind a lambda. 09:57.410 --> 10:02.960 I'd like to add a lambda, but instead of using add lambda, I'd like to use add weak lambda. 10:02.990 --> 10:04.100 So what does that mean? 10:04.100 --> 10:05.780 What does add weak lambda? 10:05.810 --> 10:14.000 Well, a weak lambda is a little bit safer than a regular lambda because it has an additional parameter, 10:14.030 --> 10:16.550 a u object that it takes in. 10:16.550 --> 10:25.520 And internally, the weak lambda wraps this u object in a weak pointer, which does not affect its garbage 10:25.520 --> 10:27.080 collection reference count. 10:27.080 --> 10:33.830 But what it does do is it keeps track of that object and knows when that object is no longer valid. 10:33.830 --> 10:39.020 It checks that weak pointer to see if that object is still valid. 10:39.020 --> 10:41.690 If it's not, the lambda will not be executed. 10:41.690 --> 10:50.150 So weak lambdas are a safe way to bind a lambda, specifying an object to be checked when that lambda 10:50.150 --> 10:51.500 is to be called. 10:51.500 --> 10:58.700 So this can help us to prevent trying to access a pointer that points to a memory address that's no 10:58.700 --> 10:59.690 longer valid. 10:59.720 --> 11:06.320 The object that it used to point to perhaps was garbage collected or destroyed or marked pending kill. 11:06.320 --> 11:14.210 Weak lambdas will not be executed if that object passed in, as its first parameter is no longer valid. 11:14.240 --> 11:17.300 So I'm going to use add weak lambda. 11:17.330 --> 11:23.900 Now add weak lambda is different than add lambda in that it requires a user object first and then the 11:23.900 --> 11:24.470 lambda. 11:24.470 --> 11:26.420 So we're going to make the lambda here. 11:26.660 --> 11:30.320 Now I'll go ahead and put the body on its own lines. 11:30.320 --> 11:36.140 And the signature has to be for a function that can take a usability system component. 11:36.140 --> 11:38.180 So I'm going to call it in ASC. 11:38.480 --> 11:43.400 And in ASC I can do exactly what we're doing up here. 11:43.400 --> 11:47.240 We can register our callback to the gameplay tag event. 11:47.270 --> 11:52.740 Of course if we want to use this and debuff tag, we have to capture this. 11:52.740 --> 12:00.120 So now that we have this, we can make sure that we're broadcasting, get on, ask registered delegate. 12:00.120 --> 12:03.840 We want to make sure that this delegate is broadcast. 12:03.840 --> 12:09.630 And that's really going to mean something different depending on which character, whether it's or a 12:09.660 --> 12:16.500 character or enemy, if it's a or a character, we're going to do it in init ability actor info here. 12:16.530 --> 12:23.010 After our ability system component is valid, we know that it's valid after we set it here so we can 12:23.040 --> 12:26.850 broadcast on ASC, registered here. 12:27.810 --> 12:33.210 So on ASC registered broadcast and we can pass in the ability system component. 12:33.210 --> 12:39.960 But on Ora enemy that's going to be after it calls init ability actor info here. 12:39.960 --> 12:47.100 So I'm going to broadcast on ASC registered after it has its actor info initialized. 12:47.100 --> 12:49.260 So we'll broadcast it here. 12:49.560 --> 12:51.910 Broadcasting ability system component. 12:51.940 --> 12:58.060 Now, yes, we're calling it in both an ability actor infos and we could just call it in or a character 12:58.060 --> 13:00.520 base init ability actor info. 13:00.550 --> 13:02.410 Then we could call super. 13:02.440 --> 13:09.760 But the problem with that is is I don't want to do that because I'd have to remember to call super after 13:09.760 --> 13:13.150 we set our ability system component, not before. 13:13.150 --> 13:20.350 And that's error prone to developer error because it's kind of fragile when everything breaks. 13:20.350 --> 13:24.430 If you call super in the wrong place, and I just don't want to do that. 13:24.460 --> 13:26.440 So we're just going to call it here. 13:27.280 --> 13:31.570 So now we know on ASC registered will be broadcast. 13:31.930 --> 13:33.820 Now this is all great. 13:33.820 --> 13:38.020 Except there's another thing that we're not taking into account. 13:38.020 --> 13:42.220 And that other thing is what about when the character dies? 13:42.220 --> 13:45.280 When the character dies, we're going to want to call deactivate. 13:45.280 --> 13:48.760 Just like when a debuff tag has been removed. 13:48.790 --> 13:49.360 Right. 13:49.360 --> 13:54.470 So I'd like another delegate for when the enemy dies that we can broadcast. 13:54.470 --> 13:58.490 That's going to be really useful even in other circumstances. 13:58.490 --> 14:00.890 But we need to be able to get that, too. 14:00.920 --> 14:08.150 So I'm going to declare it on the combat interface and go through these same steps as I did for the 14:08.180 --> 14:10.310 on ask registered delegate. 14:10.310 --> 14:17.390 So back to the combat interface, but I'm going to make this one a dynamic multicast delegate, one 14:17.390 --> 14:25.400 param, because I'd like to be able to bind to this in blueprint, we're going to see all kinds of useful 14:25.400 --> 14:30.290 reasons to want a delegate bound for when something dies. 14:30.290 --> 14:40.010 So I'm going to declare a dynamic multicast delegate, and this will be one param. 14:41.150 --> 14:44.150 And I'm going to call this F on death. 14:45.200 --> 14:50.370 And on death is going to have one param and it's going to be an A actor. 14:52.050 --> 14:53.220 That'll be a pointer. 14:53.220 --> 15:00.090 And with a dynamic multicast we put a comma followed by the name of the param I'm going to call it dead 15:00.120 --> 15:00.870 Actor. 15:00.870 --> 15:07.080 And I'm going to create just another function here, just like the last one virtual. 15:07.080 --> 15:10.860 And it's going to be on death delegate. 15:11.190 --> 15:14.460 We'll call it get on death delegate. 15:15.210 --> 15:19.950 And it's going to be pure virtual and it needs a return type. 15:19.950 --> 15:22.650 It's going to return F on death. 15:22.770 --> 15:25.020 So same thing. 15:25.020 --> 15:27.390 We'll go back to our character base. 15:27.420 --> 15:30.030 We'll give it an F on death. 15:30.030 --> 15:33.480 Delegate called on death. 15:35.190 --> 15:37.890 And it's actually just called F on death. 15:38.100 --> 15:42.630 So we'll call it on death super short for a delegate name. 15:42.630 --> 15:48.340 And we'll override the function virtual F on Death. 15:48.760 --> 15:50.500 Get on death. 15:50.890 --> 15:51.850 Delegate. 15:52.690 --> 15:53.710 Override. 15:53.980 --> 15:55.690 Let's go ahead and implement it. 15:55.690 --> 15:57.370 And return on death. 15:59.860 --> 16:05.890 And we'll go ahead and go back to our beginplay on the Niagara component. 16:05.890 --> 16:13.810 And now I have a reason to get this eye combat interface outside the ElseIf, because I want to bind 16:13.810 --> 16:17.770 to this whether our ASC was initially valid or not. 16:17.770 --> 16:22.630 So I'm going to go ahead and make this combat interface just a variable here. 16:22.630 --> 16:25.900 And in the ElseIf we'll just check combat interface. 16:29.800 --> 16:33.370 But regardless I'm going to also bind here. 16:33.370 --> 16:42.550 If combat interface then I'm going to take Combat Interface and call get on death delegate. 16:42.550 --> 16:45.220 And I want to add a function to that. 16:45.220 --> 16:47.740 Now this is a dynamic multicast delegate. 16:47.740 --> 16:51.310 So I'm going to have to make a new function for it. 16:51.430 --> 16:54.910 I'm going to call this void on owner death. 16:55.180 --> 16:58.840 And this has to receive an A actor. 16:58.930 --> 17:00.670 We'll call it dead actor. 17:03.940 --> 17:05.740 Generate the definition for it. 17:05.770 --> 17:07.300 It's just going to deactivate. 17:07.300 --> 17:08.770 That's all it's going to do. 17:08.920 --> 17:11.290 It's still useful for this to broadcast the dead actor. 17:11.290 --> 17:12.580 So I'm going to keep that there. 17:12.580 --> 17:14.980 And it doesn't need to be inline. 17:15.490 --> 17:17.230 So I'm going to move it to the CPP. 17:20.290 --> 17:23.530 And if we're going to bind it it has to be a U function. 17:23.530 --> 17:29.560 And we can bind it here with add dynamic as it's a dynamic multicast. 17:29.560 --> 17:35.920 So we'll use this and at U debuff Niagara component on owner death. 17:35.950 --> 17:36.670 Okay. 17:36.700 --> 17:41.290 So that is basically everything we need here. 17:41.320 --> 17:47.060 Now another thing I want to do is broadcast our on death Delegate. 17:47.090 --> 17:53.210 Now that's something we could do in Oracle database because we know when we're going to die. 17:53.240 --> 17:54.620 In fact, handle death. 17:54.620 --> 17:58.040 Multicast is the perfect place to broadcast this. 17:58.070 --> 18:06.140 We can take on death dot broadcast and broadcast this because we have to broadcast that dead actor. 18:06.320 --> 18:09.560 And with that, everything is tied together. 18:09.560 --> 18:17.420 And we can add one of these debuff Niagara components to our Aurora character Base class and construct 18:17.420 --> 18:17.930 it. 18:18.710 --> 18:25.190 So here in Aurora Character Base, I'm going to add this to the protected section all the way down at 18:25.190 --> 18:34.400 the bottom we're going to make a T object pointer of type U debuff Niagara component. 18:34.940 --> 18:43.040 I'm going to add the forward declaration and I'm going to call this fire debuff component. 18:44.030 --> 18:51.130 And in fact our fire debuff is called burn, so I'm going to call it Burn Debuff component sounds cooler. 18:51.160 --> 18:55.780 I'm going to give it a Uproperty with visible anywhere so we can see it. 18:55.780 --> 18:58.180 And we'll be able to set its properties. 18:58.180 --> 19:02.110 And I'm going to construct this in aura character based CPP. 19:02.500 --> 19:06.460 So I'm going to do this at the top just under primary actor tick. 19:06.490 --> 19:15.340 I'm going to use Createdefaultsubobject and specify you debuff Niagara component. 19:15.340 --> 19:20.950 So see our aura character base is dependent on Debuff Niagara component, which is a good reason to 19:20.980 --> 19:25.570 not let debuff Niagara component be dependent on Aura character base. 19:25.570 --> 19:27.640 We don't want that circular dependency. 19:27.670 --> 19:36.220 We're going to give it the name of Burn Debuff component and we're going to attach it. 19:36.220 --> 19:38.200 So Burn Debuff component. 19:38.200 --> 19:40.150 We're going to call set up attachment. 19:40.180 --> 19:42.280 We're going to attach it to get root component. 19:42.280 --> 19:44.470 So we'll attach it to the root. 19:44.470 --> 19:50.560 We'll still be able to adjust it and we need to set its debuff tag right. 19:50.560 --> 19:56.140 So burn debuff component debuff tag will set it. 19:56.140 --> 20:01.390 And we're going to need F or a gameplay tags. 20:01.780 --> 20:07.450 We'll call Get and get debuff and burn. 20:07.810 --> 20:13.540 And we made Debuff Niagara component edit defaults only didn't we. 20:13.570 --> 20:18.100 Now we can set it to visible anywhere because we don't need to set it from blueprint. 20:18.130 --> 20:20.080 We're just going to set it here. 20:20.080 --> 20:27.340 And with that, all we need to do is set a Niagara system on this component and test it out. 20:27.340 --> 20:31.510 So let's try it okay. 20:31.510 --> 20:33.460 So we're back in the editor. 20:33.460 --> 20:39.670 And really what I need to do is open up my character classes. 20:39.670 --> 20:44.750 I need to go into character and BP enemy base. 20:44.750 --> 20:47.210 And here's my burn debuff component. 20:47.210 --> 20:51.170 We can set the Niagara system asset, and I'm going to search for fire. 20:51.170 --> 20:57.560 And as fire will do because I have that nice fire which looks like this. 20:57.590 --> 20:58.400 We've seen it. 20:58.430 --> 21:01.160 We're going to use this now. 21:01.160 --> 21:08.360 We're going to need to adjust it relative to the capsule, but we're going to need to adjust it per 21:08.390 --> 21:08.780 enemy. 21:08.810 --> 21:09.620 Right. 21:09.620 --> 21:17.600 So what I want to do is go to my goblin, just edit that and get my burn debuff. 21:17.600 --> 21:21.410 And what I can do is take auto activate and check it. 21:21.410 --> 21:23.240 And now I'll see what it looks like. 21:23.240 --> 21:25.580 And then I can move it around. 21:25.790 --> 21:29.720 And that way I can make their heads be on fire. 21:29.750 --> 21:32.210 I could put it on their chest like this. 21:33.560 --> 21:36.350 I kind of like their heads being on fire. 21:36.380 --> 21:37.670 I think it's funny. 21:37.670 --> 21:45.090 So I'm gonna put it there, uncheck auto activate, compile, save and then I can go into my other enemies 21:45.090 --> 21:49.200 like Goblin slingshot and do the same thing. 21:49.200 --> 21:56.940 So I'm going to take the burn debuff, search for auto activate, check that, and then make sure their 21:56.940 --> 21:58.260 head is on fire. 21:58.290 --> 22:07.440 I'll do the same thing for the shaman opening that taking the burn debuff. 22:07.440 --> 22:12.570 Search for auto activate, check it and make sure this head is on fire. 22:12.570 --> 22:15.360 It's got a wooden mask, so that's pretty flammable. 22:15.360 --> 22:16.650 I think that looks good. 22:16.650 --> 22:21.030 And we're going to do it for Ghoul Demon. 22:21.420 --> 22:22.170 And that's it. 22:22.170 --> 22:23.460 Let's go to ghoul. 22:29.370 --> 22:30.900 And we'll select it. 22:32.130 --> 22:34.020 Auto activate on. 22:34.050 --> 22:40.650 We can just go ahead and make its head burn or really doesn't matter. 22:40.650 --> 22:43.000 We can make it back here. 22:43.870 --> 22:50.260 I think it kind of looks cool if it's back is on fire, maybe even down on the back a little more. 22:52.510 --> 22:53.980 Something like that. 22:54.640 --> 22:55.150 Okay. 22:55.180 --> 23:02.350 Checking that, I also want to check it so the auto activate isn't active on any of them. 23:02.350 --> 23:06.130 And finally I'll go back to my daemon. 23:06.130 --> 23:09.580 We have two daemons, so we need to add it to both of them. 23:11.440 --> 23:16.660 In hindsight, it would have been nice if I had just lowered it on the base and then raised it for the 23:16.660 --> 23:23.020 bigger enemies, because most of the smaller ones are about the same height, so the daemons can be 23:23.020 --> 23:24.130 on fire. 23:25.840 --> 23:30.250 Can I uncheck that and set it for the last enemy? 23:34.180 --> 23:35.380 Like so. 23:36.040 --> 23:44.440 Okay, so now that those have their debuffs, the last thing is to set it for aura, because maybe aura 23:44.470 --> 23:46.150 might get burned too. 23:46.180 --> 23:54.670 So I'm going to go to aura and select Aura Burn debuff check auto activate for that. 23:56.500 --> 24:03.010 And of course I have to set the Niagara system to NS fire. 24:03.340 --> 24:05.890 And we can see what it looks like for aura. 24:10.030 --> 24:14.380 And I think burning Aura about like that is going to look good. 24:14.980 --> 24:15.610 Okay. 24:15.610 --> 24:19.450 With all that we can go ahead and test things out. 24:20.800 --> 24:23.680 So I have 100% chance to burn. 24:23.950 --> 24:25.930 Even aura has 100% chance to burn. 24:25.960 --> 24:26.650 Look at that. 24:26.650 --> 24:28.510 I'm going to fix that real quick. 24:30.610 --> 24:32.410 Auto activate off. 24:32.410 --> 24:33.340 There we go. 24:34.030 --> 24:37.870 Okay, so all we need to do is cause some damage. 24:37.870 --> 24:41.450 And there we have an enemy getting burned. 24:43.700 --> 24:45.740 And it died and the flames went away. 24:45.770 --> 24:50.510 Of course, it was there for five seconds, which is our debuff duration. 24:50.510 --> 24:55.550 But if we set our debuff duration to 10s, then we can really test it out. 24:56.630 --> 25:00.410 Because then we'll see that the enemy will die. 25:00.800 --> 25:04.760 It hasn't been 10s yet and it was deactivated. 25:04.790 --> 25:12.290 We can also test, say one second and make sure that the debuff only lasts one second. 25:13.040 --> 25:13.850 There it goes. 25:13.850 --> 25:14.810 Perfect. 25:14.810 --> 25:18.020 And that's looking pretty good. 25:18.020 --> 25:20.780 So with that we now have debuffs. 25:25.940 --> 25:27.260 We have burning. 25:27.290 --> 25:28.400 Excellent. 25:29.150 --> 25:32.420 I'll go ahead and leave that debuff duration at five. 25:32.420 --> 25:36.800 And with that we can go ahead and close all these other tabs. 25:36.830 --> 25:39.680 We now have a working burn debuff. 25:39.680 --> 25:39.690 Off. 25:39.690 --> 25:46.830 And even though my game play ability has 100% chance to burn, we can lower that to whatever we want. 25:46.830 --> 25:53.970 And now our debuff system is in place, and it's actually quite robust because all we need to do to 25:54.000 --> 25:59.370 add a debuff to a gameplay ability is just set parameters and everything else is in place. 25:59.370 --> 26:05.370 If we go to our abilities lightning electrocute, we'll see in the class defaults, well, we don't 26:05.370 --> 26:12.900 see anything, but if we change the class settings and inherit from aura damage gameplay ability. 26:15.450 --> 26:16.320 Then we'll see. 26:16.350 --> 26:24.180 In class defaults, we can set debuff chance and other parameters, and once we set the damage type, 26:24.210 --> 26:26.130 our debuff will just work. 26:26.130 --> 26:28.500 So we have a really nice system in place. 26:28.500 --> 26:35.460 It took some work to set up, but it will take very little work to use it as we create our game. 26:35.460 --> 26:39.780 So great job on this one and I'll see you in the next video.