Hello everyone, i've searched through this forum and was wondered how all suggestions about aura ends as "reapply buff every 0.1-1 second".
This is another solution, based on validators and here aura-buff lasts forever until aura should stop working.
Notes:
We will make simple slow aura without gfx effects, because of beginner difficulty.
We will call this aura Slowness, and it will slowdown enemy units by 60%.
We will give this aura to marine, just to restory balance in starcraft.
We won't copy anything and all our effects and other data should be created from scratch (right click -> add).
Editor properties: Table View: Show Field Categories, Combine Structure Values
Test: Check *Marine* in units section, first field should be named as: Ability: Abilities +
Let's start!
Creation:
Behaviors:
1. Add new *behavior* with type *buff* and name Slowness (Aura).
Units with this behavior will carry our aura through the game.
Don't forget to press *Suggest*, so our objects IDs will be nice and comfy too.
2. Add another *behavior*, type *buff* and name it Slowness.
This one will be applied to units being slowed.
We'll edit them later, time to add some effects:
Effects:
1. Add effect Slowness (Search) of type Search Area
This is main effect, it will search units to apply *Slowness* behavior to them, with help of
2. Slowness (Search Apply) of type Apply Behavior
Because Slowness (Search) can't apply anything, it will use this one.
Ok, leave effects as is, we will also return to them later.
Validators:
(Green plus sign > Edit Game Data > Validators)
Main reason of this tutorial is the validators, they will do main job for us:
1. Add validator named Slowness (Aura Check) of type Unit Compare Behavior Count
This validator will check if aura unit still alive and his aura is working:
set Validator:Behavior to Slowness (Aura)
set Validator:Compare to Greater Than
and Validator:Unit + set to (None):Source
We will link to later to *Slowness* behavior.
It checks if *Source* (that one who applied behavior ) has Slowness (Aura), and if he hasn't it, then this validator result an error
2. Add validator Slowness (Range) of type Location Range
in Target: Location + put Target Unit
Validator: Compare => Less Than Or Equal To
Validator: Range => *3*
Validator: Value + set to (None): Source
This one we will link to later to *Slowness* behavior.
And it's easy too: we take *Source* (that one who applied behavior ) and check distance between it and our target - should be less or equal 3.
3. Add another validator Source Alive of type Unit Filters
in Validator: Filters set Dead:Excluded
Validator: Value + set to (None): Source
This one doesnt have "Slowness" in its name because it can be applied to any effect or behavior, it just checks if source unit alive or not, we don't want our aura work after source unit's death.
4. Next validator is Slowness (Not Exist) with same type Unit Compare Behavior Count
and only one field: Validator: Behavior should be *Slowness*
This is more than easy, we just check if target unit dont have *Slowness* behavior because we dont want reapply it
5. Last validator is Enemies (Target Filter) of type Unit Filters
at Validator:Filters check to *Excluded* following parameters: *Dead*, *Structure*, *HarvestableResource*, *RawResource*, *Missile*, *Destructible*, *Item*, *UnderConstruction*, *Invulnerable*
and in this field uncheck: *Player*, *Ally* and *Neutral*
Again, no *Slowness* in the name because it can be applied to any effect or behaviuor, it just declares who're enemy units to us.
Combination:
We've done validators, time to go back through effects to behaviors:
Effects
1. Slowness (Search)
at Search: Areas add new area with effect Slowness (Search Apply) and range: 3
Should look like this:
This effect will search units and apply Slowness (Search Apply) to them, within range 3 (should be same or less as we declared in Slowness (Range) validator.)
Main difference - this effect search in range 3, and validator checks if unit goes out of range.
If you make effect 5 and validator 3 -> then search area would apply slow and validator will remove it, resuling in blinking behavior with no-effect in 3-5 range.
If you make validator 5 and effect 3 -> then aura would apply on units within 3 range, but they will be slowed until there will be more than 5 range between them and aura-holder.
2. Slowness (Search Apply)
Effect: Behavior => *Slowness*, hope you understand why :)
in Effect: Validators + add these validators:
Enemies (Target Filter), because we want our aura apply to enemies
and Slowness (Not Exist), just as i said above - we dont want reapply our *Slowness* every 0.1-1 second.
Effects are done, lets go back to *behaviors* panel:
Behaviors:
1. Slowness. Our support *behavior*, that one who actually slow units.
Behavior: Modification+ -> *Movement* -> Movement Speed Multiplier set to 0.4 (40% of original unit speed)
in Behavior: Validators (Remove) + add these:
Source Alive
Slowness (Range)
Slowness (Aura Check)
if any of these validators result an error, our behavior will be removed, that's the core thing, and that's why we don't need to reapply behavior every 1 second.
other fields:
Behavior: Alignment - *Negative*
UI: Icon - put a nice picture here
UI: Tooltip - here you should write something like:
This units slowed by <d ref="100 - (Behavior,Slowness,Modification[0].MoveSpeedMultiplier[0]*100)"/>%
Note: <d ref="Behavior,Slowness,Modification[0].MoveSpeedMultiplier[0]"/>% will result *40%*, but units slows by 60% (40% is value of unit speed under this behavior). thats why we add "100 -"
2. Slowness (Aura) Our main aura *behavior*.
Behavior: Alignment - *Positive* ;)
Effect: Effect - Periodic => Slowness (Search)
Stats: Period => 0.1 or 1 sec
This one is pretty standart, main difference is that Period affects only new units, old ones are handled by behaviors
Test
In Units section select *Marine* and add to Behavior: Behaviors + our pretty Slowness (Aura)
In terrain editor put 10-30 zerglings(player 2) and 1-5 marines (player 1) -> all should work here.
Problems:
No behavior icon on zerglings => you messed up something with effects/behaviors
Icon on zergling is blinking => you messed up with validators
Slow effect doesn't dissappear even if should => you messed up with validators again
All works, but there's no graphics here! => Ohohoho, post a comment :D
Ending:
Any PMs with grammatical fixes would be gladly appreciated, i hope you can understand what I've written here :)
Anyway, post a comments, feedback, etc
Hello everyone, i've searched through this forum and was wondered how all suggestions about aura ends as "reapply buff every 0.1-1 second".
This is simply not right! So, in this tutorial, I'll show you how to make your aura truly one, where aura-buff lasts forever until aura should stop working.
You just cannot say its "not right", implying that your way of doing it would be the correct one in all cases. The reapplying stuff works, and its the method Blizzard uses (granted, they don't always use the best way to do things). Your method is not necessarily any better, and even if it is, it doesn't make the old method wrong or obsolete.
Also, you don't even attempt to explain, why your method would be "right", aka better than the old method. I assume, you are mostly referring to the needed buffer time for the old method, while yours will always work "exactly", and to the fact, that your method doesn't re-apply the behavior on units, which already have it.
However, usually a buffer time makes sense. Auras mostly don't need to be perfectly accurate, and if it always works exactly, the behavior would turn on and off a lot more, if units step out of the aoe just a tiny bit and immediately re-enter it. Especially when animations are involved, this would produce constant creation and destruction of behaviors and associaded models, as opposed to using a buffer time. WC3 auras for example had a buffer time of about 2 to 4 seconds.
Re-applying the buff isn't necessarily a bad thing either. If you are worried about performance, I hardly think an additional check, if the buff is already present AND periodic distance checks to the caster for affected units are superior here.
Don't get me wrong, the method is great, if you need its specific advantages, but from what I understand, you cannot just say, it is the right way to create auras and other ways are wrong. Maybe you didn't even mean it like that, but it sure looks that way :)
There always will be alternatives, thats just the way the data editor is structured. You can create many things in many different ways. Hell, you could make an aura with 2 transient autocast abilities, applying the buff on single units with no cooldown. One with a max range applying the buff and one with a min range removing it again. Granted, it would have some problems, but probably nothing you cannot fix :D
Hello everyone, i've searched through this forum and was wondered how all suggestions about aura ends as "reapply buff every 0.1-1 second".
This is another solution, based on validators and here aura-buff lasts forever until aura should stop working.
Notes:
Editor properties: Table View: Show Field Categories, Combine Structure Values
Test: Check *Marine* in units section, first field should be named as: Ability: Abilities +
Let's start!
Creation:
Behaviors:
1. Add new *behavior* with type *buff* and name Slowness (Aura).
Units with this behavior will carry our aura through the game.
Don't forget to press *Suggest*, so our objects IDs will be nice and comfy too.
2. Add another *behavior*, type *buff* and name it Slowness.
This one will be applied to units being slowed.
We'll edit them later, time to add some effects:
Effects:
1. Add effect Slowness (Search) of type Search Area
This is main effect, it will search units to apply *Slowness* behavior to them, with help of
2. Slowness (Search Apply) of type Apply Behavior
Because Slowness (Search) can't apply anything, it will use this one.
Ok, leave effects as is, we will also return to them later.
Validators:
(Green plus sign > Edit Game Data > Validators)
Main reason of this tutorial is the validators, they will do main job for us:
1. Add validator named Slowness (Aura Check) of type Unit Compare Behavior Count This validator will check if aura unit still alive and his aura is working:
We will link to later to *Slowness* behavior.
It checks if *Source* (that one who applied behavior ) has Slowness (Aura), and if he hasn't it, then this validator result an error
2. Add validator Slowness (Range) of type Location Range
This one we will link to later to *Slowness* behavior.
And it's easy too: we take *Source* (that one who applied behavior ) and check distance between it and our target - should be less or equal 3.
3. Add another validator Source Alive of type Unit Filters
This one doesnt have "Slowness" in its name because it can be applied to any effect or behavior, it just checks if source unit alive or not, we don't want our aura work after source unit's death.
4. Next validator is Slowness (Not Exist) with same type Unit Compare Behavior Count and only one field: Validator: Behavior should be *Slowness* This is more than easy, we just check if target unit dont have *Slowness* behavior because we dont want reapply it
5. Last validator is Enemies (Target Filter) of type Unit Filters
Again, no *Slowness* in the name because it can be applied to any effect or behaviuor, it just declares who're enemy units to us.
Combination:
We've done validators, time to go back through effects to behaviors:
Effects
1. Slowness (Search)
Should look like this:
This effect will search units and apply Slowness (Search Apply) to them, within range 3 (should be same or less as we declared in Slowness (Range) validator.)
Main difference - this effect search in range 3, and validator checks if unit goes out of range.
If you make effect 5 and validator 3 -> then search area would apply slow and validator will remove it, resuling in blinking behavior with no-effect in 3-5 range.
If you make validator 5 and effect 3 -> then aura would apply on units within 3 range, but they will be slowed until there will be more than 5 range between them and aura-holder.
2. Slowness (Search Apply)
Effects are done, lets go back to *behaviors* panel:
Behaviors:
1. Slowness. Our support *behavior*, that one who actually slow units.
if any of these validators result an error, our behavior will be removed, that's the core thing, and that's why we don't need to reapply behavior every 1 second.
other fields:
This units slowed by <d ref="100 - (Behavior,Slowness,Modification[0].MoveSpeedMultiplier[0]*100)"/>%
Note: <d ref="Behavior,Slowness,Modification[0].MoveSpeedMultiplier[0]"/>% will result *40%*, but units slows by 60% (40% is value of unit speed under this behavior). thats why we add "100 -"
2. Slowness (Aura) Our main aura *behavior*.
This one is pretty standart, main difference is that Period affects only new units, old ones are handled by behaviors
Test
In Units section select *Marine* and add to Behavior: Behaviors + our pretty Slowness (Aura)
In terrain editor put 10-30 zerglings(player 2) and 1-5 marines (player 1) -> all should work here.
Problems:
Ending:
Any PMs with grammatical fixes would be gladly appreciated, i hope you can understand what I've written here :)
Anyway, post a comments, feedback, etc
Nice tutorial, good to have an alternative, however:
You just cannot say its "not right", implying that your way of doing it would be the correct one in all cases. The reapplying stuff works, and its the method Blizzard uses (granted, they don't always use the best way to do things). Your method is not necessarily any better, and even if it is, it doesn't make the old method wrong or obsolete.
Also, you don't even attempt to explain, why your method would be "right", aka better than the old method. I assume, you are mostly referring to the needed buffer time for the old method, while yours will always work "exactly", and to the fact, that your method doesn't re-apply the behavior on units, which already have it.
However, usually a buffer time makes sense. Auras mostly don't need to be perfectly accurate, and if it always works exactly, the behavior would turn on and off a lot more, if units step out of the aoe just a tiny bit and immediately re-enter it. Especially when animations are involved, this would produce constant creation and destruction of behaviors and associaded models, as opposed to using a buffer time. WC3 auras for example had a buffer time of about 2 to 4 seconds.
Re-applying the buff isn't necessarily a bad thing either. If you are worried about performance, I hardly think an additional check, if the buff is already present AND periodic distance checks to the caster for affected units are superior here.
Don't get me wrong, the method is great, if you need its specific advantages, but from what I understand, you cannot just say, it is the right way to create auras and other ways are wrong. Maybe you didn't even mean it like that, but it sure looks that way :)
There always will be alternatives, thats just the way the data editor is structured. You can create many things in many different ways. Hell, you could make an aura with 2 transient autocast abilities, applying the buff on single units with no cooldown. One with a max range applying the buff and one with a min range removing it again. Granted, it would have some problems, but probably nothing you cannot fix :D
wow, wow, ok, sorry, count this as aggressive marketing? :D i've edited the post to add more neutrality
Would have advantages with multicasting. Wonder if aliases could be applied with the location range validator so any valid emitter counts.
Contribute to the wiki (Wiki button at top of page) Considered easy altering of the unit textures?
https://www.sc2mapster.com/forums/resources/tutorials/179654-data-actor-events-message-texture-select-by-id
https://media.forgecdn.net/attachments/187/40/Screenshot2011-04-17_09_16_21.jpg