If all else fails, use the "cargo behavior" field on the transport ability. Make that behavior kill the cargo when triggered, and add a validator that checks a dummy on the transport (i.e. a dummy buff you place on the transport when "casting" your kill ability). You have to modify all transport abilities you want to affect though.
If you mean "only 1 worm per Nydus Network", just place dummy buff or something on the Network and give the "spawn worm" ability a requirement that checks "dummy buff - completed at unit". Then find a way to remove the buff when the worm dies.
To replicate the SC1 Nydus the best solution would probably be to make an exact replica, and use a Teleport Unit effect instead of a transport ability.
You can do the 1-per-tick method, but that alone would still mean that once a unit is linked to a generator it stays linked until that one goes offline.
Buffs with a stack limit are automatically "replaced" when a new stack is meant to be applied. This can be set to keep the "oldest" buff (nothing gets replaced), but it can also be set to prefer the newest one, which even is the default afaik. All existing auras work by reapplying the buff before the previous stack expires, which in those cases simply refreshes the duration (as there are no initial effects or vitals modifiers involved)
What would then happen is that every unit would constantly be re-linked to whichever generator aura "ticked" most recently, producing a rather random distribution but ensuring the effect keeps going if one generator dies. Basically like stacking Psi Storms from multiple templar should work from what I can gather.
It greatly depends on how you want multiple generators to interact with eachother. You can use "markers" (and subsequent validators that check for them) to identify units. Mutalisk attacks and healing beams use them.
I can think of 2 basic approaches:
The first is to have each generator operate individually. Setting the maximum stack amount on your target buff to infinite allows generators to stack, while setting it to 1 (and setting the appropriate replacement rule) would basically make the generators "compete" for targets, distributing damage rather randomly amongst each other. (What happens then is that every time the aura effect ticks it reapplies the target buff, linking the target to the generator that just ticked. This would be happening several times per second for a decent aura)
The second method, which would work with BorgDragon's suggestion, is to have 2 seperate effect chains: 1 places the shield buff as discussed, the other checks for all targets in range and applies the shield restoration/distribution. You could either have all generators affecting the target simultaneously, hopefully producing an even damage distribution, or limit it to 1 generator per target.
Both methods allow the use of markers, exclusion of generator units from the effect (if desired), and some degree of control over how multiple generators interact. I think BorgDragon's method is more efficient for doing what you've explained, but the other one might be easier to use with a more complex chain of effects as you have a direct link between the shield buff and the shield-sharing mechanism.
How does your "learning" system work? Seems as if the requirement registers the dummy ability as "completed", so what happens if you change the requirement to call an ability not used by the unit?
Otherwise, why not place a dummy behavior on the unit to signal it has bought the upgrade, or is this a "hero" unit which you can revive after it dies?
You can apply a Modify Unit effect upon applying the shield buff that reduces shields by the amount given by your buff.
Use a Create Healer effect to restore shields. Use a cost of caster shields with a 1:1 ratio, and a near-infinite healing rate. And probably add some validators to stop it when not needed, compare with the medic/medivac.
If your actor responds to Behavior...ON/OFF with Create/Destroy, and you reapply the buff before the older stack expires the model shouldn't flicker.
Limit the target buff to 1 stack per caster. Be careful with BorgDragon's method as it will have some residual problems if units are in range of multiple generators, especially if one of them goes down.
Open a map with campaign dependencies enabled and find one of those. The Void Seeker (Zeratul's starship) has it as a useable ability. It somehow causes the first Launch Missile effect to "impact" prematurely, creating a Persistent effect that launches the secondary missiles. Probably a field on the Launch Missile effect or the missile unit's Mover.
If the ability already checks a validator, make an AND Combine Validator, to which you add the unit type comparison and whatever validator is already set on the ability.
If you can't figure out how to properly invert a validator you can always place it as the sole argument of another Combine validator, and check the appropriate flag on that.
If it's a search area effect you can use a target sorting method "sort by distance" as a "soft" solution. Limit the search to a maximum of 1 target to ensure only the closest unit is affected. The search also checks validators on the effect it's supposed to apply, so you can always use dummy buffs to "mark" units.
There's a field called "vitals received from damage" or so. I know you can find it on units and buff type behaviors, possibly on other things too. Usually classified under "combat".
Gaining health or shields from attacks would essentially equal %damage reduction, but you can do that with Damage Response buffs too. You can also use damage responses to trigger "flat" gains or %caster vitals ones, by triggering a Modify Unit effect. (The "vitals received" field scales with damage taken, and only with that)
1) What are UI splats? What are you trying to do? Does it work with other attachment points?
2) Have the attack/beam actor reference the intended target as the impact location. Reference an effect that executes on the target, or possibly use a Location actor (compare Collossus weapon, complicated and easy to get wrong)
3) Try a SetOpacity: 0 actor event with a model that works? Make sure the model is what causes the problem though.
And for your concept, how do you define "crossing the beam" with a single dummy unit? The only decent way I can think of is to have the HSM continuously launch linear collision-detecting missiles at the current target and react to their collision detection. This would probably be laggy as hell though, unless it's limited to few instances per map ("hero" ability etc)
I did manage to make a (rather choppy) replica of the original Colossus attack once, where the beam sweeps from one target to the next. I've never made a "collision-detecting" projectile though, and to give the impression of a constant searching beam you'd need more pewpewpew than a battlecruiser.
Does the missile have to strike the unit, or the surrounding area? You can set references for the missile launch and impact locations: Caster (Unit/Point) is the unit that used the ability/weapon. Source and Target refer to the previous link in the chain of effects by default, but you can specify effects from which to draw the reference.
To target the ground where the unit is spawned you can set "YourCreateUnitEffect : Target Point" as the impact reference for the launch missile effect. To target the unit itself you can use the "creation effect" field on the create unit effect.
Compare with the Raven spawn abilities (autoturret, PDD) or the mutalisk weapon, but remeber that the Raven uses a "create precursor" setup to hide the unit until the missile hits.
Excess damage is usually caused by lack of markers/marker checks in periodic setups, or by not excluding Target and Outer from splash damage searches.
The death zone probably is a lingering persistent effect. Check for any persistent effects with (near-)infinite period count, and if units die almost instantly check specifically for loops that allow persistent effects to self-replicate.
If there are any dummy units involved behaviors with periodic effects can function much the same as persistent effects, but they instantly die with the unit.
Ammo units are only "used" if an effect calls them, or if they are given enough independent abilities to take actions themselves (like broodling escorts)
Use something like a magazine ability. Unless there's a better way of doing it you can at least create an invisible exterior ammo unit that triggers the intended effect on the caster, then kills itself.
0
If all else fails, use the "cargo behavior" field on the transport ability. Make that behavior kill the cargo when triggered, and add a validator that checks a dummy on the transport (i.e. a dummy buff you place on the transport when "casting" your kill ability). You have to modify all transport abilities you want to affect though.
0
If you mean "only 1 worm per Nydus Network", just place dummy buff or something on the Network and give the "spawn worm" ability a requirement that checks "dummy buff - completed at unit". Then find a way to remove the buff when the worm dies.
To replicate the SC1 Nydus the best solution would probably be to make an exact replica, and use a Teleport Unit effect instead of a transport ability.
0
You can do the 1-per-tick method, but that alone would still mean that once a unit is linked to a generator it stays linked until that one goes offline.
Buffs with a stack limit are automatically "replaced" when a new stack is meant to be applied. This can be set to keep the "oldest" buff (nothing gets replaced), but it can also be set to prefer the newest one, which even is the default afaik. All existing auras work by reapplying the buff before the previous stack expires, which in those cases simply refreshes the duration (as there are no initial effects or vitals modifiers involved)
What would then happen is that every unit would constantly be re-linked to whichever generator aura "ticked" most recently, producing a rather random distribution but ensuring the effect keeps going if one generator dies. Basically like stacking Psi Storms from multiple templar should work from what I can gather.
0
It greatly depends on how you want multiple generators to interact with eachother. You can use "markers" (and subsequent validators that check for them) to identify units. Mutalisk attacks and healing beams use them.
I can think of 2 basic approaches:
The first is to have each generator operate individually. Setting the maximum stack amount on your target buff to infinite allows generators to stack, while setting it to 1 (and setting the appropriate replacement rule) would basically make the generators "compete" for targets, distributing damage rather randomly amongst each other. (What happens then is that every time the aura effect ticks it reapplies the target buff, linking the target to the generator that just ticked. This would be happening several times per second for a decent aura)
The second method, which would work with BorgDragon's suggestion, is to have 2 seperate effect chains: 1 places the shield buff as discussed, the other checks for all targets in range and applies the shield restoration/distribution. You could either have all generators affecting the target simultaneously, hopefully producing an even damage distribution, or limit it to 1 generator per target.
Both methods allow the use of markers, exclusion of generator units from the effect (if desired), and some degree of control over how multiple generators interact. I think BorgDragon's method is more efficient for doing what you've explained, but the other one might be easier to use with a more complex chain of effects as you have a direct link between the shield buff and the shield-sharing mechanism.
0
How does your "learning" system work? Seems as if the requirement registers the dummy ability as "completed", so what happens if you change the requirement to call an ability not used by the unit?
Otherwise, why not place a dummy behavior on the unit to signal it has bought the upgrade, or is this a "hero" unit which you can revive after it dies?
0
You can apply a Modify Unit effect upon applying the shield buff that reduces shields by the amount given by your buff.
Use a Create Healer effect to restore shields. Use a cost of caster shields with a 1:1 ratio, and a near-infinite healing rate. And probably add some validators to stop it when not needed, compare with the medic/medivac.
If your actor responds to Behavior...ON/OFF with Create/Destroy, and you reapply the buff before the older stack expires the model shouldn't flicker.
Limit the target buff to 1 stack per caster. Be careful with BorgDragon's method as it will have some residual problems if units are in range of multiple generators, especially if one of them goes down.
0
Void Seeker/Zeratul - Void Spheres/Phase Mine Blast.
Open a map with campaign dependencies enabled and find one of those. The Void Seeker (Zeratul's starship) has it as a useable ability. It somehow causes the first Launch Missile effect to "impact" prematurely, creating a Persistent effect that launches the secondary missiles. Probably a field on the Launch Missile effect or the missile unit's Mover.
0
Validate Unit Type Target=/=Medic
If the ability already checks a validator, make an AND Combine Validator, to which you add the unit type comparison and whatever validator is already set on the ability.
If you can't figure out how to properly invert a validator you can always place it as the sole argument of another Combine validator, and check the appropriate flag on that.
0
If it's a search area effect you can use a target sorting method "sort by distance" as a "soft" solution. Limit the search to a maximum of 1 target to ensure only the closest unit is affected. The search also checks validators on the effect it's supposed to apply, so you can always use dummy buffs to "mark" units.
0
There's a field called "vitals received from damage" or so. I know you can find it on units and buff type behaviors, possibly on other things too. Usually classified under "combat".
Gaining health or shields from attacks would essentially equal %damage reduction, but you can do that with Damage Response buffs too. You can also use damage responses to trigger "flat" gains or %caster vitals ones, by triggering a Modify Unit effect. (The "vitals received" field scales with damage taken, and only with that)
0
1) What are UI splats? What are you trying to do? Does it work with other attachment points?
2) Have the attack/beam actor reference the intended target as the impact location. Reference an effect that executes on the target, or possibly use a Location actor (compare Collossus weapon, complicated and easy to get wrong)
3) Try a SetOpacity: 0 actor event with a model that works? Make sure the model is what causes the problem though.
And for your concept, how do you define "crossing the beam" with a single dummy unit? The only decent way I can think of is to have the HSM continuously launch linear collision-detecting missiles at the current target and react to their collision detection. This would probably be laggy as hell though, unless it's limited to few instances per map ("hero" ability etc)
I did manage to make a (rather choppy) replica of the original Colossus attack once, where the beam sweeps from one target to the next. I've never made a "collision-detecting" projectile though, and to give the impression of a constant searching beam you'd need more pewpewpew than a battlecruiser.
0
Does the missile have to strike the unit, or the surrounding area? You can set references for the missile launch and impact locations: Caster (Unit/Point) is the unit that used the ability/weapon. Source and Target refer to the previous link in the chain of effects by default, but you can specify effects from which to draw the reference.
To target the ground where the unit is spawned you can set "YourCreateUnitEffect : Target Point" as the impact reference for the launch missile effect. To target the unit itself you can use the "creation effect" field on the create unit effect.
Compare with the Raven spawn abilities (autoturret, PDD) or the mutalisk weapon, but remeber that the Raven uses a "create precursor" setup to hide the unit until the missile hits.
0
Excess damage is usually caused by lack of markers/marker checks in periodic setups, or by not excluding Target and Outer from splash damage searches.
The death zone probably is a lingering persistent effect. Check for any persistent effects with (near-)infinite period count, and if units die almost instantly check specifically for loops that allow persistent effects to self-replicate.
If there are any dummy units involved behaviors with periodic effects can function much the same as persistent effects, but they instantly die with the unit.
0
Ammo units are only "used" if an effect calls them, or if they are given enough independent abilities to take actions themselves (like broodling escorts)
0
Use something like a magazine ability. Unless there's a better way of doing it you can at least create an invisible exterior ammo unit that triggers the intended effect on the caster, then kills itself.
I use that, problem is you can't queue it easily.