Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Pause MovePart when Mobile is paused. #17189
As mentioned in #17043, I'm on the fence about whether this is the best approach.
If we restore pausing stopping movement immediately we will be forced to introduce a third state for
IMO "reject player input and move to a safe/valid location before stopping" is a completely reasonable default behaviour for pausing, and cases like the Hijacker that really do want to freeze the unit immediately have the option of enabling a speed modifier.
What do we gain by going this route instead?
This fixes the regression part and restores the thief to its current (stable) behaviour. The other use cases are not part of stable mods yet, so do not require a quick fix.
I agree that always going to a valid location instead of stopping on the spot is the more sane behaviour, but there are several snags in the current movement logic that prevent that from working properly (especially with regards to turning). I have been busy for a while now with a rigorous rework of the movement logic that will (hopefully) address those issues in a more robust way, but that is way out of scope for next release. In the mean time, I am hesitant to add more workarounds that may make that job more difficult.
I am also not sure if a proper implementation of the hijacker behaviour would absolutely need freezing on the spot either and would be more happy if there where no exceptions to the rule at all (so speed modifiers would also only apply after the current MovePart has ended).