I'm building a "Cluster Mine", meant to blow up as a group of 5 when an enemy gets too close to any one of them.
I've got them successfully blowing up individually, and I have a behavior set such that once a validator fails, they'll all blow up.
However, I'm having trouble building a validator capable of saying " true if 4 other units that have the same persistent effect parent are within radius 3 of parent effect, false otherwise".
Is such a validator possible, or am I using a flawed approach?
Some alternative avenues I've identified that would also lead to an answer, should any kind soul know how to do these:
-Somehow having each mine check it's own proximity area and those of it's cohorts ( I don't know how to get the mines to know and act on the position of the effect that spawned them )
-Have all the mines check (the parent effect's radius minus an area in the center), finding units less than 5m away but more than 2m, and guaranteeing that at least one such unit exists, and then having them all explode
-Somehow using a spawn behavior to build all the mines,somehow having one die kill off the unit who owned the spawn behavior, and having it set to kill spawned units on death
-Something involving "compare unit field" or "Compare unit order count", or something similar, to learn of a unique identifying trait somehow capable of being set
@Sylveslexi: Go
-Somehow having each mine check it's own proximity area and those of it's cohorts ( I don't know how to get the mines to know and act on the position of the effect that spawned them )
As you can see, multiple nuke towers cannot target the Marker location of other Nuke Towers. I have a persistent effect run a search at the marker position, and if moving enemies are found, orders the Marker's creator(the tower) to launch the nuke. It always finds it's "parent" unit, and never orders other towers to launch.
It was quite simple.
I have the Issue Order effect, the Unit+ field, set to CreateUnit effect:Caster, and the Target+ field set to CreateTarget:TargetPoint. The game automatically filters for the owning Tower and launches from proper tower to proper target point.
For more details and hands on, go to my link ASSETS and download the NukeDefenseTower map.
So perhaps...
Create Persisten effect, Effect - Initial creates the mines. The persistent flag "Persist Until Destroyed" should be checked.
When the first mine detonates, have it destroy the persistent aswell. Set the Destroy Persistent's Location+ field to CreatePersistent:TargetPoint
The Effect - Final in the Create Persistent should destroy all remaining mines. Set the Location+ field to CreatePersistent:TargetPoint/Unit
Profit?
As with everything, I would have to test this out to be sure but it seems sound.
ALTERNATIVE: Thinking this through... I believe you MIGHT need 2 persistents and a Set effect. Set effect creates persistent #1 and #2. #1 creates the mines, #2 Persists until expired. You point the Destroy Persistent to Persistent#2, which is set to on Effect- Final, destroy the mines by pointing to the proper mines via Location+ field(CreatePersisten1:TargetPoint/Unit).
In short create buff on unit and caster if unit dies it removes buff on caster that causes all units to suicide. Else just use an enumerate area approach where on death they order all nearby ones using a search area to blow.
Or just link their health with a conjoin behaviour. That way when one dies all those linked at the exact same instant also die.
First, THANKS! I'm thoroughly impressed with the replies here.
Re: Dr.SuperEvil:
That last one sounds rather elegant, but I'm not sure if I can make the conjoined-ness be exclusive to one set of mines, as I'm hoping to - it looks like giving the mines conjoined behavior would make any mines from other sets explode as well, as we're just looking for nearby entities with "conjoined" on them.
As for this: "buff on caster that causes all units to suicide. "
How would I build such a buff? I'm not sure how to specify a search area to exclusively find units created by another, or what effects would otherwise be used to target " just units created by a persistent effect created by a behavior on this unit"
Re:BorgDragon:
I tried something very sikmilar to that with one persistent effect - if I let it live forever, it spawns a crazy amount of mines as it's period count can't be used. Spawning two might work... I didn't know you could aim stuff at "CreatePersistent1" from the mine at all! I'm going to play with that and a second persistent effect now.
Once a group of units are conjoined they cannot have any others added to them. It only shares life of that specific group (think of the campaign trains where each train had independent shared life but there could be two different trains at once) so should be what you are after.
Have a validator that looks for the buff on the caster unit which the mine units will know from the create unit effect and if it is not then a suicide buff is activated. This method would not allow seperate groups of mines though.
I found giving all of the spawned units a "Conjoined" behavior caused them to join with units from other groups of 5.
My interpretation of conjoined was that every unit with conjoin, conjoins with every other unit that has conjoin. Is it, rather, that one conjoin behavior will conjoin everything in a certain radius?
You're probably right, but with every mine having a "Conjoin" behavior, I saw one group detonate as many groups as were near it, even if they were spawned a few seconds apart. It appeared that multiple groups of mines, "conjoined" separately, were seeing each other and conjoining further.
As for the buff, I have a validator looking for the caster of the "Create Unit" effect, and checking that it's behavior count for the "Don't Explode Yet" behavior = 1, but I can't get the validator to see that unit - I've tried every item on the "Value" list.
Here's the setup, built currently to debug why the mines always explode when spawned, even with no behaviors save "Explode if Parent Lacks Buff":
Ability - G-4 Charge Copy
Effect: D-8 Charge Copy
Effect (Create Unit) - D-8 Charge Copy
Spawn Unit: G-4 Charge Copy, Target Unit/Point
Unit: G-4 Charge Copy
Behavior (Buff) : D-8 Charge Fate Copy
Behavior (Buff) : D-8 Charge Don't Explode While This Exists
Behavior (Buff) : D-8 Charge Don't Explode While This Exists ( just exists, does nothing on its own)
What I want to happen, is that the parent mine ( a fake, it juts sits there) spawns the little mines, then nothing happens, unless one mine blows up, causing that group to all blow up.
Right now, even *without* the effects wired up that should cause mines to explode when enemies are nearby, all of the mines blow up immediately on spawn - the validator isn't returning true. I can see the parent mine having the buff; I let it be targetable for debug purposes.
I'm seeing the parent mine spawn explosions, constantly, instead of spawning infinitely many mines - that are, incidentally, finding the buff on the parent and then not doing anything.
Well that goes against my previous beliefs of how the conjoin behaviour functions. Heard tales of it not being able to fuse with previously conjoined groups. Maybe was changed in a patch.
Conjoined units should also combine life, check if the life is being combined or it is the damage on death that is triggering the chain. In other words is cluster A killing one from cluster B causing that to detonate.
The mines are invulnerable, but suicide upon exploding - I don't think it's possible for them to damage each other.
To check, I bumped their health to 1000 ( they deal 75 damage ). I still have groups with overlapping conjoin regions blowing up at once.
Does it mean anything useful that a validator (Compare Unit Behavior Count), looking for a certain buff on the caster of the create unit effect which created the unit whose behavior is running the validator, returns false constantly?
Even if the "Equal To" field is set to "Not Equal To", the validator fails. That seems illogical, but I'm staring at it.
Hello!
I'm building a "Cluster Mine", meant to blow up as a group of 5 when an enemy gets too close to any one of them.
I've got them successfully blowing up individually, and I have a behavior set such that once a validator fails, they'll all blow up.
However, I'm having trouble building a validator capable of saying " true if 4 other units that have the same persistent effect parent are within radius 3 of parent effect, false otherwise".
Is such a validator possible, or am I using a flawed approach?
Any advice would be welcome!
Thanks, -S
@Sylveslexi: Go
Some alternative avenues I've identified that would also lead to an answer, should any kind soul know how to do these:
-Somehow having each mine check it's own proximity area and those of it's cohorts ( I don't know how to get the mines to know and act on the position of the effect that spawned them )
-Have all the mines check (the parent effect's radius minus an area in the center), finding units less than 5m away but more than 2m, and guaranteeing that at least one such unit exists, and then having them all explode
-Somehow using a spawn behavior to build all the mines,somehow having one die kill off the unit who owned the spawn behavior, and having it set to kill spawned units on death
-Something involving "compare unit field" or "Compare unit order count", or something similar, to learn of a unique identifying trait somehow capable of being set
As you can see, multiple nuke towers cannot target the Marker location of other Nuke Towers. I have a persistent effect run a search at the marker position, and if moving enemies are found, orders the Marker's creator(the tower) to launch the nuke. It always finds it's "parent" unit, and never orders other towers to launch.
It was quite simple.
I have the Issue Order effect, the Unit+ field, set to CreateUnit effect:Caster, and the Target+ field set to CreateTarget:TargetPoint. The game automatically filters for the owning Tower and launches from proper tower to proper target point.
For more details and hands on, go to my link ASSETS
and download the NukeDefenseTower map.
So perhaps...
As with everything, I would have to test this out to be sure but it seems sound.
ALTERNATIVE: Thinking this through... I believe you MIGHT need 2 persistents and a Set effect. Set effect creates persistent #1 and #2. #1 creates the mines, #2 Persists until expired. You point the Destroy Persistent to Persistent#2, which is set to on Effect- Final, destroy the mines by pointing to the proper mines via Location+ field(CreatePersisten1:TargetPoint/Unit).
I say try method 1 first, slightly less work.
-
View User Profile
-
View Posts
-
Send Message
ModeratorsIn short create buff on unit and caster if unit dies it removes buff on caster that causes all units to suicide. Else just use an enumerate area approach where on death they order all nearby ones using a search area to blow.
Or just link their health with a conjoin behaviour. That way when one dies all those linked at the exact same instant also die.
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
@DrSuperEvil: Go
First, THANKS! I'm thoroughly impressed with the replies here.
Re: Dr.SuperEvil:
That last one sounds rather elegant, but I'm not sure if I can make the conjoined-ness be exclusive to one set of mines, as I'm hoping to - it looks like giving the mines conjoined behavior would make any mines from other sets explode as well, as we're just looking for nearby entities with "conjoined" on them.
As for this: "buff on caster that causes all units to suicide. "
How would I build such a buff? I'm not sure how to specify a search area to exclusively find units created by another, or what effects would otherwise be used to target " just units created by a persistent effect created by a behavior on this unit"
Re:BorgDragon:
I tried something very sikmilar to that with one persistent effect - if I let it live forever, it spawns a crazy amount of mines as it's period count can't be used. Spawning two might work... I didn't know you could aim stuff at "CreatePersistent1" from the mine at all! I'm going to play with that and a second persistent effect now.
Thanks guys! -S
-
View User Profile
-
View Posts
-
Send Message
ModeratorsOnce a group of units are conjoined they cannot have any others added to them. It only shares life of that specific group (think of the campaign trains where each train had independent shared life but there could be two different trains at once) so should be what you are after.
Have a validator that looks for the buff on the caster unit which the mine units will know from the create unit effect and if it is not then a suicide buff is activated. This method would not allow seperate groups of mines though.
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
@DrSuperEvil: Go
I found giving all of the spawned units a "Conjoined" behavior caused them to join with units from other groups of 5.
My interpretation of conjoined was that every unit with conjoin, conjoins with every other unit that has conjoin. Is it, rather, that one conjoin behavior will conjoin everything in a certain radius?
You're probably right, but with every mine having a "Conjoin" behavior, I saw one group detonate as many groups as were near it, even if they were spawned a few seconds apart. It appeared that multiple groups of mines, "conjoined" separately, were seeing each other and conjoining further.
As for the buff, I have a validator looking for the caster of the "Create Unit" effect, and checking that it's behavior count for the "Don't Explode Yet" behavior = 1, but I can't get the validator to see that unit - I've tried every item on the "Value" list.
Here's the setup, built currently to debug why the mines always explode when spawned, even with no behaviors save "Explode if Parent Lacks Buff":
What I want to happen, is that the parent mine ( a fake, it juts sits there) spawns the little mines, then nothing happens, unless one mine blows up, causing that group to all blow up.
Right now, even *without* the effects wired up that should cause mines to explode when enemies are nearby, all of the mines blow up immediately on spawn - the validator isn't returning true. I can see the parent mine having the buff; I let it be targetable for debug purposes.
I'm seeing the parent mine spawn explosions, constantly, instead of spawning infinitely many mines - that are, incidentally, finding the buff on the parent and then not doing anything.
Any ideas?
Thanks,
-S
-
View User Profile
-
View Posts
-
Send Message
ModeratorsWell that goes against my previous beliefs of how the conjoin behaviour functions. Heard tales of it not being able to fuse with previously conjoined groups. Maybe was changed in a patch.
Conjoined units should also combine life, check if the life is being combined or it is the damage on death that is triggering the chain. In other words is cluster A killing one from cluster B causing that to detonate.
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
@DrSuperEvil: Go
The mines are invulnerable, but suicide upon exploding - I don't think it's possible for them to damage each other.
To check, I bumped their health to 1000 ( they deal 75 damage ). I still have groups with overlapping conjoin regions blowing up at once.
Does it mean anything useful that a validator (Compare Unit Behavior Count), looking for a certain buff on the caster of the create unit effect which created the unit whose behavior is running the validator, returns false constantly?
Even if the "Equal To" field is set to "Not Equal To", the validator fails. That seems illogical, but I'm staring at it.
Thanks,
-S