You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Knockback3's design is to act as a kind of global physics system for units in a map. It behaves well when you use it for everything, and poorly if you mix and match.
The implication is that applying knockback to a unit in motion is an additive effect. setVel can be used when an instantaneous interruption is needed.
As such, scoping 2D knockback opens some questions:
How should 2D knockback behave on a unit in 3D motion?
How should 3D knockback behave on a unit in 2D motion?
What constitutes a unit in 2D or 3D motion for answering the above?
Should it be possible to force a 2D knockback with any guarantees?
What should the behavior be for 3D knockback with horizontal trajectory? The same as a 2D knockback? What trajectory should act as threshold between the two?
public static add2d(unit u, real initial_speed, angle groundAngle)
When applied to a unit with low velocity (configurable threshold), instantiates a Knockback3 with a 2d flag that behaves differently
When any knockback is applied to a flying unit, this codepath is used instead
When applied to a unit with 2d flag, behaves as add does
When applied to a unit with velocity and no 2d flag, "elevates" to 3d and uses horizontal trajectory
When a 3d knockback is applied to a unit with 2d flag, elevates to a 3d knockback, considering current velocity as simply 0 z component
What constitutes a unit in 2D or 3D motion for answering the above?
A unit is in 2d-only motion with the 2d flag.
Should it be possible to force a 2D knockback with any guarantees?
No, out of scope.
What should the behavior be for 3D knockback with horizontal trajectory? The same as a 2D knockback? What trajectory should act as threshold between the two?
Out of scope. Leave 3d knockback with horizontal trajectory unchanged.
Leads to a new question: what special handling should 2d knockback have?
Constant friction value (configurable, both air and ground)
FX only for ground units
setXY instead of setXYZ
Should 2d knockback consider heightmap?
No. Out of scope. Constant friction, no terrain-z consideration initially.
needs scoping/proposal
The text was updated successfully, but these errors were encountered: