the old limit was made in the php5 days when performance was far worse and it was much more costly to generate chunks that weren't needed. Now it's significantly less and having a higher limit allows terrain to be sent more quickly in new worlds and to fast-moving players.
This limit really ought to go away completely but considering the technical barriers in the way it'll have to stay for now.
Introduction
This PR is a second attempt at improving movement processing to fix#1215 , #2730 and more.
This is significantly less complex than the previous attempt #2646 -- it gets rid of the movement buffering system entirely and instead relies on a simple rate limit counter to restrict on-the-fly movement processing.
Movement is rate limited to a max average of 2 per tick. It allows up to 5 seconds' backlog to accommodate network lag. The rate limit counter is increased by 2 per tick and decreased once for every movement processed. This prevents movement processing being abused for denial of service attacks.
Changes
API changes
This PR, while obviously highly beneficial for most current users, poses some BC-breaking issues because of changes to the internal Player API.
Player->processMovement() (protected) has been removed. This is a BC concern for custom player classes which overrode it and called it as a parent. In addition, child implementations won't be called every tick any more, which could break some custom movement processing systems.
Player->newPosition (protected) has been removed. This internal field may have been accessed by custom movement implementations.
Player->isTeleporting (protected) has been removed. BC concern is same as previous point.
Player->getNextPosition() (public) has been @deprecated.
Added the following protected Player class members:
int $moveRateLimit
?Vector3 $forceMoveSync
handleMovement()
processMostRecentMovements()
revertMovement()
Behavioural changes
Player movement is now subject to less rubberbanding and has more reliable behaviour.
this reduces the temptation to use it in high-level code, as well as making syncNetworkData() more useful (now it can export to many data collections, which means we can start to think about having a property cache per network session, which is more flexible)
