Wouldn't it be simpler to use a set that both applies the desired behavior and removes the other one instead? Or even use a morph ability, which allows for better customization in the long run.
Alternatively, the above suggestion of a "Behavior" type ability like the ghost cloak would work perfectly, as you could simply have your ground buff (present by default) validate the absence of it to disable the ground buff when needed.
Depends how many splash upgrades and +% damage upgrades he wants since with abilities with over 3+ compounded variables using triggers becomes more efficient.
That's where the upgrades section of the data editor comes into play! You could very easily setup an upgrade with with as many levels as you'd like (though I believe they're capped at 100 if memory serves right) that extends the radius of your search area or the damage values. All of that without having to touch your ability or its effects at all. I'm sure there might be very specific scenarios where triggers would get the job done more easily, but everything mentioned so far would better be done with just data.
i think its easier to just have a SET effect and simply add requirements to each effect in the set effect. ???
Yes, that would be the most logical way to to it. No need for any trigger, just your ability and the upgrades for your optional effects. Essentially, it would probably look like this:
You might want to set it up differently, for instance if you want the targets of your splash to also receive the burn effect, but otherwise it should be as simple as that. Or even replace the search area effect with a damage effect (excluding the target) if you want splash with multiple radius values. It's very flexible, but you get the idea.
The advantage of using a behavior is efficiency, yes, but also the ability to easily modify your ability with actors. For instance, you could easily add sounds & visual FX when your units take damage by simply adding actors without modifying your existing setup.
Now, as for what you need:
1 Damage Effect.
1 Behavior.
In the data editor, open the effects tab and create a new one.
Set its type to "Damage" and give it a name
Next, you want to change its damage in the "Combat" tab of your damage effect (under the label Amount). There's plenty of other fields to customize your damage effect which you can freely explore.
The next step is creating a behavior that uses this effect. Go to the behaviors tab and create a new one.
Set its type to "Buff" and give it a name
There's 4 values you need to make sure are setup properly. Duration, Period, Period Count, and periodic effect.
In the stats tab of your behavior, make sure the duration is set to 0 (meaning infinite).
Also in the stats tab, make sure the period count is set to -1 (a period that repeats for as long as the behavior is active)
Last thing in that same tab, set the period value to the desired delay between each application of your damage effect (i.e.: setting it to 43 would trigger your periodic effect every 43 seconds. Chances are you'll want a value of 1 or so)
Now that you have a behavior of infinite duration with a periodic event looping every X second, all you need is to setup what effect will be fired. Go to the effects tab of your behavior and link the "effect - periodic" to the damage effect you previously created.
And that's it for your behavior. The trigger part is a lot easier and would probably look similar to this (those being 2 triggers)
Any unit enters <your region here>
Apply 1 <your behavior here> to triggering unit
Any unit exits <your region here>
Remove 1 <your behavior here> from triggering unit
Create a behavior with no duration and a periodic event. In the Effects tab, link your periodic event effect to a damage effect. Adjust the period/damage to have the desired "dps". You'll have to use triggers if you intend to use regions more complex than circles, and it's as simple as applying the behavior on units when they enter the region, and removing it when they exit.
I realize this might sound like a traditional good spirited answer, but I sort of like them all in their own way. Lately though, I've begun experimenting with the Ulaan cave tileset for a little project and I find it rather fascinating. It is both extremely limited in the variety of textures and props that fit well with it, that it almost forces you to be a little creative in how you use terrain geometry, texture blending, lighting and a few other neat tricks I've discovered along the way. The results can be quite surprising. I've attached a screenshot of a small area that illustrates this.
Heroes reviving automatically is quite simple. On the behavior itself is a 18.5s period and an effect that "revives" the hero when this period is expired. Just remove that.
Now for animations, that's the trickier part although manageable. What you want to do is apply the death animation as usual when your hero dies but pause it before he disappears. You can do that with a timer within the actor for that behavior. (if you're working with default data, it's called "HeroIncap (Unnamed)". When your behavior is removed, simply unpause animations. That'll work for most units but not all of them. Some models, such as Nova, have no death animation but instead use a 2nd model which has that specific animation. So in order for the animation to work, you'll first need to do a model swap, and then swap it back to its default model when the behavior is removed. You can start playing relevant animations within the unit's actor events by detecting when its model is being swapped.
See attached images for more details.
p.s.: Swapping model on the fly during gameplay can cause problems for certain users, so I recommend preloading the "death" model in a trigger.
Since this trigger is called "Boss Waves", I'm going to assume you have another one that handles your regular enemy waves. In which case, this is a simple logic problem, fortunately.
You start by comparing your spawn count to how many players are in the players' team multiplied by 20 (why?). Let's just call that amount of players "x". So essentially if spawn count <= 20x you do your spawning thing. I'm guessing spawn count starts at 0 so it goes through your condition.
Then, you add to your spawn count that exact same value you were comapring it with, so it becomes 20x as well. And then monsters are spawned. Everything is well and your trigger runs again 1.5 sec later. The first condition is run again and this time you check if your spawn count (now worth 20x) is <= 20x. Which it is! And thus a 2nd set of monsters is spawned. Your spawn count variable is incremented to 40x and won't go through your comparison next time the trigger runs.
Now I don't know the mechanics of your map but if the only thing this trigger is meant to do is spawn 1 boss monster for each player, then you can do away with the periodic check and spawn count. Instead, just shrink your trigger to the basics and use a "run trigger (check conditions)" action instead of turning it on/off.
A simple trigger like this should be all you need.
0
Wouldn't it be simpler to use a set that both applies the desired behavior and removes the other one instead? Or even use a morph ability, which allows for better customization in the long run.
Alternatively, the above suggestion of a "Behavior" type ability like the ghost cloak would work perfectly, as you could simply have your ground buff (present by default) validate the absence of it to disable the ground buff when needed.
0
That's where the upgrades section of the data editor comes into play! You could very easily setup an upgrade with with as many levels as you'd like (though I believe they're capped at 100 if memory serves right) that extends the radius of your search area or the damage values. All of that without having to touch your ability or its effects at all. I'm sure there might be very specific scenarios where triggers would get the job done more easily, but everything mentioned so far would better be done with just data.
0
Yes, that would be the most logical way to to it. No need for any trigger, just your ability and the upgrades for your optional effects. Essentially, it would probably look like this:
You might want to set it up differently, for instance if you want the targets of your splash to also receive the burn effect, but otherwise it should be as simple as that. Or even replace the search area effect with a damage effect (excluding the target) if you want splash with multiple radius values. It's very flexible, but you get the idea.
0
The advantage of using a behavior is efficiency, yes, but also the ability to easily modify your ability with actors. For instance, you could easily add sounds & visual FX when your units take damage by simply adding actors without modifying your existing setup.
Now, as for what you need:
And that's it for your behavior. The trigger part is a lot easier and would probably look similar to this (those being 2 triggers)
0
@Lonami: Go
Create a behavior with no duration and a periodic event. In the Effects tab, link your periodic event effect to a damage effect. Adjust the period/damage to have the desired "dps". You'll have to use triggers if you intend to use regions more complex than circles, and it's as simple as applying the behavior on units when they enter the region, and removing it when they exit.
0
I realize this might sound like a traditional good spirited answer, but I sort of like them all in their own way. Lately though, I've begun experimenting with the Ulaan cave tileset for a little project and I find it rather fascinating. It is both extremely limited in the variety of textures and props that fit well with it, that it almost forces you to be a little creative in how you use terrain geometry, texture blending, lighting and a few other neat tricks I've discovered along the way. The results can be quite surprising. I've attached a screenshot of a small area that illustrates this.
0
Heroes reviving automatically is quite simple. On the behavior itself is a 18.5s period and an effect that "revives" the hero when this period is expired. Just remove that.
Now for animations, that's the trickier part although manageable. What you want to do is apply the death animation as usual when your hero dies but pause it before he disappears. You can do that with a timer within the actor for that behavior. (if you're working with default data, it's called "HeroIncap (Unnamed)". When your behavior is removed, simply unpause animations. That'll work for most units but not all of them. Some models, such as Nova, have no death animation but instead use a 2nd model which has that specific animation. So in order for the animation to work, you'll first need to do a model swap, and then swap it back to its default model when the behavior is removed. You can start playing relevant animations within the unit's actor events by detecting when its model is being swapped.
See attached images for more details.
p.s.: Swapping model on the fly during gameplay can cause problems for certain users, so I recommend preloading the "death" model in a trigger.
0
Since this trigger is called "Boss Waves", I'm going to assume you have another one that handles your regular enemy waves. In which case, this is a simple logic problem, fortunately.
You start by comparing your spawn count to how many players are in the players' team multiplied by 20 (why?). Let's just call that amount of players "x". So essentially if spawn count <= 20x you do your spawning thing. I'm guessing spawn count starts at 0 so it goes through your condition.
Then, you add to your spawn count that exact same value you were comapring it with, so it becomes 20x as well. And then monsters are spawned. Everything is well and your trigger runs again 1.5 sec later. The first condition is run again and this time you check if your spawn count (now worth 20x) is <= 20x. Which it is! And thus a 2nd set of monsters is spawned. Your spawn count variable is incremented to 40x and won't go through your comparison next time the trigger runs.
Now I don't know the mechanics of your map but if the only thing this trigger is meant to do is spawn 1 boss monster for each player, then you can do away with the periodic check and spawn count. Instead, just shrink your trigger to the basics and use a "run trigger (check conditions)" action instead of turning it on/off.
A simple trigger like this should be all you need.
If any of my assessments were wrong, you may want something different however.