SiteOps, I already told you you'd need AttachCenter or something. You can view the valid attachment points in the Cutscene module (they're defined individually for each model, but all units have Origin and Center)
For the "attach" SOps to work you also need the actor you'll be attaching to, hence the "At" Term I also mentioned in my previous post. Behavior triggers automatically default to the unit that gains the behavior, but for Effects there may not be a valid unit linked to them. Best example: Psi Storm, the lightning field is always placed where the AoE cursor was, even if there's nothing in range. That's the "At Effect" scope.
You can get the pictures yourself, the easiest template probably are the "dark" Protoss from the campaign. Pick a unit with a "dark" model (e.g. Stalker), open the Events+ field on its Actor, and check all non-grey entries. There'll be half a dozen starting with "Upgrade.DarkProtoss", including some to revert the visuals if the upgrade is removed.
Marines should also work for the Combat Shield upgrade, but stay away from Zerglings if you're inexperienced as they'll have a lot of other events to handle burrowing.
Look at the Zeratul/Maar Blink abilities from WoL campaign, they create a smoke trail between the start and end positions by aligning two direction-specific models. I think it's something with an SOpForwardVector, not sure if it's aligned to Unit Facing or Target Point though.
Err, you weren't supposed to delete all the previous stuff, you do need animation triggers and a destruction event. If this is meant to be a one-shot animation copy from the original Karass ability (where the model came from), if it's meant to loop you'll have to put in a bit more work.
I suggest you read some basic tutorials on Actors, or at least the full wiki entry, and compare to existing assets to gain a better understanding of the system.
If you want to stick to the Effect trigger you'll want to add a Term to it to use the correct scope, probably Caster or Target (both work if it's self-cast). Under Hosting: Host Site Operations you'll need to define the attachment controllers, for that model SOpAttachCenter should suffice (might be named "Attach Center" or so)
Oh, and regarding your original post, the text color marks which source that data is drawn from: Green is the current map/mod, yellow is custom mods, blue is Blizzard-made mods, grey is the very basic editor presets. Red text appears in the rare cases where you can actually delete the grey presets, such as in Events+, and replaces grey for all remaining entries. The appearance of red text doesn't mean you've made an error per se, but it probably means you took the wrong source to copy from.
Just from the screenshot, it seems you missed to set any actual commands there. The creation trigger should normally have the "Start" or "Finish" keyword added (Effect.ArmorLock.Start), not sure if this works with no key assigned.
ActorCreation always defaults to "this actor", so you don't need to specify its name. Same goes for your AnimDone event, if you want to check the animation name add a condition "AnimName" under the event trigger.
And AnimPlay needs keywords to know which animation it's actually supposed to play. You only assigned the "name" used by the editor interface, which is used to reference that animation in other events. For "standard" naming conventions that line should read "AnimPlay Stand Stand", the first "Stand" is the name, the second is the keyword that's sent to the 3d model. To find out which keywords you need, open the model in the Cutscene viewer.
AnimDone is uncommon for "continuous" animations, this will trigger once the animation has run through once, the timing of that is defined by the (often arbitrary) length in the 3d model. Usually 1-5s, but the WoL Time Bomb model would persist for 20-30s...
If the host unit can be removed by non-standard means (trigger removal etc.) you might also want an event ActorOrphan->Destroy, just to be sure. I think the game does this automatically by now.
You really should look at existing setups, and copy one of those for a start. For instance they use AnimBracketStart instead of AnimPlay, which allows for easy "Intro" and "Outro" animations. Oh, and make sure you have your Hosting and SiteOps set up properly (not visible in the screenshot), or your model may appear at the bottom-left corner of the map, if at all.
There is of course also the (probably hardcoded) distinction between "units" and "structures". I don't know which of the fields actually controls it, but if any "unit" is in the rectangle it is prioritised over an arbitrarily high number of "structures" in the same area. This is however dependent on "units" being present, and will never result in an empty selection.
If you have a working instance in the same map, select that and the structure you're working on simultaneously, which will show only the fields that differ between the two (or at least there's one option to do that). Check both the Unit and the Actor, and expand the "+" array fields as much as possible via the viewer options at the top of the data module.
1) You'll need either a new Damage Response buff for each stack count, or you mash them all together into one and use Combine-OR validators to make a whitelist of unit types for each one. You'd also have to place the Damage Response on every unit that's supposed to gain stacks.
2) A "Mana Shield" type setup should be doable for using energy as shields, other than that the 3 existing "Vitals" are hardcoded. "Wild Mutation" from HotS campaign uses Protoss shields btw, just recolored.
3) Dummy buffs to mark "cloaked" units and "detectors", and an Enumerate Area validator on the cloak (or pulsing aura on the detector) should be enough for 1v1, along with something to exclude targeting a "cloaked" unit. For additional spectators it'll probably be much more complex, as the "revealed" state would have to be tracked per player somehow. Even then it's probably trivial to do the visuals right, the problem is making sure units don't auto-target without detection. And ally shared sight will be a nightmare.
If you snoop around in the unused assets you'll find the "falling" animation as a separate model, but only for an outdated Misisle Turret missile.
You should be able to do this globally for all affected missiles (or for specific groups via validators, or set it individually on each missile of course). Just create a Model type actor with the desired model (Banana in your case) at the position of the missile, and use an ACTOR "Mover" (NOT a "missile" mover, an actor of the "Site Mover" type), those can be set to a constant acceleration.
I have no idea how to tap into the physics engine for the "rolling on the ground" part though, if there's no easy way to set that up (borrowing from "HotS Unit Death" actors maybe?) the best I can think of is a "Random Point in Circle" SiteOp to pick a direction, and another, slow, horizontal actor Mover, which you switch to upon reaching Z=0.
You can aim all of these actor movements at the actual missile too, via a Simple type actor aiming its events at "_Missile" via the Target line in the top-right. Just make sure all animation triggers ignore unit timescale, and don't kill off the missile before the "animation" completes. For the banana version include a ModelSwap event (I'm assuming you want to turn the missiles into bananas as the Time Bomb destroys them, you can also create a separate Simple actor upon creation of any missile to change its model into a banana from the start, e.g. for an April Fools patch)
So, players won't be able to control these "units", or otherwise interfere with their pathing except for a select few abilities?
In that case missiles might work, as long as you define their impact point properly. You can redirect them mid-flight, or create a new missile aimed at e.g. the center of a black hole, not sure if Apply Force effects work properly with missile movers though.
Maybe you could also do something with pathing footprints like the Zhakul'Das light bridge from WoL campaign, I'm not sure if you can limit those to specific collision planes though, or just the movement type.
Try applying a dummy buff via Expire, and validate for NOT having that buff on Final. If it doesn't work straight-up make the dummy last 2 ticks and delay the actual Final effect 1 tick via a Persistent effect.
Final runs on pretty much any form of removal, including expiry and death of the host. Haven't tested "Remove" type death or trigger-based removal yet though.
Expire only procs if the buff ends because of its own duration timer.
The problem with missiles is that they require distinct Launch and Impact locations, with no "idle" phase between orders. In principle you could make an actual unit that launches itself as a missile upon right-click or a fake "Move" ability, but you can't really do damage reactions or a-move target tracking that way. At least not in a simple, intuitive fashion that won't lag out everyone when 100+ of those units are moving about at the same time...
The Model has over a dozen "walk" animations with letter keys, to match the various walking directions. Hardcoded to the Immortal and Colossus.
The turret is your standard-fare "let this part of the model rotate independently" setup. It also requires Model hardcoding, as the rotating part has to be hosted on the turret attachment point (usually TurretZ), but many more models support it. In principle you can make anything into a TurretZ by hosting it as an attachment onto the Phoenix model, since the entire visible asset rotates around its Origin.
That's the tricky part, you somehow have to define when a unit is "idle" and allow the player to interrupt the passive movement orders with their own commands. For a start you can make Unit Order Queue validators to check for the Stop and Move orders, and only run your passive if one of those is being executed. This would allow the player to interrupt it through all means except Stop and Move, notably "a-move" would still work. Oh, and you'll have to do something about Patrol and Hold Position too.
It may be a hardcoded "feature" of the movement type, as I recall in one of the TeamLiquid "depth of micro" videos they said ground units with a "moving shot" were impossible due to the game engine, this may be the reverse problem.
Maybe instead try starting from the Colossus movement/collision scheme and see if you can get that to pathe above "abyss" terrain (cliff level 0).
0
SiteOps, I already told you you'd need AttachCenter or something. You can view the valid attachment points in the Cutscene module (they're defined individually for each model, but all units have Origin and Center)
For the "attach" SOps to work you also need the actor you'll be attaching to, hence the "At" Term I also mentioned in my previous post. Behavior triggers automatically default to the unit that gains the behavior, but for Effects there may not be a valid unit linked to them. Best example: Psi Storm, the lightning field is always placed where the AoE cursor was, even if there's nothing in range. That's the "At Effect" scope.
0
You can get the pictures yourself, the easiest template probably are the "dark" Protoss from the campaign. Pick a unit with a "dark" model (e.g. Stalker), open the Events+ field on its Actor, and check all non-grey entries. There'll be half a dozen starting with "Upgrade.DarkProtoss", including some to revert the visuals if the upgrade is removed.
Marines should also work for the Combat Shield upgrade, but stay away from Zerglings if you're inexperienced as they'll have a lot of other events to handle burrowing.
0
Look at the Zeratul/Maar Blink abilities from WoL campaign, they create a smoke trail between the start and end positions by aligning two direction-specific models. I think it's something with an SOpForwardVector, not sure if it's aligned to Unit Facing or Target Point though.
0
Err, you weren't supposed to delete all the previous stuff, you do need animation triggers and a destruction event. If this is meant to be a one-shot animation copy from the original Karass ability (where the model came from), if it's meant to loop you'll have to put in a bit more work.
I suggest you read some basic tutorials on Actors, or at least the full wiki entry, and compare to existing assets to gain a better understanding of the system.
If you want to stick to the Effect trigger you'll want to add a Term to it to use the correct scope, probably Caster or Target (both work if it's self-cast). Under Hosting: Host Site Operations you'll need to define the attachment controllers, for that model SOpAttachCenter should suffice (might be named "Attach Center" or so)
Oh, and regarding your original post, the text color marks which source that data is drawn from: Green is the current map/mod, yellow is custom mods, blue is Blizzard-made mods, grey is the very basic editor presets. Red text appears in the rare cases where you can actually delete the grey presets, such as in Events+, and replaces grey for all remaining entries. The appearance of red text doesn't mean you've made an error per se, but it probably means you took the wrong source to copy from.
0
@Cybrok: Go
Just from the screenshot, it seems you missed to set any actual commands there. The creation trigger should normally have the "Start" or "Finish" keyword added (Effect.ArmorLock.Start), not sure if this works with no key assigned.
ActorCreation always defaults to "this actor", so you don't need to specify its name. Same goes for your AnimDone event, if you want to check the animation name add a condition "AnimName" under the event trigger.
And AnimPlay needs keywords to know which animation it's actually supposed to play. You only assigned the "name" used by the editor interface, which is used to reference that animation in other events. For "standard" naming conventions that line should read "AnimPlay Stand Stand", the first "Stand" is the name, the second is the keyword that's sent to the 3d model. To find out which keywords you need, open the model in the Cutscene viewer.
AnimDone is uncommon for "continuous" animations, this will trigger once the animation has run through once, the timing of that is defined by the (often arbitrary) length in the 3d model. Usually 1-5s, but the WoL Time Bomb model would persist for 20-30s...
If the host unit can be removed by non-standard means (trigger removal etc.) you might also want an event ActorOrphan->Destroy, just to be sure. I think the game does this automatically by now.
You really should look at existing setups, and copy one of those for a start. For instance they use AnimBracketStart instead of AnimPlay, which allows for easy "Intro" and "Outro" animations. Oh, and make sure you have your Hosting and SiteOps set up properly (not visible in the screenshot), or your model may appear at the bottom-left corner of the map, if at all.
0
There is of course also the (probably hardcoded) distinction between "units" and "structures". I don't know which of the fields actually controls it, but if any "unit" is in the rectangle it is prioritised over an arbitrarily high number of "structures" in the same area. This is however dependent on "units" being present, and will never result in an empty selection.
If you have a working instance in the same map, select that and the structure you're working on simultaneously, which will show only the fields that differ between the two (or at least there's one option to do that). Check both the Unit and the Actor, and expand the "+" array fields as much as possible via the viewer options at the top of the data module.
0
1) You'll need either a new Damage Response buff for each stack count, or you mash them all together into one and use Combine-OR validators to make a whitelist of unit types for each one. You'd also have to place the Damage Response on every unit that's supposed to gain stacks.
2) A "Mana Shield" type setup should be doable for using energy as shields, other than that the 3 existing "Vitals" are hardcoded. "Wild Mutation" from HotS campaign uses Protoss shields btw, just recolored.
3) Dummy buffs to mark "cloaked" units and "detectors", and an Enumerate Area validator on the cloak (or pulsing aura on the detector) should be enough for 1v1, along with something to exclude targeting a "cloaked" unit. For additional spectators it'll probably be much more complex, as the "revealed" state would have to be tracked per player somehow. Even then it's probably trivial to do the visuals right, the problem is making sure units don't auto-target without detection. And ally shared sight will be a nightmare.
0
If you snoop around in the unused assets you'll find the "falling" animation as a separate model, but only for an outdated Misisle Turret missile.
You should be able to do this globally for all affected missiles (or for specific groups via validators, or set it individually on each missile of course). Just create a Model type actor with the desired model (Banana in your case) at the position of the missile, and use an ACTOR "Mover" (NOT a "missile" mover, an actor of the "Site Mover" type), those can be set to a constant acceleration.
I have no idea how to tap into the physics engine for the "rolling on the ground" part though, if there's no easy way to set that up (borrowing from "HotS Unit Death" actors maybe?) the best I can think of is a "Random Point in Circle" SiteOp to pick a direction, and another, slow, horizontal actor Mover, which you switch to upon reaching Z=0.
You can aim all of these actor movements at the actual missile too, via a Simple type actor aiming its events at "_Missile" via the Target line in the top-right. Just make sure all animation triggers ignore unit timescale, and don't kill off the missile before the "animation" completes. For the banana version include a ModelSwap event (I'm assuming you want to turn the missiles into bananas as the Time Bomb destroys them, you can also create a separate Simple actor upon creation of any missile to change its model into a banana from the start, e.g. for an April Fools patch)
0
So, players won't be able to control these "units", or otherwise interfere with their pathing except for a select few abilities?
In that case missiles might work, as long as you define their impact point properly. You can redirect them mid-flight, or create a new missile aimed at e.g. the center of a black hole, not sure if Apply Force effects work properly with missile movers though.
Maybe you could also do something with pathing footprints like the Zhakul'Das light bridge from WoL campaign, I'm not sure if you can limit those to specific collision planes though, or just the movement type.
0
Try applying a dummy buff via Expire, and validate for NOT having that buff on Final. If it doesn't work straight-up make the dummy last 2 ticks and delay the actual Final effect 1 tick via a Persistent effect.
0
Final runs on pretty much any form of removal, including expiry and death of the host. Haven't tested "Remove" type death or trigger-based removal yet though.
Expire only procs if the buff ends because of its own duration timer.
0
@Someguy3141: Go
The problem with missiles is that they require distinct Launch and Impact locations, with no "idle" phase between orders. In principle you could make an actual unit that launches itself as a missile upon right-click or a fake "Move" ability, but you can't really do damage reactions or a-move target tracking that way. At least not in a simple, intuitive fashion that won't lag out everyone when 100+ of those units are moving about at the same time...
0
The Model has over a dozen "walk" animations with letter keys, to match the various walking directions. Hardcoded to the Immortal and Colossus.
The turret is your standard-fare "let this part of the model rotate independently" setup. It also requires Model hardcoding, as the rotating part has to be hosted on the turret attachment point (usually TurretZ), but many more models support it. In principle you can make anything into a TurretZ by hosting it as an attachment onto the Phoenix model, since the entire visible asset rotates around its Origin.
0
That's the tricky part, you somehow have to define when a unit is "idle" and allow the player to interrupt the passive movement orders with their own commands. For a start you can make Unit Order Queue validators to check for the Stop and Move orders, and only run your passive if one of those is being executed. This would allow the player to interrupt it through all means except Stop and Move, notably "a-move" would still work. Oh, and you'll have to do something about Patrol and Hold Position too.
0
It may be a hardcoded "feature" of the movement type, as I recall in one of the TeamLiquid "depth of micro" videos they said ground units with a "moving shot" were impossible due to the game engine, this may be the reverse problem.
Maybe instead try starting from the Colossus movement/collision scheme and see if you can get that to pathe above "abyss" terrain (cliff level 0).