First you have to define what the "idle" trajectory should look like. In principle you can set any reasonable shape by periodically aiming an Issue Order - Move effect at an offset generated by a Persistent effect. Due to constantly giving orders this makes it somewhat difficult to define the "idle" state though, in terms of coding this "idle" movement looks just the same as if the player had given an order themselves.
The player would also be able to prevent the movement by mashing the "Stop" command faster than the update pulse rate. This is a more general problem though, as technically receiving constant "Stop" orders isn't an "idle" state.
For preventing all forms of selection there's the Unselectable flag on the unit. I don't know if you can somehow prevent only box-select, especially if the box contains just that one unit, but the opposite can probably be done using actors/models: Messing with the "radius" of the model or disabling "Add To Proximity System" on the actor should prevent left-click selection while allowing the box. Technically left-click selection is still "allowed" in that case, you simply give the game engine 0 on-screen area that will trigger it.
The various Aliases are for making multiple unit types equal to each other, as explained when you mouse over the fields there's one for double-click/Ctrl-click select and one for grouping once selection has occurred, plus the Tech and Leaderboard ones. I think the Unit-over-Structure box priority is hardcoded and tied to those tags.
Damage Response on a Buff type Behavior. Make sure it runs on "Attacker" and tick the "Fatal" flag, then either give lifesteal (not sure if that works) or apply a Modify Unit effect on the Caster unit (i.e. your attacking unit and not the victim) set to heal.
You'll need several effects and validators if the unit has shields and ought to "reverse-damage" itself, i.e. heal HP first and only then the shields. Healing based on enemy health/max health will also be complicated.
Check the Mover itself, the default "Fly" mover may have a setting for maximum turn speed. Otherwise I know there was a "turn before moving" flag somewhere, but I have no idea whether it's relevant to your problem. Check on the unit and the Move ability, if it's not there it's related to a more specific use and of no interest to you.
Of course you should also double-check that you changed all relevant fields, there's usually "speed" and "acceleration", and there's a "stationary" turn rate as well.
For attack use check the Weapons. The "Shared Cooldown" flag often interferes with having multiple weapons, and I have no idea how having multiple eligible weapons works out if you don't allow a full multitarget: The blade/head swing is "channeled" via delays on the weapon or Persistent effects, and while one weapon is firing the other will either have to wait or misfires.
As for the animation bug, I assume the Ultralisk tries to use both weapons simultaneously, and while one of the attacks may fail (you have checked it's not actually firing both damage effects, right?) the standard animation trigger is Weapon.AttackStart, so it may be trying to play two animations at the same time even if the actual effect fails.
The validator class is called Unit Order Queue, and checks both an Ability (name) and Ability Command (integer), the latter lets you select specific actions. For example Move has 0=Move, 1=Patrol, 2=Hold Position, 3=Scan Move (a-move), 4=Turn.
Actually for a one-off speed boost just apply it via the Effect - Initial field of the Carry behavior, no validators beyond checking that the worker is eligible to receive the buff in the first place (only Probes/upgrade researched/whatever). You'll still have to implement this on each Carry behavior, in vanilla multiplayer there's one each for Minerals, High Yield Minerals, Assimilators, Extractors and Refineries. Minerals have another variant titled "No Remove" used by Umojan Lab crystals, not sure if those are accessible in multiplayer (just set them to the same as regular Mineral Fields)
Most ability types have various Effect/Behavior fields to apply "on use" stuff, for Effect types (Instant/Target etc.) you can substitute their main effect with a Set.
In the few cases where you aren't given any such fields you can always use a "Unit Order" validator to check for use of the ability itself, for example on a dummy buff.
In this case you'll want 2-3 buffs cycling between each other via the Effect: Final field via Apply Behavior effects, the first is the "ready" state, then the "active", and finally, if desired, the "recharge"
"Ready": Set the "Validator (Remove)" to check for NOT using the Gather-Return Cargo ability. This will remove the buff if the validator returns FALSE (i.e. the Probe currently is returning cargo). Effect:Final should apply "active" (or a Set conatining "active" and "recharge" if you want a cooldown that starts upon activation)
"Active": The movespeed buff. Set the duration here, and if you don't want any cooldowns straight-up apply "ready" via Effect:Final or Effect:Expire (Expire may break the chain and remove the boost ability entirely if the "active" buff is removed by other means); If you want cooldowns, an "upon completion" cooldown would replace "ready" with "recharge" on this setup, or set up nothing if you already use an "on activation" cooldown.
"Recharge": Just set the Duration to the recharge time and apply "ready" upon ending. Again, Expire allows for easy "dispell" effects but may break the chain.
From my understanding the only potential problem is that "ready" can also activate if the Probe is already on the way back when the cooldown comes back up because there's no link to the actual act of harvesting. Instead of chaining the buffs indefinitely you could tie application into the "carry" behavior used by the Gather setup (i.e. "Carry" applies "ready" via Effect:Initial, max 1 stack, and "ready" applies "active" once with no looping, this allows one 4s boost every time the Probe acquires a new resource chunk to hold) Keep in mind each resource type has its own "Carry" behavior and you'll have to modify all of them.
I would be interested to know more about such workarounds if you don't mind. Indeed I don't need the build queue UI, however I would want the player to be able to change a building's production type.
Yeah, that's the work-intensive bit. For a very straightforward (but probably inefficient) setup, consider this:
"train" ability applies a buff to the structure upon completion instead of creating a unit
Units have an aura that applies to capturable structures, max 1 stack to prevent implicit multi-owner use. The on-structure buff pulses or checks BehaviorCount, activating if any of the "unit built" buffs is present (here you need a list of all trainable units, each with a unique dummy buff)
Upon activation, use a Create Unit effect to summon the "trained" unit. Since the owner of the effect chain is the unit that captured the structure you can use that as the owner reference.
For pulse-free activation you can try the Effect: Final field on the aura buff, use a validator to check for presence of a "unit completed" buff (Effect: Final also activates on expiration and structure death, amongst other things), and then remove the "unit completed" buff after the Create Unit went through.
There are many other ways though, you could probably also do Ability:Effect-Instant(cast time/delay=build time) -> Search (for capturing units) -> CreateUnit(Owner=Target of Search), which may cause less periodic checks but heavily relies on the effectiveness of the search at the instant of "unit completion", which may or may not be a problem. Depends on how many AoEs and teleports are being thrown around I guess.
From my limited understanding triggers can be "dynamic", but this will usually be synonymous to "inefficient" because it will involve looping over all generic cases and then checking a condition, where data is bottom-up. You could try a dummy data setup to start up your trigger though:
unit receives ownership aura buff
check current owner
give ownership of "target unit" to player "owner of Caster Unit"
No idea how that would look in actual triggers, but you should be able to grab the scope of a dummy buff/effect somehow, and that's all you need to define the owner.
That said, have you tried messing with the Flags and "Link" options on the Train ability? Sadly neither Train nor Queue abilities seem to have the "abort on ownership change" flag...
There are also many (fairly work-intensive) workarounds if you don't need the build queue UI, using some combination of buffs to handle build time and ownership.
Look at the Events+ field on the Mothership Core unit actor. There are several animation triggers linked to the existing Purify abilities, in particular one ability has 2 different animations assigned.
The LMDummy is aimed at Target Point, maybe it doesn't work with Point type target scopes? And then there's the validators on the effects, which I haven't looked into, if one of those is a LocationRange or scope-specific target check you'll have to change it.
Buff type behaviors act like a Persistent effect on their own, complete with Effect: Final field on the buff, which you can just set to the teleport. The only thing they can't do at all is location offsets.
If you don't want to force the Stalker back if the effect expires you'll probably end up needing a second monitor buff, one for the back-port command and one for the max duration. Maybe someone else has a smarter solution.
Straight-up Enumerate Area validator on the ability or its imminent effect? Also has access to standard area filters and there's a "Worker" tag if you want to keep siege bombing but don't like mineral line BM.
For upgrades you have to define completely new weapons, because it's coded into the baseline properties. The main flags are "only fire at attack target" and "only fire while attacking", additionally a turret or sufficiently large firing arc are required to aim at different units.
Apparently the Behavior/Toggle ability doesn't work well with external buff sources, try an Effect-Instant applying a Remove Behavior effect. Under Commands+ on that ability specify a button so you can assign the correct command on the command card, and place the "Showmonitor" requirement here too, not on the buff you're supposed to be counting (the requirement says "only allow this if the unit has this buff", placing it on the buff means "deactivate the buff if the conditions aren't met")
Specify the buff duration on the buff itself, the way you tried to do it also works in principle, but you have to tick the "Use Duration" flag on the apply effect.
The "teleport back" effect must also be set to teleport the Caster unit. The Persistent needs a duration or it will complete instantly, set the Period Duration to the desired update rate and the Period Count to "desired duration" divided by "Period Duration". You might be able to use the Effect: Final field of the monitor buff itself instead, which allows instant updating without the period.
With all of these modifications I can get it to teleport back to the Blink target location consistently. I don't know why, because the Persistent effect itself occurs at the pre-teleport location, so get all the other issues fixed first and then start playing with the Scope fields. Maybe try just "Target Point" without specifying an effect, otherwise go through Source/Target for all effects in the chain.
0
First you have to define what the "idle" trajectory should look like. In principle you can set any reasonable shape by periodically aiming an Issue Order - Move effect at an offset generated by a Persistent effect. Due to constantly giving orders this makes it somewhat difficult to define the "idle" state though, in terms of coding this "idle" movement looks just the same as if the player had given an order themselves.
The player would also be able to prevent the movement by mashing the "Stop" command faster than the update pulse rate. This is a more general problem though, as technically receiving constant "Stop" orders isn't an "idle" state.
0
For preventing all forms of selection there's the Unselectable flag on the unit. I don't know if you can somehow prevent only box-select, especially if the box contains just that one unit, but the opposite can probably be done using actors/models: Messing with the "radius" of the model or disabling "Add To Proximity System" on the actor should prevent left-click selection while allowing the box. Technically left-click selection is still "allowed" in that case, you simply give the game engine 0 on-screen area that will trigger it.
The various Aliases are for making multiple unit types equal to each other, as explained when you mouse over the fields there's one for double-click/Ctrl-click select and one for grouping once selection has occurred, plus the Tech and Leaderboard ones. I think the Unit-over-Structure box priority is hardcoded and tied to those tags.
0
Damage Response on a Buff type Behavior. Make sure it runs on "Attacker" and tick the "Fatal" flag, then either give lifesteal (not sure if that works) or apply a Modify Unit effect on the Caster unit (i.e. your attacking unit and not the victim) set to heal.
You'll need several effects and validators if the unit has shields and ought to "reverse-damage" itself, i.e. heal HP first and only then the shields. Healing based on enemy health/max health will also be complicated.
0
Check the Mover itself, the default "Fly" mover may have a setting for maximum turn speed. Otherwise I know there was a "turn before moving" flag somewhere, but I have no idea whether it's relevant to your problem. Check on the unit and the Move ability, if it's not there it's related to a more specific use and of no interest to you.
Of course you should also double-check that you changed all relevant fields, there's usually "speed" and "acceleration", and there's a "stationary" turn rate as well.
0
For attack use check the Weapons. The "Shared Cooldown" flag often interferes with having multiple weapons, and I have no idea how having multiple eligible weapons works out if you don't allow a full multitarget: The blade/head swing is "channeled" via delays on the weapon or Persistent effects, and while one weapon is firing the other will either have to wait or misfires.
As for the animation bug, I assume the Ultralisk tries to use both weapons simultaneously, and while one of the attacks may fail (you have checked it's not actually firing both damage effects, right?) the standard animation trigger is Weapon.AttackStart, so it may be trying to play two animations at the same time even if the actual effect fails.
0
The validator class is called Unit Order Queue, and checks both an Ability (name) and Ability Command (integer), the latter lets you select specific actions. For example Move has 0=Move, 1=Patrol, 2=Hold Position, 3=Scan Move (a-move), 4=Turn.
Actually for a one-off speed boost just apply it via the Effect - Initial field of the Carry behavior, no validators beyond checking that the worker is eligible to receive the buff in the first place (only Probes/upgrade researched/whatever). You'll still have to implement this on each Carry behavior, in vanilla multiplayer there's one each for Minerals, High Yield Minerals, Assimilators, Extractors and Refineries. Minerals have another variant titled "No Remove" used by Umojan Lab crystals, not sure if those are accessible in multiplayer (just set them to the same as regular Mineral Fields)
0
Most ability types have various Effect/Behavior fields to apply "on use" stuff, for Effect types (Instant/Target etc.) you can substitute their main effect with a Set.
In the few cases where you aren't given any such fields you can always use a "Unit Order" validator to check for use of the ability itself, for example on a dummy buff.
In this case you'll want 2-3 buffs cycling between each other via the Effect: Final field via Apply Behavior effects, the first is the "ready" state, then the "active", and finally, if desired, the "recharge"
From my understanding the only potential problem is that "ready" can also activate if the Probe is already on the way back when the cooldown comes back up because there's no link to the actual act of harvesting. Instead of chaining the buffs indefinitely you could tie application into the "carry" behavior used by the Gather setup (i.e. "Carry" applies "ready" via Effect:Initial, max 1 stack, and "ready" applies "active" once with no looping, this allows one 4s boost every time the Probe acquires a new resource chunk to hold) Keep in mind each resource type has its own "Carry" behavior and you'll have to modify all of them.
0
Yeah, that's the work-intensive bit. For a very straightforward (but probably inefficient) setup, consider this:
There are many other ways though, you could probably also do Ability:Effect-Instant(cast time/delay=build time) -> Search (for capturing units) -> CreateUnit(Owner=Target of Search), which may cause less periodic checks but heavily relies on the effectiveness of the search at the instant of "unit completion", which may or may not be a problem. Depends on how many AoEs and teleports are being thrown around I guess.
0
From my limited understanding triggers can be "dynamic", but this will usually be synonymous to "inefficient" because it will involve looping over all generic cases and then checking a condition, where data is bottom-up. You could try a dummy data setup to start up your trigger though:
No idea how that would look in actual triggers, but you should be able to grab the scope of a dummy buff/effect somehow, and that's all you need to define the owner.
That said, have you tried messing with the Flags and "Link" options on the Train ability? Sadly neither Train nor Queue abilities seem to have the "abort on ownership change" flag...
There are also many (fairly work-intensive) workarounds if you don't need the build queue UI, using some combination of buffs to handle build time and ownership.
0
Look at the Events+ field on the Mothership Core unit actor. There are several animation triggers linked to the existing Purify abilities, in particular one ability has 2 different animations assigned.
0
The LMDummy is aimed at Target Point, maybe it doesn't work with Point type target scopes? And then there's the validators on the effects, which I haven't looked into, if one of those is a LocationRange or scope-specific target check you'll have to change it.
0
Buff type behaviors act like a Persistent effect on their own, complete with Effect: Final field on the buff, which you can just set to the teleport. The only thing they can't do at all is location offsets.
If you don't want to force the Stalker back if the effect expires you'll probably end up needing a second monitor buff, one for the back-port command and one for the max duration. Maybe someone else has a smarter solution.
0
Straight-up Enumerate Area validator on the ability or its imminent effect? Also has access to standard area filters and there's a "Worker" tag if you want to keep siege bombing but don't like mineral line BM.
0
For upgrades you have to define completely new weapons, because it's coded into the baseline properties. The main flags are "only fire at attack target" and "only fire while attacking", additionally a turret or sufficiently large firing arc are required to aim at different units.
0
Apparently the Behavior/Toggle ability doesn't work well with external buff sources, try an Effect-Instant applying a Remove Behavior effect. Under Commands+ on that ability specify a button so you can assign the correct command on the command card, and place the "Showmonitor" requirement here too, not on the buff you're supposed to be counting (the requirement says "only allow this if the unit has this buff", placing it on the buff means "deactivate the buff if the conditions aren't met")
Specify the buff duration on the buff itself, the way you tried to do it also works in principle, but you have to tick the "Use Duration" flag on the apply effect.
The "teleport back" effect must also be set to teleport the Caster unit. The Persistent needs a duration or it will complete instantly, set the Period Duration to the desired update rate and the Period Count to "desired duration" divided by "Period Duration". You might be able to use the Effect: Final field of the monitor buff itself instead, which allows instant updating without the period.
With all of these modifications I can get it to teleport back to the Blink target location consistently. I don't know why, because the Persistent effect itself occurs at the pre-teleport location, so get all the other issues fixed first and then start playing with the Scope fields. Maybe try just "Target Point" without specifying an effect, otherwise go through Source/Target for all effects in the chain.