Look at the HotS campaign Aberration, which iirc already does this (not sure if Banelings are included)
For unit-to-unit collision it's those Collide/Plane fields you already found, but they're hardcoded. Everything in one group collides with other members of that group, but I don't know if there are other hardcoded interactions such as multiple "burrower" groups intrinsically colliding with each other.
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.
You should look into Aliases though, especially when it comes to straight-up multiform units like Burrow, Liftoff/Land etc.
Since they're set on the unit itself, maybe that'll also serve as a reminder to equalise the costs between both forms, too many "campaign" mods where burrowing Kerrigan gives you 1000+ min/gas...
Maybe add "Position, Rotation" to Properties: Inherited Properties +? If that doesn't fix it (or maybe it was Accepted Transfers, I forgot...), you'll have to give details on the rest of the setup, as it may be a problem with how you're creating the attachment in the first place.
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.
You did put the SiteOp on the attached models, right?
Maybe that AttachModelOffset method works differently, I usually use UnitBirth->Create"Attachment" and adjust the positioning with a separate SOp Local Offset. I know it works that way if you put all SOps in the Hosting: Host Site Operations + field on the attachment model itself.
You throw a SiteOp on the attached model, after the "Attach" method but before any other modifiers (offsets, rotators etc.). The critical setting is to enable Actor: Hold Rotation on that SiteOp.
It may work with certain "functional" SOps, but this setting seems to break Rotators. In that case simply make a SOp "Variance Rotation" with both angle fields set to 0.
As an example, AttachCenter->dummy VarianceRotation->Rotator->Offset produces a circular orbiting motion.
That's perfectly viable with Data though, Interact ability or the like.
Some passive effects have display buttons visible to enemies, right? Try placing those underneath the active ones along with an Interact/Share Control setup, but if it works you could even import artificially greyscaled ones.
Put the aura on the hero, and add a check on the applied buff (which goes on the shop) for "Caster within range of target" (try to convert a LocationRange validator into a Requirement, and put that on the buff). Then try "Behavior Allowed: aura buff" as the button Requirement. Will probably fail horribly, but worth a try.
Ah, so the AI already has permanent shared control, meh. What I don't know with autocast-share-control is how to show greyed-out buttons in the "inactive" state, shop control would otherwise work like you want it to if set up properly.
The problem is you don't have an "other unit" scope in your enable/disable check. I think you can't check "buff caster in range" outside of the buff aplication chain either. If the original buff is applied by the player unit you can at least check the owning player within that chain, but the Requirement on the shop won't have access to that scope.
I don't know how "Count Behavior" requirement nodes act if you assign a non-"at Unit" condition, if you're lucky they might iterate over all player units. "Behavior Allowed" might also help depending on where it draws its scope from. I at least assume it checks the Requirement and Validator fields on the specified Behavior, but can it grab the scope of an existing instance of said buff?
SOpRotator. To fully mimic the Mothership you might have to use an additional SOp to properly inherit from the global coordinate grid, otherwise the model might additionally turn whenever the unit turns. At least I had that problem when mimicking WC3 "orb" attachment effects.
You also might have to move the entire primary model to an attached actor, meaning you'd have to copy over all animation events too.
Units with a built-in functional rotation hardpoint can just use that, but I think the Phoenix and Mothership may be the only ones that support it.
No idea on how to do it with triggers directly, I prefer data-only solutions. You definitely need to specify both a Launch and Impact scope for the Launch Missile effect for it to work. Those can be mere points, but you have to pass them from the trigger somehow. You might also need an Action/Attack actor, not sure on that bit.
For data you just make a Weapon or Ability to launch the effect, Effect - Target abilities in particular allow you to target a point on the ground, then use the casting unit as the other scope. If you want this to be an environmental effect or the like (with no unit at the launch or impact position), try looking for a "launch effect from unit/point" trigger action, data-based solutions will be inefficient.
0
In my brief testrun the Zerglings were 2-2-2 all the time, and updated properly when moved out of range.
0
Look at the HotS campaign Aberration, which iirc already does this (not sure if Banelings are included)
For unit-to-unit collision it's those Collide/Plane fields you already found, but they're hardcoded. Everything in one group collides with other members of that group, but I don't know if there are other hardcoded interactions such as multiple "burrower" groups intrinsically colliding with each other.
0
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.
0
Have you tried it on "Inherited Properties +"? Also the "attach" SOp has to come before the rotation, though that shouldn't break the attachment.
0
You should look into Aliases though, especially when it comes to straight-up multiform units like Burrow, Liftoff/Land etc.
Since they're set on the unit itself, maybe that'll also serve as a reminder to equalise the costs between both forms, too many "campaign" mods where burrowing Kerrigan gives you 1000+ min/gas...
0
Maybe add "Position, Rotation" to Properties: Inherited Properties +? If that doesn't fix it (or maybe it was Accepted Transfers, I forgot...), you'll have to give details on the rest of the setup, as it may be a problem with how you're creating the attachment in the first place.
0
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.
0
You did put the SiteOp on the attached models, right?
Maybe that AttachModelOffset method works differently, I usually use UnitBirth->Create"Attachment" and adjust the positioning with a separate SOp Local Offset. I know it works that way if you put all SOps in the Hosting: Host Site Operations + field on the attachment model itself.
0
You throw a SiteOp on the attached model, after the "Attach" method but before any other modifiers (offsets, rotators etc.). The critical setting is to enable Actor: Hold Rotation on that SiteOp.
It may work with certain "functional" SOps, but this setting seems to break Rotators. In that case simply make a SOp "Variance Rotation" with both angle fields set to 0.
As an example, AttachCenter->dummy VarianceRotation->Rotator->Offset produces a circular orbiting motion.
0
@MaskedImposter: Go
That's perfectly viable with Data though, Interact ability or the like.
Some passive effects have display buttons visible to enemies, right? Try placing those underneath the active ones along with an Interact/Share Control setup, but if it works you could even import artificially greyscaled ones.
0
Put the aura on the hero, and add a check on the applied buff (which goes on the shop) for "Caster within range of target" (try to convert a LocationRange validator into a Requirement, and put that on the buff). Then try "Behavior Allowed: aura buff" as the button Requirement. Will probably fail horribly, but worth a try.
0
Ah, so the AI already has permanent shared control, meh. What I don't know with autocast-share-control is how to show greyed-out buttons in the "inactive" state, shop control would otherwise work like you want it to if set up properly.
The problem is you don't have an "other unit" scope in your enable/disable check. I think you can't check "buff caster in range" outside of the buff aplication chain either. If the original buff is applied by the player unit you can at least check the owning player within that chain, but the Requirement on the shop won't have access to that scope.
I don't know how "Count Behavior" requirement nodes act if you assign a non-"at Unit" condition, if you're lucky they might iterate over all player units. "Behavior Allowed" might also help depending on where it draws its scope from. I at least assume it checks the Requirement and Validator fields on the specified Behavior, but can it grab the scope of an existing instance of said buff?
0
How do the shops work? Still that ancient setup of "autocast-share-control"? (haven't looked into shops since WoL release era)
Buttons being greyed out means you have a Requirement/Validator on them, correct? What exactly does that check for?
0
SOpRotator. To fully mimic the Mothership you might have to use an additional SOp to properly inherit from the global coordinate grid, otherwise the model might additionally turn whenever the unit turns. At least I had that problem when mimicking WC3 "orb" attachment effects.
You also might have to move the entire primary model to an attached actor, meaning you'd have to copy over all animation events too.
Units with a built-in functional rotation hardpoint can just use that, but I think the Phoenix and Mothership may be the only ones that support it.
0
No idea on how to do it with triggers directly, I prefer data-only solutions. You definitely need to specify both a Launch and Impact scope for the Launch Missile effect for it to work. Those can be mere points, but you have to pass them from the trigger somehow. You might also need an Action/Attack actor, not sure on that bit.
For data you just make a Weapon or Ability to launch the effect, Effect - Target abilities in particular allow you to target a point on the ground, then use the casting unit as the other scope. If you want this to be an environmental effect or the like (with no unit at the launch or impact position), try looking for a "launch effect from unit/point" trigger action, data-based solutions will be inefficient.