The cost field by itself doesn't support this kind of behavior, so you would need a workaround. Possible ways to try would be either restoring the charges with a Modify Unit effect after a behavior expires. You would need to figure out, how to check, if the charges are depleted (probably using validators or requirements), then a behavior could be applied executing the effect after a delay, which in turn restores the charges.
Another possibility would be to adjust the recharge rate of the ability manually, for example via trigger. This would require checking the charges as well. If this should be difficult in data, it can easily be checked via trigger, or you could even simulate the ability charges with a behavior system.
I have no idea, if this is in any way related to SC2, but in WC3's Jass there was a type called Handle as well, and it basically was the parent type of most other complex types (unit, unitgroup, player, whatever). For example, you might be able to store a unit in a handle variable, then later override it with a playergroup. But probably not, since that would either require implicit typecasting for handles (which I doubt is supported) or conversion functions, which don't exist.
In WC3, these "existed" (or rather, were created) and were widely used in the return-bug era, where any handle could be converted to an integer and back (presumably the handle's internal ID).
Now, in SC2 the handle type could still be parent to all these other types, but since it is not used by any function and cannot be converted to anything (and no returnbug exists), we probably cannot do anything useful with it.
Turrets are objects useable by Units, which may or may not have Weapons attached to them. Turrets are capable of rotation, either by themselves or in the direction of the attached weapon. Turrets allow their attached weapons to shoot in the direction the Turret is facing, regardless of the facing angle of the attached unit.
Turret actors are linked to these Turret objects and are capable of interacting with it, to a limited extend. They also need an associated Model or Unit actor (usually the main actor of the unit) to pass on these interactions, so you can actually see the effect of your turret.
For an actor/model to be able to function with a turret, it needs to be set up with a TurretZ attachment point. If the model is properly configured, the unit is linked to the Turret object and the Turret has an associated Turret Actor and Model Actor, the unit model, or parts of it if it is set up that way, is capable of turning with the turret, independent of the unit's real facing.
This interaction is limited to either passive rotation or rotation connected to a Weapon. To my knowledge, there is no way to affect the rotation of a turret with an ability or via trigger. There are a couple of workarounds, though. One possibility is shown in the test map in this thread: A dummy unit is spawned by the ability and attacked by a hidden weapon, which is connected to a turret. Another possibility would probably be to use triggers to send rotation actor messages constantly to simulate turret rotation.
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
You can try to use a site operation for this. There is an existing one called SOpTargetUnitZ, which would set the height to the height of the target unit. Obviously, thats not very useful here, but you can create a copy of that and change the unit to Source or Caster. Then just add your newly created SOpCasterUnitZ to your action actor's impact POINT site operations.
For your persistent, make sure the Offset Start and Offset End locations point to the location of the BC and the target point respectively. This kind of erratic behavior suggests, it might reference the missile and the target point instead. Try all variations of source/origin/caster point for the start and target point for end, see if it makes a difference. If the problem persists, specify the effect, whose points should be used.
EDIT EDIT: Impact Effect should work... according to the wiki, Launch Effect applies an effect where the missile was launched, and Impact Effect applies an effect where the missile targeted. I targeted the target unit, so this should work.
Both effects are capable of hitting the caster or the target, that depends on the target options you set for them. Its more about WHEN these effects are executed.
1) I doubt, the model has any attachment points, but you can add an additional Local Offset site operation to adjust the position to your liking.
2) Check the very first event of the Beam. Do you see the "ContentPlayOnce"? Uncheck that. (You probably used BeamSimpleAnimationStyleOneShot instead of -Continuous as a parent).
Try SOpTargetPoint as your impact site operation. Also set the Host Launch Subject to _Selectable.
And a note: Currently, the beam is not MUI (if 2 beams are created, both will disappear when the first persistent ends) and it will not play its death animation, if it has one.
I would suggest changing the destroy event to:
0
The cost field by itself doesn't support this kind of behavior, so you would need a workaround. Possible ways to try would be either restoring the charges with a Modify Unit effect after a behavior expires. You would need to figure out, how to check, if the charges are depleted (probably using validators or requirements), then a behavior could be applied executing the effect after a delay, which in turn restores the charges.
Another possibility would be to adjust the recharge rate of the ability manually, for example via trigger. This would require checking the charges as well. If this should be difficult in data, it can easily be checked via trigger, or you could even simulate the ability charges with a behavior system.
Does this help you in any way?
0
I have no idea, if this is in any way related to SC2, but in WC3's Jass there was a type called Handle as well, and it basically was the parent type of most other complex types (unit, unitgroup, player, whatever). For example, you might be able to store a unit in a handle variable, then later override it with a playergroup. But probably not, since that would either require implicit typecasting for handles (which I doubt is supported) or conversion functions, which don't exist.
In WC3, these "existed" (or rather, were created) and were widely used in the return-bug era, where any handle could be converted to an integer and back (presumably the handle's internal ID).
Now, in SC2 the handle type could still be parent to all these other types, but since it is not used by any function and cannot be converted to anything (and no returnbug exists), we probably cannot do anything useful with it.
0
Usually you can find all sorts of error messages in the Text Editor (F8). Not sure, where it could be located otherwise, maybe a validator?
0
Hey.
Sorry, but you might need to add a little more information (and maybe an actual question), so we can help you.
I am not sure, if I understand the design of the spell entirely, so correct me, if I am wrong:
Correct so far?
Also, what exactly is your problem? What did you try, what did you get to work already and what exactly doesn't work?
0
Turrets are objects useable by Units, which may or may not have Weapons attached to them. Turrets are capable of rotation, either by themselves or in the direction of the attached weapon. Turrets allow their attached weapons to shoot in the direction the Turret is facing, regardless of the facing angle of the attached unit.
Turret actors are linked to these Turret objects and are capable of interacting with it, to a limited extend. They also need an associated Model or Unit actor (usually the main actor of the unit) to pass on these interactions, so you can actually see the effect of your turret.
For an actor/model to be able to function with a turret, it needs to be set up with a TurretZ attachment point. If the model is properly configured, the unit is linked to the Turret object and the Turret has an associated Turret Actor and Model Actor, the unit model, or parts of it if it is set up that way, is capable of turning with the turret, independent of the unit's real facing.
This interaction is limited to either passive rotation or rotation connected to a Weapon. To my knowledge, there is no way to affect the rotation of a turret with an ability or via trigger. There are a couple of workarounds, though. One possibility is shown in the test map in this thread: A dummy unit is spawned by the ability and attacked by a hidden weapon, which is connected to a turret. Another possibility would probably be to use triggers to send rotation actor messages constantly to simulate turret rotation.
0
Resetting the events to default works wonders in this case.
0
usually in the Assets/Textures folder
0
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
0
You can try to use a site operation for this. There is an existing one called SOpTargetUnitZ, which would set the height to the height of the target unit. Obviously, thats not very useful here, but you can create a copy of that and change the unit to Source or Caster. Then just add your newly created SOpCasterUnitZ to your action actor's impact POINT site operations.
0
The site operation has to be added to the Host Impact Site Operations, below the SOpTargetPoint.
0
For your persistent, make sure the Offset Start and Offset End locations point to the location of the BC and the target point respectively. This kind of erratic behavior suggests, it might reference the missile and the target point instead. Try all variations of source/origin/caster point for the start and target point for end, see if it makes a difference. If the problem persists, specify the effect, whose points should be used.
0
Both effects are capable of hitting the caster or the target, that depends on the target options you set for them. Its more about WHEN these effects are executed.
0
1) I doubt, the model has any attachment points, but you can add an additional Local Offset site operation to adjust the position to your liking.
2) Check the very first event of the Beam. Do you see the "ContentPlayOnce"? Uncheck that. (You probably used BeamSimpleAnimationStyleOneShot instead of -Continuous as a parent).
0
@Kabelkorven: Go
You can use an autocast ability or an enumerate area validator on a behavior for example.
0
Try SOpTargetPoint as your impact site operation. Also set the Host Launch Subject to _Selectable.
And a note: Currently, the beam is not MUI (if 2 beams are created, both will disappear when the first persistent ends) and it will not play its death animation, if it has one.
I would suggest changing the destroy event to: