Work on pre0 for OctoberProject is progressing well but I got snagged wanting to sort out how viscosity impacts the world before looking at some balancing. After a few attempts at changing how this is managed in order to make the impact more what I would expect (0.5 viscosity should make your top speed roughly 0.5 or what it is with none), I keep coming back to the same fundamental problem with how the motion design works: The client applies it continuously while the server applies it discretely and the underlying logic needs to do something reasonable in both cases, with a matching (or almost identical) result.

This problem has been with the project forever and was further magnified by the change to the vector-based movement design. Part of this is related to how it now applies motion but part was also due to how much additional complexity it removed.

This got me wondering, though: Why can't the server apply this logic using the same continuous approach as the client, only rolling up the remainder in the tick as a discrete calculation (which should be the same as anything the client was going to do, anyway)? Fundamentally, the server is seeing the same mutations as the client, it is just changing how it applies the end-of-tick roll-up of whatever changed. It could do that roll-up operation after each of these changes, as the client does, and then just apply the final end-of-tick logic it currently has on any remainder.

While this is less efficient, it might just resolve all of these inconsistencies (or at least as many as the server could know about - the other cases shouldn't even be visible) and simplify the system (since the hacks to make this appear to work are not trivial).

I will have to think a bit more about this but I think that the idea might be worth prototyping.
Jeff.