You can specify an "ammo unit" (type) on the "use magazine" effect, that should allow targeting specific "device types". Or if that fails you can always validate the unit type on other effects, though I don't know exactly what happens when an ammo unit is simply called and then left idle. Interceptors return eventually, so hopefully your dummy units will too. (i.e. those of the "incorrect" type, which then would be "used" but not instantly salvaged)
Actually you could do that via data as well ("kill" damage effect+"create unit" effect)
That would destroy all other buffs placed on the unit though, and you couldn't (easily) refund anything either. Could even be used to "cheat out" of slow-acting detrimal effects ("poison", "timed bomb", "cripple" etc) by negating any effect centered on the mothership unit, at the cost of your upgrades.
For refunding "ability charges". I used it with the specialise->buff setup, with the cancel being a seperate effect-instant ability that removes the buffs and restores charges accordingly. Using ability charges as "device points" seems easier than making a dummy buff.
You'll also need a Modify Unit effect to "salvage" the ammo units on the "reset to default" ability if refunds are to be given, or even individual Modify Player effects containing the refund amounts if using a buff-based setup.
(S)He wants it to allow movement and use a build queue.
Faking a cancel is easy enough, albeit a bit tedious, using modify unit effects and a switch effect. (expect 2-3 effects for each individual upgrade at minimum)
Have you tried using a "use magazine" effect, and setting the "ammo effect" field to a "kill" effect? (+ a refund mechanic as mentioned above, if desired)
You can "use" all ammo units simultaneously with a persistent effect, just set the "period" to 0.
Controlling how your battlecruiser weapon destroys the ammo units might be difficult, especially getting it "truly" random if the "use magazine" effect doesn't do this by default.
Thanks, that works perfectly. Had forgotten I hadn't set up an Attack actor and that the explosions were only the death animation of the "magnetic mine" model.
Basically, I'm trying to make a version of the reaper's D-8 cluster bomb that detonates once an enemy walks near it, but without using units for the mines.
So far I have an initial persistent effect as the "spawner", which uses periodic offsets to place the "mines"
These "mines" are simply persistent effects which periodically check an EnumArea validator and have the explosion damage as their "final" effect.
This works fine for the most part, except all "mines" go off when one is triggered. Since the EnumArea search radius is so small I can conclude that the individual mine effects collectively check each other's impact locations. They don't just oscillate between the offsets of the initial persistent effect, as even with a period of 0.5s all (currently 5) "mines" explode simultaneously.
So, how do I stop this link, and why is it there in the first place? I've tried Target Point references with and without specifying an effect to no avail. I've also tried adding another "delay" persistent effect between the initial one and the "mines", but that doesn't help either.
And yes, I'm aware it's easy to do with dummy units, but that seems overkill for such a trivial effect, and I would still like to understand what's happening.
Most of this should be doable with the buffs used by the abilities.
Power Up: Change the duration of the "Purifier - Charging Planet Cracker" Buff to 15s. If you don't change anything that will immediately fire the Planet Cracker upon completion. You can then remove the Planet Cracker ability and button from the Purifier, and edit the costs of the Power Up ON/OFF toggles to equal Planet Cracker - Use/Cancel
Make a Requirement that counts the "using planet cracker" buff "completed at unit". Require the count to be 0. Add this to the ON toggle of the Power Up ability.
Shield: Use the "validator - deactivate" field on the shield buff. This triggers if the called validator returns FALSE! For your specific problem, make an AND combine validator to which you add "Behavior Count - Count=0" validators for each buff you want to check. For now make 2, 1 for each Planet Cracker behavior (charging/using)
Keeping the abilities seperate is a bit more work. Make the "charging" behavior apply another behavior "planet cracker ready" instead of starting the planet cracker effect, and make a requirement "planet cracker ready - count>=1" for the Planet Cracker ability itself. Probably add the "planet cracker ready" buff to the validator list on the shield buff as well. Add further cancel/refund abilities if desired. Don't remove the button and ability from the Purifier if you do this, obviously.
Wait, wouldn't that only track current life? Or can you compare "relative" vital values, thus measuring the rate of vitals loss?
Still, I think (s)he wants to classify "hard-hitting" attacks (siege tanks?) and "weaker" attacks (zerglings?) and display different visuals based on that, not necessarily taking into account the remaining shield reserves of the target.
Are you using regular shields or a custom graphic that triggers on attacks?
Regular shields are attached to a spherical mesh set by the model, and can't be scaled ingame afaik.
Any other effects can use a Model type actor with the "auto scaling factor" field to adjust to unit sizes. You can link the model to an Attack actor via the AttackImpactModel field.
You can send actor events to other actors in the same scope. Thus you should be able to change the opacity, scaling, tint etc of the shields if you find a valid reference to it, which I don't know. Colossus and Medivac beams use such references, but I haven't tried it with shields yet.
If you're using damage response behaviors you can set a cooldown on the reaction, that should solve the lightbulb issue.
Are you sure you tested your radar in the fog of war? It doesn't actually "detect" cloaked units, only show them as red (!) when in the fog.
Also check that said red blip actor (and potential host actors) don't inherit the "cloak status" from their host unit (many model attachments do, if the target is cloaked you don't see the effects either)
The basic shields already do this to some extent. There's at least a "full sphere" graphic and a "local impact" one. If using regular shields you can split your damage effect up into multiple smaller ones and have each trigger a shield impact (think 20 marines vs mothership), you can adjust the "armor reduction" value accordingly and use a persistent effect to apply many damage effects simultaneously.
As for your actual question, if you're okay with having only a few different reactions, you can use damage responses on behaviors. There are fields to set the minimum and maximum damage thresholds to which the behavior responds. Then have your "shield" actor react to certain damage responses.
Directly converting damage taken into say, opacity, is impossible without triggers afaik.
The link is easy, as one is created by the other. Have the creation process apply a persistent effect to both the caster and the target (spawned worm), then use these persistent effects as references for the teleport targets ("worm persistent" tp to "network persistent target", "network persistent" tp to "worm persistent target")
Then use periodic offsets or something to prevent sending the units in an infinite loop. Or a behavior that validates TargetIsStationary, then leaves another buff behind for 0.5 seconds or so, both of which prevent the unit from being warped. That's the hard part with this solution, and there's the slight drawback that anything that runs into the nydus gets teleported, even if it wasn't explicitely told to walk into it.
0
You can specify an "ammo unit" (type) on the "use magazine" effect, that should allow targeting specific "device types". Or if that fails you can always validate the unit type on other effects, though I don't know exactly what happens when an ammo unit is simply called and then left idle. Interceptors return eventually, so hopefully your dummy units will too. (i.e. those of the "incorrect" type, which then would be "used" but not instantly salvaged)
0
Actually you could do that via data as well ("kill" damage effect+"create unit" effect)
That would destroy all other buffs placed on the unit though, and you couldn't (easily) refund anything either. Could even be used to "cheat out" of slow-acting detrimal effects ("poison", "timed bomb", "cripple" etc) by negating any effect centered on the mothership unit, at the cost of your upgrades.
0
For refunding "ability charges". I used it with the specialise->buff setup, with the cancel being a seperate effect-instant ability that removes the buffs and restores charges accordingly. Using ability charges as "device points" seems easier than making a dummy buff.
You'll also need a Modify Unit effect to "salvage" the ammo units on the "reset to default" ability if refunds are to be given, or even individual Modify Player effects containing the refund amounts if using a buff-based setup.
0
(S)He wants it to allow movement and use a build queue.
Faking a cancel is easy enough, albeit a bit tedious, using modify unit effects and a switch effect. (expect 2-3 effects for each individual upgrade at minimum)
Have you tried using a "use magazine" effect, and setting the "ammo effect" field to a "kill" effect? (+ a refund mechanic as mentioned above, if desired)
You can "use" all ammo units simultaneously with a persistent effect, just set the "period" to 0.
Controlling how your battlecruiser weapon destroys the ammo units might be difficult, especially getting it "truly" random if the "use magazine" effect doesn't do this by default.
0
Thanks, that works perfectly. Had forgotten I hadn't set up an Attack actor and that the explosions were only the death animation of the "magnetic mine" model.
0
1) They don't hurt allies, nor do they trigger on allies.
2) The "mines" aren't units, just persistent effects with a periodic EnumArea validator.
0
Basically, I'm trying to make a version of the reaper's D-8 cluster bomb that detonates once an enemy walks near it, but without using units for the mines.
So far I have an initial persistent effect as the "spawner", which uses periodic offsets to place the "mines"
These "mines" are simply persistent effects which periodically check an EnumArea validator and have the explosion damage as their "final" effect.
This works fine for the most part, except all "mines" go off when one is triggered. Since the EnumArea search radius is so small I can conclude that the individual mine effects collectively check each other's impact locations. They don't just oscillate between the offsets of the initial persistent effect, as even with a period of 0.5s all (currently 5) "mines" explode simultaneously.
So, how do I stop this link, and why is it there in the first place? I've tried Target Point references with and without specifying an effect to no avail. I've also tried adding another "delay" persistent effect between the initial one and the "mines", but that doesn't help either.
And yes, I'm aware it's easy to do with dummy units, but that seems overkill for such a trivial effect, and I would still like to understand what's happening.
0
Most of this should be doable with the buffs used by the abilities.
Keeping the abilities seperate is a bit more work. Make the "charging" behavior apply another behavior "planet cracker ready" instead of starting the planet cracker effect, and make a requirement "planet cracker ready - count>=1" for the Planet Cracker ability itself. Probably add the "planet cracker ready" buff to the validator list on the shield buff as well. Add further cancel/refund abilities if desired. Don't remove the button and ability from the Purifier if you do this, obviously.
0
I figured. Sadly the data editor sucks at basic arithmetics.
0
It's the "Player+" field on the behavior. Compare with the Infestor's Neural Parasite. Set that field to "Hostile" for your purposes.
0
Wait, wouldn't that only track current life? Or can you compare "relative" vital values, thus measuring the rate of vitals loss?
Still, I think (s)he wants to classify "hard-hitting" attacks (siege tanks?) and "weaker" attacks (zerglings?) and display different visuals based on that, not necessarily taking into account the remaining shield reserves of the target.
0
Are you using regular shields or a custom graphic that triggers on attacks?
Regular shields are attached to a spherical mesh set by the model, and can't be scaled ingame afaik.
Any other effects can use a Model type actor with the "auto scaling factor" field to adjust to unit sizes. You can link the model to an Attack actor via the AttackImpactModel field.
You can send actor events to other actors in the same scope. Thus you should be able to change the opacity, scaling, tint etc of the shields if you find a valid reference to it, which I don't know. Colossus and Medivac beams use such references, but I haven't tried it with shields yet.
If you're using damage response behaviors you can set a cooldown on the reaction, that should solve the lightbulb issue.
0
Are you sure you tested your radar in the fog of war? It doesn't actually "detect" cloaked units, only show them as red (!) when in the fog.
Also check that said red blip actor (and potential host actors) don't inherit the "cloak status" from their host unit (many model attachments do, if the target is cloaked you don't see the effects either)
0
The basic shields already do this to some extent. There's at least a "full sphere" graphic and a "local impact" one. If using regular shields you can split your damage effect up into multiple smaller ones and have each trigger a shield impact (think 20 marines vs mothership), you can adjust the "armor reduction" value accordingly and use a persistent effect to apply many damage effects simultaneously.
As for your actual question, if you're okay with having only a few different reactions, you can use damage responses on behaviors. There are fields to set the minimum and maximum damage thresholds to which the behavior responds. Then have your "shield" actor react to certain damage responses.
Directly converting damage taken into say, opacity, is impossible without triggers afaik.
0
The link is easy, as one is created by the other. Have the creation process apply a persistent effect to both the caster and the target (spawned worm), then use these persistent effects as references for the teleport targets ("worm persistent" tp to "network persistent target", "network persistent" tp to "worm persistent target")
Then use periodic offsets or something to prevent sending the units in an infinite loop. Or a behavior that validates TargetIsStationary, then leaves another buff behind for 0.5 seconds or so, both of which prevent the unit from being warped. That's the hard part with this solution, and there's the slight drawback that anything that runs into the nydus gets teleported, even if it wasn't explicitely told to walk into it.