Question:
How can I create a weapon similar to the Void Ray's prismatic ray? I want a weapon that "charges up" as the unit moves. I'm thinking about creating a Behavior that has a Effect - Final and a set of effects. The first effect would enable a weapon, and the subsequent effects increase the weapon's damage. However, the problem I'm having is how to make the effect fire when the unit begins moving. There is an actor event that looks promising, but I can't seem to make it fire an effect.
Any help?
Thanks.
Context:
I'm developing a map that is going to focus on movement. Right now I've got a Hellion that drifts and powerslides using a Move Instantly effect that pulls its angle from some trigonometry functions. It also has a 'jump' ability that fires every time it encounters a cliff or height difference (high to low ground) beyond a certain threshold. The first is purely trigger-based, the other is a hybrid approach. I'm comfortable with trigger editing, but I'm having a hard time learning the Data layer.
the behavior that checks if the unit is moving or not should always be on, then add or remove charges accordingly
have a high max stack count on charges, have these charges increase the damage of the weapon, have a validator in the "apply behavior" effect that checks to see if the unit is moving.
You could also use a switch effect that checks if unit is moving, add behavior, if unit is stopped, remove all behaviors.
Though, if you want it to count powerslides and stuff you may need to trigger in a dummy behavior that can be used to check for if the moving validator fails, so it will still charge the ramming while sliding.
Alternatively, you could also use the "charging" buff like acceleration, and have the buff not only increase weapon damage but speed as well, to more accurately reflect momentum. Though if you use a trigger base, you can probably grab exact speed and set the stack count based on that.
I added a "Momentum Check" permanent behavior that ticks every 3 seconds, firing a Switch effect as its final that (right now) only has a Unit is Not Stationary validator. The only option in the switch right now is an area search. That area search has its source location offset ahead of the unit, encompassing the front and sides of the unit.
The effect Kraith - Crashing Charge Target Set is applied to any units found by the search.
The end result? Squished zerglings and knocked-back roaches.
I thought about a serie of buffes that will be all deactivated with the validator not moves or not forced to move. So the first behavior creates an effect within like 5 seconds that add a behavior with the same type of effect and etc. So you can add an infinite number of buff and they will be easily deactivated.
Actually, I've run into what seems to be a common issue: The force element doesn't fire correctly. That is, it doesn't actually knock the units affected. I think it's a problem in how the effect creates the vector between the source unit and the target. Even with ridiculous stacks of Apply Force effects and a behavior to up the target's speed to 160, the affected units don't get moved.
I discovered this by linking (through a Catalog - Set Field trigger action) the unit's current speed to the damage of the effect. I've given up on that for now and moved on to the crash feature of the same map.
So far so good on that (units take damage when they crash into walls and structures) but I'm having a hell of a time trying to come up with an edge finding method in order to determine the normal of a cliff.
Rather than having the switch effect, you could always have the "IsMoving" validator disable your "Momentum Check" behavior. Then it won't perform the periodic effect so long as the unit is not moving.
Actually, that works! It doesn't solve the knockback issue, but the validator (used IsNotStationary) does means it's not necessary to run a periodic check.
To make the knockback work correctly, you have to take into account that Apply Force effects take into account real physics. Consequently if you do knockback effects while the unit is on the ground, the ground friction of the unit will cause it to move barely at all. The solution to this is to apply a behavior to the target that lifts them, then following with the force effects, and then removing the behavior after the force effects are done. This is best done via a Create Persistent effect, with an initial effect applying the lift behavior, with the periodic effect being the force effects, and the expire effect removing the lift behavior.
Yeah I've got that structure set up. It has the side-effect that it allows the ramming unit to keep moving on its path (which is good). However, even if the units get lifted and damaged, they don't move. They ARE subjected to the apply force, but the vector seems to be zeroed out so the "force" they're subjected to keeps them in place, rather than fly off.
Hi folks,
Question: How can I create a weapon similar to the Void Ray's prismatic ray? I want a weapon that "charges up" as the unit moves. I'm thinking about creating a Behavior that has a Effect - Final and a set of effects. The first effect would enable a weapon, and the subsequent effects increase the weapon's damage. However, the problem I'm having is how to make the effect fire when the unit begins moving. There is an actor event that looks promising, but I can't seem to make it fire an effect.
Any help?
Thanks.
Context: I'm developing a map that is going to focus on movement. Right now I've got a Hellion that drifts and powerslides using a Move Instantly effect that pulls its angle from some trigonometry functions. It also has a 'jump' ability that fires every time it encounters a cliff or height difference (high to low ground) beyond a certain threshold. The first is purely trigger-based, the other is a hybrid approach. I'm comfortable with trigger editing, but I'm having a hard time learning the Data layer.
@EmperorCee: Go
You could create a behavior that has a periodic effect to add another behavior,
Behavior: "Ramming" periodic 1s, effect add behavior "charges"
the behavior that checks if the unit is moving or not should always be on, then add or remove charges accordingly
have a high max stack count on charges, have these charges increase the damage of the weapon, have a validator in the "apply behavior" effect that checks to see if the unit is moving.
You could also use a switch effect that checks if unit is moving, add behavior, if unit is stopped, remove all behaviors.
Though, if you want it to count powerslides and stuff you may need to trigger in a dummy behavior that can be used to check for if the moving validator fails, so it will still charge the ramming while sliding.
Alternatively, you could also use the "charging" buff like acceleration, and have the buff not only increase weapon damage but speed as well, to more accurately reflect momentum. Though if you use a trigger base, you can probably grab exact speed and set the stack count based on that.
@EchoedRequiem:
Thanks for the advice!
What I ended up doing is this:
I added a "Momentum Check" permanent behavior that ticks every 3 seconds, firing a Switch effect as its final that (right now) only has a Unit is Not Stationary validator. The only option in the switch right now is an area search. That area search has its source location offset ahead of the unit, encompassing the front and sides of the unit.
The effect Kraith - Crashing Charge Target Set is applied to any units found by the search.
The end result? Squished zerglings and knocked-back roaches.
So solved?
Contribute to the wiki (Wiki button at top of page) Considered easy altering of the unit textures?
https://www.sc2mapster.com/forums/resources/tutorials/179654-data-actor-events-message-texture-select-by-id
https://media.forgecdn.net/attachments/187/40/Screenshot2011-04-17_09_16_21.jpg
I thought about a serie of buffes that will be all deactivated with the validator not moves or not forced to move. So the first behavior creates an effect within like 5 seconds that add a behavior with the same type of effect and etc. So you can add an infinite number of buff and they will be easily deactivated.
@tatatatate: Go
Actually, I've run into what seems to be a common issue: The force element doesn't fire correctly. That is, it doesn't actually knock the units affected. I think it's a problem in how the effect creates the vector between the source unit and the target. Even with ridiculous stacks of Apply Force effects and a behavior to up the target's speed to 160, the affected units don't get moved.
I discovered this by linking (through a Catalog - Set Field trigger action) the unit's current speed to the damage of the effect. I've given up on that for now and moved on to the crash feature of the same map.
So far so good on that (units take damage when they crash into walls and structures) but I'm having a hell of a time trying to come up with an edge finding method in order to determine the normal of a cliff.
@EmperorCee: Go
Rather than having the switch effect, you could always have the "IsMoving" validator disable your "Momentum Check" behavior. Then it won't perform the periodic effect so long as the unit is not moving.
@MasterWrath: Go
Actually, that works! It doesn't solve the knockback issue, but the validator (used IsNotStationary) does means it's not necessary to run a periodic check.
To make the knockback work correctly, you have to take into account that Apply Force effects take into account real physics. Consequently if you do knockback effects while the unit is on the ground, the ground friction of the unit will cause it to move barely at all. The solution to this is to apply a behavior to the target that lifts them, then following with the force effects, and then removing the behavior after the force effects are done. This is best done via a Create Persistent effect, with an initial effect applying the lift behavior, with the periodic effect being the force effects, and the expire effect removing the lift behavior.
@ArcaneDurandel: Go
Yeah I've got that structure set up. It has the side-effect that it allows the ramming unit to keep moving on its path (which is good). However, even if the units get lifted and damaged, they don't move. They ARE subjected to the apply force, but the vector seems to be zeroed out so the "force" they're subjected to keeps them in place, rather than fly off.