The final release in the "tech demo" series for the OctoberPlains work under OctoberProject is nearly done and has been for a few days. The problem is that there are a few de-sync issues which are really making me uncomfortable.

This was a big change to the underlying entity movement mechanics in order to make things like swimming less insane while also removing a bunch of irritating special-cases from several other parts of the code, all while eliminating a sort of "soft cheating" technique which was otherwise possible under the old movement design. I refer to this change as "vector-base movement" since it replaces the previous approach of describing explicit movements in the world, where the client was responsible for all movement, with a general velocity vector which is changed by movement actions but is applied by the server or client (speculatively) to adjust the entity's actual location in the world.

For the most part, this works very well (and being able to remove falling logic from several other entity actions implied that this was the right path). However, since the server is now responsible for moving the entity (not just checking that client-originating movements are within limits), some odd de-sync can happen.

For example, quasi-dependent actions can now have problems when they arrive at the wrong time on the server. Consider the case of jumping out of a hole: If the horizontal movement arrives too soon after the jump, the entity may not have risen high enough to make it over the adjacent block. A similar problem happens when jumping up into water (if some block below displaces it): It is possible that the swim will come too soon after the jump so that the entity isn't yet in the water or is still climbing too rapidly to swim again.

My current approach to these problems is mostly to soften to them such that the server has more options to use: For example, the client should send the move even if there is a barrier since the server might receive it at the intended time, when it isn't in the way. While this works and isn't exactly wrong (since the server is the source of truth and the client shouldn't be too clever about this), it does _seem_ wrong. I am trying to figure out a real-world analogue to use to validate this approach and one could argue that this is fine since we don't "know" that we will move when we try to, we just try to and let the universe sort out what actually happens.

So, I think that this is the right approach, at least for now, but I do keep wondering if this will need to be re-thought, again, in the future.

As in an exam, as in real life: "State your assumptions and proceed."

Jeff.