Depends on how you set up the "upgrade". Sounds like the sold item still belongs to the neutral player, and thus researches the upgrade for them.
For single-player shops you can shut them down through a buff when no hero is near, this will allow allies to buy from across the map though.
I don't know how the various "mind control" methods work regarding upgrade research, but you could try applying one on the item. Or spawn the item through a Create Unit effect or the like, which allows you to explicitly state an owning player.
Alternatively you could just run a trigger that detects the purchase and give the upgrade to the purchasing player.
From what I know Proton Charge was only a "click once, buff Probes" type of deal. Fungal Growth does that, and Psi Storm is the "pulsing field" variety. For the actual effect, there's a "harvest amount bonus" array on buffs which just adds the value to the amount gathered by that unit. I doubt Proton Charge buffed mineral fields separately, but the best option might be to just put an aura on the mineral field that spreads the same "harvest amount" buff to nearby probes.
True "line" AoE doesn't exist, you approximate it by firing circular AoEs along the line, check the Hellion weapon for that. With HotS you have Guide/Quad actors for the targeting cursor.
Thanks, LaunchModel and "Force Site" seem to both work just fine. For some reason just adding the actor ID works for Launch Model: Host but not for Launch Request, oh well.
Is there any guide/summary on this? Anything I try with Site actors fails rather disappointingly, and I noticed one of my older implementations broke too (which was basically a blank Site actor hosted on the attachment)
My "attachment" is a ModelAddition actor created by the main unit via ActorCreation->Create"Attachment", meant to act as a surrogate for the actual unit to use the Phoenix turret rotation.
Launch Request+ fails in an "out of scope" way no matter what I try. Launch Site doesn't go out of scope, but never finds the attachment, either it evaluates the SiteOps within the main unit scope, or it gets overridden by the fallback options. I've tried Actor Find, References copied from the "tentacle" skills and even a ::global reference on ActorCreation of the attachment, to no avail.
What's really cheesing me off is that the previous working implementation was so easy, and it broke somehow (that was from before Actor Find worked properly though...)
I know this problem with the resources but yet i solved it by set the costs from both forms to the same. Isn't this the best way?
Oh, it is, the only other way I know is to set the costs on all build/train/evolution abilities, which leaves you manually calculating all cost differences and struggling to find all your stuff every time you need to rebalance something.
People just don't do it because they fail to realise that the burrowed form is a different unit in terms of code.
Aliases literally allow you to reference a group of different unit types as if they were the same, without losing any existing functionality when not using the alias. The only situation where they're less efficient is when you have many more "groups" than units within a group, and each group is only used in one piece of code, like forming pairs out of 5+ unit types and each is only used for one ability check.
What do you mean "launching ammo missiles"? By default missiles are simply created when they're "launched", any system that mimics ammo or "producing" the missiles is simply an arbitrary restriction and would work equally well to give Psi Storm "ammo limitations". "Magazine" interfaces are meant to do what the Carrier does, and as I already said the Nuke calldown doesn't even involve "missiles" in the gameplay sense.
You can "launch" regular units, but that's more for the purpose of suicide-bombing or forcefully moving them (Abduct)
The "calldown" mechanic is only an ammo system, but might require an Ability with the Calldown Effect field set to function properly. Still, I see no reason why you couldn't add a Persistent effect to the existing Nuke ability to launch multiple calldowns at different offsets. In the worst case the Calldown effect type can request more than one launch, so you can define the offset afterwards with a single-tick Persistent.
To auto-target missiles simply don't exclude them from the target filter of the anti-missile weapon, if players are meant to target manually you'll have to sift through the Unit: Flags+ field on the missile and make sure it's targetable via mouseclick, this might also allow actually selecting the unit to view the wireframe.
The arc/flight path is defined by the missile Mover, if there is an actual traveling missile involved at all. Nukes just play stationary animations at the launch and impact location.
"Selecting a larger radius" in this case would mean you have to define an additional offset distribution for each radius choice, and switch between them based on however the "selection" part works (multiple abilities, on/off toggle buff, tech requirements or whatever)
In general you can and should split the ability into multiple parts, test each one individually, then combine them. So far you have:
Calldown/Ammo system: Either get the Calldown to work copying from the Nuke ability, or come up with an alternative ammo system like buff stacks or dummy units. Test with a simple activation effect like dealing 1 damage to the target unit instantly or giving the caster a stacking armor buff (ApplyBehavior on Caster, buff gives +1 armor for easy stack counting)
"Random impact location workaround": You can test your offset distribution system by launching something like Psi Storm or Siege Tank attacks, by setting your Persistent to apply the effect called by that weapon/ability, anything that can target points on the ground should work.
Remote Launch: You'll need to launch the missiles from the silos to the ability target location. Either implement a separate ability for the silos to "attack" with, or look at e.g. the Mutalisk bouncing weapon for how to launch missiles from something that isn't the ability caster (it's fairly complicated and requires Actors). Test with only launching a single missile with no conditions like ammo and no target offsets, this is also where you can adjust the travel arc easily by repeatedly launching missiles to and from the same 2 points until you're satisfied with the visuals
Then you glue everything together: the "success" effect of the calldown/ammo mechanism becomes the offset distribution, and that aims a single-missile launch at the chosen offset (instead of the Psi Storm you had for testing). If you run into problems regarding the Scope (incorrect unit-based locations most likely), note you can specify an effect that previously occured in the chain to draw the scope from. Caster always points at the unit that originally used the ability/weapon.
What exactly are the "silos" in your setup? Proper structures on the map or just "missile pod" upgrades on a unit? Do you need the ability to control how many missiles are actually launched each time, or just a "fire everything" approach limited by the total capacity of the silos? And do the silos have to actually "build" the missiles or just sit there and wait for launch orders?
In general you can either use a Persistent effect to repeatedly use a Calldown (nuke) setup if individual missiles are built and stored in separate structures, or just use a high-range Search Area effect to "count" how many silos there are and create the missiles at launch time (basically how all standard weapons function, no ammo involved)
There is no "random point in circle" targeting option (might get added in LotV), so you're stuck with either randomly choosing offsets from a predefined list, or damaging the whole target zone and making the distinct impact location visual-only. The AoE will be defined by the offset locations and/or the radius of any Area fields used to inflict damage, that bit is easy to set.
Missiles are fully functional units and can already be targeted and destroyed, as the Raven's PDD does (using an instant kill rather than damage though); making missiles fully selectable like units will require some meddling with Actor data to give them wireframes, armor icons etc.
If kill credit isn't an issue you could also make the ability only trigger an Issue Order effect on the silos, and give them the ability/weapon to attack based on their own capacity.
The buffs keep "bouncing" between affected units indefinitely. Since you can't check for the casting unit directly you might have to resort to Markers. You might run into a lot of arbitrary complications in getting them to apply and reset properly.
Do people have to eat/drink/restorck ammo? How do they even end up with having to defend only one objective? There should at least be a "command center", "engine/power", "life support" and "armory/tech/medical" room, how do they cope if one of those gets sabotaged? "Keeping away from doors" means your map is badly designed, there should be at least two doors between any two objectives (#1->corridor->#2), they can't "keep away" from all of those...
Edit: Middle click isn't implemented, at least not in the triggers on the map itself. And it seems the secondary check is broken, only the immediate surroundings are counted.
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.
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.
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?
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?
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.
0
Depends on how you set up the "upgrade". Sounds like the sold item still belongs to the neutral player, and thus researches the upgrade for them.
For single-player shops you can shut them down through a buff when no hero is near, this will allow allies to buy from across the map though.
I don't know how the various "mind control" methods work regarding upgrade research, but you could try applying one on the item. Or spawn the item through a Create Unit effect or the like, which allows you to explicitly state an owning player.
Alternatively you could just run a trigger that detects the purchase and give the upgrade to the purchasing player.
0
From what I know Proton Charge was only a "click once, buff Probes" type of deal. Fungal Growth does that, and Psi Storm is the "pulsing field" variety. For the actual effect, there's a "harvest amount bonus" array on buffs which just adds the value to the amount gathered by that unit. I doubt Proton Charge buffed mineral fields separately, but the best option might be to just put an aura on the mineral field that spreads the same "harvest amount" buff to nearby probes.
True "line" AoE doesn't exist, you approximate it by firing circular AoEs along the line, check the Hellion weapon for that. With HotS you have Guide/Quad actors for the targeting cursor.
0
Thanks, LaunchModel and "Force Site" seem to both work just fine. For some reason just adding the actor ID works for Launch Model: Host but not for Launch Request, oh well.
0
Is there any guide/summary on this? Anything I try with Site actors fails rather disappointingly, and I noticed one of my older implementations broke too (which was basically a blank Site actor hosted on the attachment)
My "attachment" is a ModelAddition actor created by the main unit via ActorCreation->Create"Attachment", meant to act as a surrogate for the actual unit to use the Phoenix turret rotation.
Launch Request+ fails in an "out of scope" way no matter what I try. Launch Site doesn't go out of scope, but never finds the attachment, either it evaluates the SiteOps within the main unit scope, or it gets overridden by the fallback options. I've tried Actor Find, References copied from the "tentacle" skills and even a ::global reference on ActorCreation of the attachment, to no avail.
What's really cheesing me off is that the previous working implementation was so easy, and it broke somehow (that was from before Actor Find worked properly though...)
0
Oh, it is, the only other way I know is to set the costs on all build/train/evolution abilities, which leaves you manually calculating all cost differences and struggling to find all your stuff every time you need to rebalance something.
People just don't do it because they fail to realise that the burrowed form is a different unit in terms of code.
Aliases literally allow you to reference a group of different unit types as if they were the same, without losing any existing functionality when not using the alias. The only situation where they're less efficient is when you have many more "groups" than units within a group, and each group is only used in one piece of code, like forming pairs out of 5+ unit types and each is only used for one ability check.
0
@COldfusionstorm: Go
What do you mean "launching ammo missiles"? By default missiles are simply created when they're "launched", any system that mimics ammo or "producing" the missiles is simply an arbitrary restriction and would work equally well to give Psi Storm "ammo limitations". "Magazine" interfaces are meant to do what the Carrier does, and as I already said the Nuke calldown doesn't even involve "missiles" in the gameplay sense.
You can "launch" regular units, but that's more for the purpose of suicide-bombing or forcefully moving them (Abduct)
0
The "calldown" mechanic is only an ammo system, but might require an Ability with the Calldown Effect field set to function properly. Still, I see no reason why you couldn't add a Persistent effect to the existing Nuke ability to launch multiple calldowns at different offsets. In the worst case the Calldown effect type can request more than one launch, so you can define the offset afterwards with a single-tick Persistent.
To auto-target missiles simply don't exclude them from the target filter of the anti-missile weapon, if players are meant to target manually you'll have to sift through the Unit: Flags+ field on the missile and make sure it's targetable via mouseclick, this might also allow actually selecting the unit to view the wireframe.
The arc/flight path is defined by the missile Mover, if there is an actual traveling missile involved at all. Nukes just play stationary animations at the launch and impact location.
"Selecting a larger radius" in this case would mean you have to define an additional offset distribution for each radius choice, and switch between them based on however the "selection" part works (multiple abilities, on/off toggle buff, tech requirements or whatever)
In general you can and should split the ability into multiple parts, test each one individually, then combine them. So far you have:
Then you glue everything together: the "success" effect of the calldown/ammo mechanism becomes the offset distribution, and that aims a single-missile launch at the chosen offset (instead of the Psi Storm you had for testing). If you run into problems regarding the Scope (incorrect unit-based locations most likely), note you can specify an effect that previously occured in the chain to draw the scope from. Caster always points at the unit that originally used the ability/weapon.
0
What exactly are the "silos" in your setup? Proper structures on the map or just "missile pod" upgrades on a unit? Do you need the ability to control how many missiles are actually launched each time, or just a "fire everything" approach limited by the total capacity of the silos? And do the silos have to actually "build" the missiles or just sit there and wait for launch orders?
In general you can either use a Persistent effect to repeatedly use a Calldown (nuke) setup if individual missiles are built and stored in separate structures, or just use a high-range Search Area effect to "count" how many silos there are and create the missiles at launch time (basically how all standard weapons function, no ammo involved)
There is no "random point in circle" targeting option (might get added in LotV), so you're stuck with either randomly choosing offsets from a predefined list, or damaging the whole target zone and making the distinct impact location visual-only. The AoE will be defined by the offset locations and/or the radius of any Area fields used to inflict damage, that bit is easy to set.
Missiles are fully functional units and can already be targeted and destroyed, as the Raven's PDD does (using an instant kill rather than damage though); making missiles fully selectable like units will require some meddling with Actor data to give them wireframes, armor icons etc.
If kill credit isn't an issue you could also make the ability only trigger an Issue Order effect on the silos, and give them the ability/weapon to attack based on their own capacity.
0
The buffs keep "bouncing" between affected units indefinitely. Since you can't check for the casting unit directly you might have to resort to Markers. You might run into a lot of arbitrary complications in getting them to apply and reset properly.
0
Do people have to eat/drink/restorck ammo? How do they even end up with having to defend only one objective? There should at least be a "command center", "engine/power", "life support" and "armory/tech/medical" room, how do they cope if one of those gets sabotaged? "Keeping away from doors" means your map is badly designed, there should be at least two doors between any two objectives (#1->corridor->#2), they can't "keep away" from all of those...
Edit: Middle click isn't implemented, at least not in the triggers on the map itself. And it seems the secondary check is broken, only the immediate surroundings are counted.
0
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.
0
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.
0
@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?
0
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?
0
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.