drift_handler 
Component that handles drifting Manages a movement loop that actually does the legwork of moving someone Alongside dealing with the post movement input blocking required to make things look nice
Vars | |
| delayed | Have we been delayed? IE: active, but not working right this second? |
|---|---|
| drift_force | How much force is behind this drift. |
| ignore_next_glide | Should we ignore the next glide rate input we get? This is to some extent a hack around the order of operations Around COMSIG_MOVELOOP_POSTPROCESS. I'm sorry lad |
Procs | |
| New | Accepts three args. The direction to drift in, if the drift is instant or not, and if it's not instant, the delay on the start |
| handle_glidesize_update | We're going to take the passed in glide size and use it to manually delay our loop for that period to allow the other movement to complete |
| newtonian_impulse | An impulse is being applied to this existing drift, react accordingly |
| stopped_pulling | If we're pulling something and stop, we want it to continue at our rate and such |
Var Details
delayed
Have we been delayed? IE: active, but not working right this second?
drift_force
How much force is behind this drift.
ignore_next_glide
Should we ignore the next glide rate input we get? This is to some extent a hack around the order of operations Around COMSIG_MOVELOOP_POSTPROCESS. I'm sorry lad
Proc Details
New
Accepts three args. The direction to drift in, if the drift is instant or not, and if it's not instant, the delay on the start
handle_glidesize_update
We're going to take the passed in glide size and use it to manually delay our loop for that period to allow the other movement to complete
newtonian_impulse
An impulse is being applied to this existing drift, react accordingly
- inertia_angle - angle of the new impulse
- start_delay - if the new impulse has a delay before it starts, this is it
- additional_force - how much force the new impulse has force is not added onto additional force, it will either override it entirely (if larger or a different direction) or be ignored (if smaller and same direction) controlled_cap - the maximum amount of force this impulse can apply, regardless of input force_loop - should we force the loop to fire immediately to react to this change, or wait for the next visual tick? Generally, if the new impulse has a start delay, you should wait, otherwise it'll look really jank
Return FALSE if the loop becomes invalid and should be replaced Return TRUE if the loop is still valid and should be kept
stopped_pulling
If we're pulling something and stop, we want it to continue at our rate and such