Open Cokemonkey11 opened 3 years ago
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:
I propose adding a new:
public static add2d(unit u, real initial_speed, angle groundAngle)
2d
flag that behaves differently2d
flag, behaves as add
does2d
flag, "elevates" to 3d and uses horizontal trajectory2d
flag, elevates to a 3d knockback, considering current velocity as simply 0 z componentWhat 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?
Should
2d
knockback consider heightmap?
No. Out of scope. Constant friction, no terrain-z consideration initially.
needs scoping/proposal