This work on the new movement design for OctoberProject is slow-going. This is largely because of going back-and-forth on some ideas, but also just because that code is everywhere (movement is pretty fundamental) and rather ugly/finicky (since movement and collision has a lot of things to check - partly because of the lava flows of previous designs still partially in play).

The change has essentially 3 ideas which aren't worth untangling (changing them together is about as much work as each individual change so doing them at once is ~1/3 as much actual work):

1) Avoid sub-tick action scheduling: Currently, movements are packaged by the client to the inter-frame delay on that client. This causes too much chatter on the network, requires that the server schedule these into (and over) ticks, and results in some very bizarre rounding errors. These problems would only compound if a client were running at a higher frame rate, which is just wrong. The change to make all actions take an entire tick will simplify this but may add some odd delays, etc, which I am unsure will be acceptable but need to mostly implement in order to try.
2) Movement/standing actions should allow concurrent actions to be scheduled for things like jumping/breaking/placing/crafting. This changes a big restriction which has been in place since the beginning, and is made possible by (1), but also kind of required by (1): If the movement takes the entire tick, things like jumping either need to be part of the move or also take a full tick, which just seems wrong.
3) Change the actual movement to be client-owned and only validated by the server. This is the most important part of this change but isn't really worth doing on its own, since it would just need to be redone in order to solve (1) and (2). This requires making sure that the way motion is described is sufficiently flexible for all the needs within the OctoberPeaks scope (if not also OctoberSkies - not likely) but also requires that validation can be reasonably performed. Also, there needs to be some way of describing external forces within the client-owned design in a way which doesn't cause excessive rubber-banding due to validation failures (think weapon knock-back or explosions, etc).

As a result of all of this, this is taking a long time and is tedious through all the second-guessing.

Still, if I can make this design encompass everything needed and make the validation flexible enough, it will be far more elegant than what is there now.

Luckily, this is the only big change planned for this release, aside from some small bug fixes. Still, that doesn't mean that this will be done soon.

Back to the grind,
Jeff.