mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2025-12-10 09:42:29 +00:00
f58ebf1a6e
## About The Pull Request This PR improves our jetpacks in 2 major ways: partially decoupling them and intentional space movement from SSnewphys, and implementing consistent pushoff speeds. Currently jetpacks work by applying constant newtonian force whenever an input key is held down by a client and stabilizing the movement every time they get processed by SSnewphys which is an SS_TICKER subsystem, which means that it attempts to fire prior to everything else and has a wait of a single tick. This would be fine if we could guarantee that there isn't another SS_TICKER subsystem with a higher priority that constantly overtimes... oh right, that'd be the most important subsystem of SSinput. Newtonian impulses, both when starting a drift and when applying continious force rely on SSnewphys to fire the loop, which can end up not happening due to overtime in input (and is a frequent issue on highpop). To circumvent this, newtonian impulses now forcefully fire their drift loop regardless of SSnewphys, thus ensuring that the movement always happens in the tick it was called (If you ask something to move with an ``instant`` flag you'd expect it to move the same tick). Second issue stems from the fact that jetpacks try to move you at your movement speed, except when pushing you off objects they hijack normal movement code that would've ran, resulting in a single tile of slow, janky movement (Or, when moving along walls, making the controls feel "sticky" and worse than what you'd have without a jetpack in the first place). By forcefully applying enough force to make players move at expected speeds, we can solve that issue. Third issue stems from a minor mistake in SSnewphys processing order - process() on jetpacks ran **after** moveloops have fired, so all stabilization only applied next tick. I swapped fire orders around which solves this problem too, although it won't be triggering much as stabilization would now forcefully fire the related loop by itself. https://github.com/user-attachments/assets/1068f68b-2cd1-49b0-bff0-1f79ed0aed5a Also I've refactored wings to be jetpacks since they behave exactly the same, which is a bit cursed if you think about it. ## Why It's Good For The Game Jetpack movement is highly inconsistent in speed/smoothness, janky and gets ruined by even a slightest amount of overtime in subsystems above it - this should solve all of those issues. ## Changelog 🆑 qol: Jetpacks are significantly smoother and nicer to use now - and not affected by lag anymore! code: Cleaned up spacemove/jetpack code a bit and moved some common code to helpers. refactor: Wings are now... jetpacks. They behave exactly the same and this should reduce the amount of copypaste code in spacemove significantly. /🆑
6 lines
343 B
Plaintext
6 lines
343 B
Plaintext
/// Converts w_class into newtons from throwing it, in (0.6 ~ 2.2) range
|
|
#define WEIGHT_TO_NEWTONS(w_class, arguments...) 0.2 NEWTONS + w_class * 0.4 NEWTONS
|
|
|
|
/// Converts movement delay into drift force required to achieve that speed
|
|
#define MOVE_DELAY_TO_DRIFT(move_delay) ((DEFAULT_INERTIA_SPEED / move_delay - 1) / INERTIA_SPEED_COEF + 1)
|