I have a buff that applies to all units within range, however it also need to apply to unit who are within range of the units who are within range and so on.
Also this buff can stack, but i only want one applied to the units within range per caster unit. Also if the caster unit goes out of range, they all lose the buff.
make an autocast effect instant ability based on stimpack. make the effect an search area and have it exclude caster. have the effect apply behavior and then apply the buff behavior
edit- after reading again, my solution may not be what you are looking for, sorry
Do you want an "epidemic" style dynamic where the buff slowly spreads outwards, or an instant effect? For the latter, follow FunkyUserName, make an infinite-range primary aura (limit the max targets per pulse though if the target buff is graphics-heavy), and use an EnumerateArea validator to check for proximity to buffed units (inside the EnumerateArea you can specify an "on target" validator to count buff stacks)
For slow spread just make the applied buff spread itself with the basic aura setup, depending on what exactly your ability is supposed to represent add EnumerateArea validators again to remove the buffs.
In both cases you can use the "max stacks per caster" field to limit overstacking, and in both cases you will probably run into problems when multiple units break off from the main blob. As long as 2 or more units stay in proximity of each other, you can't check if there's a full "conga line" of other units tracing all the way back to the original caster. If that is a problem you'll need to make the above buffs last shorter than the reapply pulse, and have them apply the actual buff effect upon application. This will "reset" the whole proximity check every pulse while the on-target buff effect remains continuously on.
Err, what exactly are you trying to achieve with this? To me it doesn't really make sense for living, breathing creatures to use more oxygen just because others are breathing nearby.
The Markers some of your effects set don't really do anything, as far as I can see you're not checking for them anywhere in this setup.
I didn't observe any lag, but I did notice your buff counter displays "..." instead of "1".
Other than that, what exactly isn't working? The counter does seem to update properly when moving units around.
the ... is a text tag error due to blizzard, it no longer shows 1's for some reason. i tried to sync the markers, so that the subsequent buffs work, but the units don't seem to pass the buff on. I am able to end up with the zerglings going 1-2-1 when it should be 2-2-2 all the way.
Edit: Some of the markers changes are just because i copied pasted certain effects (Remove 3, 4, 5, 6 etc.) The lag seems to be due to my computer when i tested in windowed mode
Yeah i got that much working now, however I've noticed that when I do larger groups it begins to screw up. I'll have some at 10 stacks and others will be at 0. No idea why, try grouping them and see if it happens for you might just be my comp screwing with me.
Your demo works fine until hitting the hardcap of 16 you coded in or running out of vespene. You can probably go lower on the pulse rate (stock "auras" like Mothership Cloaking Field often pulse at 0.0625s), but if you experience any kind of lag on that demo map you might want to get your hardware sorted out first.
As long as you avoid flickering graphics even a mapwide pulsing effect shouldn't cause much trouble before the sheer mass of units brings any computer to its knees anyway.
In the sense of each unit individually counting how many other units are in the clump, yes. I still don't quite understand how that goes into the whole "oxygen" concept, why doesn't each unit have a constant consumption rate? And why do you count the whole clump/conga line instead of the immediate proximity of the unit?
Eh they're all on a space ship together in the actual map, so there is a limited oxygen supply per area.
I conga line em cause i used to just check the immediate area, but people would dance on the line of making sure there were just enough people in the area for it to not go down.
Err, why limited oxygen "per area"? Either give each unit a base consumption rate (I mean, they're breathing constantly, right?) or, if you have actual separate "sections" on that ship, those will be handled by region-specific triggers anyway and you can just overlap the edges (using trigger logic to avoid double-counting)
If people "dance the line" wouldn't that still present an upper limit, or for a proximity check leave the outermost units exposed to hit-and-run attacks?
The issue is i'm trying to get the normal people to actually seperate and go look around in smaller groups.
People like to travel as one big group, I've implemented ways for them to be forcefully separated, but i'd rather use this as a subtle push to get the hell away from each other.
I don't know how your map plays, but don't you have any more visible mechanics to achieve that? For this purpose the "blob-finder" actually is a really good idea, but randomly running out of oxygen because someone moved 2m towards you still sounds rather iffy. Couldn't you instead apply a stacking "paranoia" debuff to movement/attack speed, damage taken, even time scale if gameplay is more focused on ability use?
Or add gameplay mechanics that "force" players to split up via objective control. In the early WoL days there was this one map where the humans on the ship had to manage life support, food and weapons, all in distinct areas of the map. If the opposing force has more options for multi-pronged attacks the "death ball" style crumbles all by itself.
I've tried splitting via objective control, but they tend to just camp the most important one (I've tried granting them equal importance, but some are just more important than others)
Edit: Each player is controlling one person, and the enemy is one person making multi-pronged attack impossible, if the enemy takes down an objective, they just group and move over there together to fix it, it's quite frustrating.
Is this enemy relying on assassination or indirect attacks? I assume it can kill the player 1v1, but can't stand up to a larger group? Is the identity of the "enemy" known from the start or do they have to blend in with the "normals"?
How about giving the enemy a "spawn minion" type ability, useless in direct combat but able to sabotage objectives independent of the main unit?
To be fair, most survival horror stories would end very quickly and with few (human) casualties if the people did just group up instead of wandering off and getting murdered one by one. This should be a challenge for the monster, you should only give it the tools to work with.
Remote-controllable airlocks would also be a potential option, either a few people stay on the other side or the entire blob gets shut in and has to painstakingly blast their way out. Or a "walking bomb" type ability that deals little to no damage to the primary target, but heavy AoE around it, forcing blobbed players to scatter. If the "monster" can take on the entire group of players ensure the "safety net" objective (door lock, gas release switch, curtains vs. vampires etc.) is far away from the infrastructure target, that's one free split right off the bat.
In the end you can use the oxygen mechanic to force players to split, but it will feel every bit as forced as it actually is.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
I have a buff that applies to all units within range, however it also need to apply to unit who are within range of the units who are within range and so on.
Also this buff can stack, but i only want one applied to the units within range per caster unit. Also if the caster unit goes out of range, they all lose the buff.
Any ideas on how to do this?
Example pic attached.
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
make an autocast effect instant ability based on stimpack. make the effect an search area and have it exclude caster. have the effect apply behavior and then apply the buff behavior
edit- after reading again, my solution may not be what you are looking for, sorry
@willuwontu: Go
i would give the ability more range and then validate if a unit is close to the target unit with the behaviour.
Do you want an "epidemic" style dynamic where the buff slowly spreads outwards, or an instant effect? For the latter, follow FunkyUserName, make an infinite-range primary aura (limit the max targets per pulse though if the target buff is graphics-heavy), and use an EnumerateArea validator to check for proximity to buffed units (inside the EnumerateArea you can specify an "on target" validator to count buff stacks)
For slow spread just make the applied buff spread itself with the basic aura setup, depending on what exactly your ability is supposed to represent add EnumerateArea validators again to remove the buffs.
In both cases you can use the "max stacks per caster" field to limit overstacking, and in both cases you will probably run into problems when multiple units break off from the main blob. As long as 2 or more units stay in proximity of each other, you can't check if there's a full "conga line" of other units tracing all the way back to the original caster. If that is a problem you'll need to make the above buffs last shorter than the reapply pulse, and have them apply the actual buff effect upon application. This will "reset" the whole proximity check every pulse while the on-target buff effect remains continuously on.
@Photoloss: Go
Thanks you helped me get on the right track, i forgot about max stacks per caster, that makes things easier.
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
Isn't there like an "initial effect" field value for buffs. You could set that to the search effect to apply it to new nearby units.
Okay so the buff isn't working properly right now, also it's laggy as fuck, could anyone else take a look and offer some advice?
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
Err, what exactly are you trying to achieve with this? To me it doesn't really make sense for living, breathing creatures to use more oxygen just because others are breathing nearby.
The Markers some of your effects set don't really do anything, as far as I can see you're not checking for them anywhere in this setup.
I didn't observe any lag, but I did notice your buff counter displays "..." instead of "1".
Other than that, what exactly isn't working? The counter does seem to update properly when moving units around.
the ... is a text tag error due to blizzard, it no longer shows 1's for some reason. i tried to sync the markers, so that the subsequent buffs work, but the units don't seem to pass the buff on. I am able to end up with the zerglings going 1-2-1 when it should be 2-2-2 all the way.
Edit: Some of the markers changes are just because i copied pasted certain effects (Remove 3, 4, 5, 6 etc.) The lag seems to be due to my computer when i tested in windowed mode
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
In my brief testrun the Zerglings were 2-2-2 all the time, and updated properly when moved out of range.
Yeah i got that much working now, however I've noticed that when I do larger groups it begins to screw up. I'll have some at 10 stacks and others will be at 0. No idea why, try grouping them and see if it happens for you might just be my comp screwing with me.
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
Your demo works fine until hitting the hardcap of 16 you coded in or running out of vespene. You can probably go lower on the pulse rate (stock "auras" like Mothership Cloaking Field often pulse at 0.0625s), but if you experience any kind of lag on that demo map you might want to get your hardware sorted out first.
As long as you avoid flickering graphics even a mapwide pulsing effect shouldn't cause much trouble before the sheer mass of units brings any computer to its knees anyway.
@Photoloss: Go
But it all works properly right?
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
In the sense of each unit individually counting how many other units are in the clump, yes. I still don't quite understand how that goes into the whole "oxygen" concept, why doesn't each unit have a constant consumption rate? And why do you count the whole clump/conga line instead of the immediate proximity of the unit?
@Photoloss: Go
Eh they're all on a space ship together in the actual map, so there is a limited oxygen supply per area.
I conga line em cause i used to just check the immediate area, but people would dance on the line of making sure there were just enough people in the area for it to not go down.
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
@willuwontu: Go
Err, why limited oxygen "per area"? Either give each unit a base consumption rate (I mean, they're breathing constantly, right?) or, if you have actual separate "sections" on that ship, those will be handled by region-specific triggers anyway and you can just overlap the edges (using trigger logic to avoid double-counting)
If people "dance the line" wouldn't that still present an upper limit, or for a proximity check leave the outermost units exposed to hit-and-run attacks?
The issue is i'm trying to get the normal people to actually seperate and go look around in smaller groups.
People like to travel as one big group, I've implemented ways for them to be forcefully separated, but i'd rather use this as a subtle push to get the hell away from each other.
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
I don't know how your map plays, but don't you have any more visible mechanics to achieve that? For this purpose the "blob-finder" actually is a really good idea, but randomly running out of oxygen because someone moved 2m towards you still sounds rather iffy. Couldn't you instead apply a stacking "paranoia" debuff to movement/attack speed, damage taken, even time scale if gameplay is more focused on ability use?
Or add gameplay mechanics that "force" players to split up via objective control. In the early WoL days there was this one map where the humans on the ship had to manage life support, food and weapons, all in distinct areas of the map. If the opposing force has more options for multi-pronged attacks the "death ball" style crumbles all by itself.
I've tried splitting via objective control, but they tend to just camp the most important one (I've tried granting them equal importance, but some are just more important than others)
Edit: Each player is controlling one person, and the enemy is one person making multi-pronged attack impossible, if the enemy takes down an objective, they just group and move over there together to fix it, it's quite frustrating.
Still alive and kicking, just busy.
My guide to the trigger editor (still a work in progress)
Is this enemy relying on assassination or indirect attacks? I assume it can kill the player 1v1, but can't stand up to a larger group? Is the identity of the "enemy" known from the start or do they have to blend in with the "normals"?
How about giving the enemy a "spawn minion" type ability, useless in direct combat but able to sabotage objectives independent of the main unit?
To be fair, most survival horror stories would end very quickly and with few (human) casualties if the people did just group up instead of wandering off and getting murdered one by one. This should be a challenge for the monster, you should only give it the tools to work with.
Remote-controllable airlocks would also be a potential option, either a few people stay on the other side or the entire blob gets shut in and has to painstakingly blast their way out. Or a "walking bomb" type ability that deals little to no damage to the primary target, but heavy AoE around it, forcing blobbed players to scatter. If the "monster" can take on the entire group of players ensure the "safety net" objective (door lock, gas release switch, curtains vs. vampires etc.) is far away from the infrastructure target, that's one free split right off the bat.
In the end you can use the oxygen mechanic to force players to split, but it will feel every bit as forced as it actually is.