It'll be just as accurate, but will require some sort of key press input to function like a standard ability and may have some input delay (although significantly less than if you were to use mouse position). I would create a dummy ability that does nothing but has the same cost/cooldown as the regular ability to fire with "regular mode".
So use QuickCastModeOn, and give players that want to use regular old targeting mode an upgrade that replaces the ability buttons on their command card with (identical) buttons for dummy abilities.
As for how targeting mode works, take a look at the attached demo map. Pressing "1" enters targeting mode for psi storm for the selected templars, functionally mimicking how normal ability targeting works which can be used in conjunction with Quick Cast mode (press T to use psi storm this way).
ALTERNATIVELY, with you could just use QuickCastModeOnUp as a compromise since it shows the ability targeting actor while the ability hotkey is held down.
You can now also enter targeting mode for an ability/unit group via triggers so you could use that create toggleable quick casting system per player. But it would be some extra work and may not play perfectly.
My first post addresses the Quick Cast/Smart Cast naming convention. Previously this was only possible by using triggers to cast abilities at mouse position, which suffered from input lag.
I'm not sure you've configured the abilities correctly- the abilities should be cast at mouse position on key press. Take a look at this demo map. All I've done is turn Quick Cast on and reduce the Psi Storm ability cost.
Quick Casting support (also known as Smart Casting in Heroes of the Storm and League of Legends) was added to SC2 in the lastest patch! Note that this is different than the Smart Cast ability option which configured issues configured ability orders on mouse click.
For those unfamiliar, quick casting issues the ability order at the mouse position when the hotkey is pressed (1 input), rather than entering targeting mode (2 inputs). You can configure quick cast to function on key down or on key up in Game UI Data.
If there's no alternate model, the you'll need 3ds max or blender to remove the stand.
Alternatively you could give the doodad a negative height (selecting the doodad and pressing Page Down adds -0.1 height) to sink the stand into the ground, making it less visible.
If the stands are too short, you could scale up the Z axis of the doodad and see how that looks.
You would think so but they used launch missile effects.
I suspect kinetics were implemented after the campaign was finished since kinetics don't seem to be fully integrated into the editor. They were even less complete when 3.0 launched.
Ah, yes and for gravity! I'll be writing a tutorial on using kinetics to set and modify velocities. Basic 2D platformer systems were gathered on google and translated into SC2 kinetic data. Cliff notes:
Every game tick the unit is in the air, a stack of gravity (negative vertical velocity) is applied. When the unit lands, vertical velocity is set to 0.
On JumpKeyDown, a positive vertical velocity as added to the hero (thus starting gravity's effect on the hero).
On JumpKeyUp the vertical velocity is clamped if the hero is still ascending, limiting the height of the jump if the key is released early.
My current working model for collision keeps track of the unit's position and X/Y velocities every game tick the unit is in motion. If the unit's "hitbox" would be in intersect the ground next tick, it is prevented by a combination of reducing/removing velocity and moving the unit instantly (very short distances, to make sure the units feet always are at the same height on the ground).
The grey shaded areas are 4x4 block units that use search areas to act as collision regions. Kinetics are used to give our hero WASD platformer movement!
Ah, I thought the raven's were individually controllable and gave you an overly complex solution. What I've done is have the persistent run two search effects each period. One looking for units to damage and one looking for a raven. When a raven is found, the persistent effect is destroyed. This could be done with enum's and persistent flags but I've lost my notes on how enumate area validators work.
A few notes:
1. The "Randomness" of damage was previously caused by setting the behavior tick to 0.625 instead of 0.0625. The latter has the persistent firing every game tick (1/16th of a game second) while the former only fires 1 in 10.
2. I removed the pre-launch behavior and added the beam launch behavior to the beam head units, resulting in the beam firing immediately. The damage area then expands with the beam.
3. I used rectangular search areas and left the debug trace on in case you wanted to make adjustments damage area.
It uses a rectangular search area (added in 3.0). I left the debug trace on in the demo- the yellow rectangle within the conveyor belt.
By adjusting the distance and duration of a translate kinetic you can specify the force applied. Note that moving 1MU (map unit) over 1.0 second over 2 cycles if functionally similar to moving 2MU over 2.0 seconds over 1 cycle.
And yes, the cannons slowly drift away from the immortal as time passes. I'm not sure why this occurs.
0
@Deadzergling: Go
It'll be just as accurate, but will require some sort of key press input to function like a standard ability and may have some input delay (although significantly less than if you were to use mouse position). I would create a dummy ability that does nothing but has the same cost/cooldown as the regular ability to fire with "regular mode".
So use QuickCastModeOn, and give players that want to use regular old targeting mode an upgrade that replaces the ability buttons on their command card with (identical) buttons for dummy abilities.
As for how targeting mode works, take a look at the attached demo map. Pressing "1" enters targeting mode for psi storm for the selected templars, functionally mimicking how normal ability targeting works which can be used in conjunction with Quick Cast mode (press T to use psi storm this way).
ALTERNATIVELY, with you could just use QuickCastModeOnUp as a compromise since it shows the ability targeting actor while the ability hotkey is held down.
0
@Deadzergling: Go
You can now also enter targeting mode for an ability/unit group via triggers so you could use that create toggleable quick casting system per player. But it would be some extra work and may not play perfectly.
@GlornII: Go
My first post addresses the Quick Cast/Smart Cast naming convention. Previously this was only possible by using triggers to cast abilities at mouse position, which suffered from input lag.
0
@Deadzergling: Go
I'm not sure you've configured the abilities correctly- the abilities should be cast at mouse position on key press. Take a look at this demo map. All I've done is turn Quick Cast on and reduce the Psi Storm ability cost.
0
@Zer0skiller: Go
Considering this feature was added last week, I'm not sure that's true =P
0
@Zer0skiller
This doesn't appear possible at the moment.
I'd keep an eye out over the next few patches though, doesn't seem like it's been fully implemented (hence EDSTR_FIELDNAME...)
@Deadzergling
OnUp/OnDown simply decides when the order is issued. The field does not seem modifiable at all. How do you mean "more accurate"?
0
Quick Casting support (also known as Smart Casting in Heroes of the Storm and League of Legends) was added to SC2 in the lastest patch! Note that this is different than the Smart Cast ability option which configured issues configured ability orders on mouse click.
For those unfamiliar, quick casting issues the ability order at the mouse position when the hotkey is pressed (1 input), rather than entering targeting mode (2 inputs). You can configure quick cast to function on key down or on key up in Game UI Data.
0
If there's no alternate model, the you'll need 3ds max or blender to remove the stand.
Alternatively you could give the doodad a negative height (selecting the doodad and pressing Page Down adds -0.1 height) to sink the stand into the ground, making it less visible.
If the stands are too short, you could scale up the Z axis of the doodad and see how that looks.
0
@JayceeCordova: Go
Holy necro batman
0
@willuwontu: Go
You would think so but they used launch missile effects.
I suspect kinetics were implemented after the campaign was finished since kinetics don't seem to be fully integrated into the editor. They were even less complete when 3.0 launched.
0
@willuwontu: Go
Ah, yes and for gravity! I'll be writing a tutorial on using kinetics to set and modify velocities. Basic 2D platformer systems were gathered on google and translated into SC2 kinetic data. Cliff notes:
Every game tick the unit is in the air, a stack of gravity (negative vertical velocity) is applied. When the unit lands, vertical velocity is set to 0.
On JumpKeyDown, a positive vertical velocity as added to the hero (thus starting gravity's effect on the hero).
On JumpKeyUp the vertical velocity is clamped if the hero is still ascending, limiting the height of the jump if the key is released early.
My current working model for collision keeps track of the unit's position and X/Y velocities every game tick the unit is in motion. If the unit's "hitbox" would be in intersect the ground next tick, it is prevented by a combination of reducing/removing velocity and moving the unit instantly (very short distances, to make sure the units feet always are at the same height on the ground).
0
@willuwontu: Go
The grey shaded areas are 4x4 block units that use search areas to act as collision regions. Kinetics are used to give our hero WASD platformer movement!
0
@willuwontu: Go
On the other hand, this property of translates makes it perfect for things like player input and gravity in 2D games.
A preview of what's to come:
0
@abvdzh: Go
Yup, that's what kinetic sequences are for! Would have to tinker to get it looking right though
0
@uroboros1987: Go
Ah, I thought the raven's were individually controllable and gave you an overly complex solution. What I've done is have the persistent run two search effects each period. One looking for units to damage and one looking for a raven. When a raven is found, the persistent effect is destroyed. This could be done with enum's and persistent flags but I've lost my notes on how enumate area validators work.
A few notes:
1. The "Randomness" of damage was previously caused by setting the behavior tick to 0.625 instead of 0.0625. The latter has the persistent firing every game tick (1/16th of a game second) while the former only fires 1 in 10.
2. I removed the pre-launch behavior and added the beam launch behavior to the beam head units, resulting in the beam firing immediately. The damage area then expands with the beam.
3. I used rectangular search areas and left the debug trace on in case you wanted to make adjustments damage area.
0
@willuwontu: Go
It uses a rectangular search area (added in 3.0). I left the debug trace on in the demo- the yellow rectangle within the conveyor belt.
By adjusting the distance and duration of a translate kinetic you can specify the force applied. Note that moving 1MU (map unit) over 1.0 second over 2 cycles if functionally similar to moving 2MU over 2.0 seconds over 1 cycle.
And yes, the cannons slowly drift away from the immortal as time passes. I'm not sure why this occurs.