SomeWritesReserved
commented
1 year ago Actually the solution of updating a single entity through the whole suite of system might be as easy as putting the IServerCommandProcessorSystem interface on things like the physics system, so the player can advance in the world immediately after the impulse was applied by the command processing system? Looking back at the history, the failed Quake style movement was done in Aug 2020 (12c249e98199405c30577deb2602653d3af0c5e0) which seems to have predicated the fix for "system-based commanding" in Sept 2020 (ca30472e0651ed5da04b1036f3c2b9dd2cafd259). So I think the answer here is that its already solved and this is not an issue. Also see bug #4 that also covers this.
tl;dr: I forgot I thought about all of this already.
Currently, the server side logic for updating a commanded entity is flawed if a command only applies "forces" or "impulses" to the commanded entity, since these impulses won't do anything until physics are run on the entity. Imagine a scenario when a client command is delayed in transit and the server receives two commands on the same tick: in this case the commanding entity could have an impulse forward then an impulse backward which should make the entity nudge forward then go backward, but since both forces are applied and then physics are run, the forces cancel out and the entity doesn't move at all. This is obviously wrong since the entity could have triggered something by moving and it prevents precise player control (and skill based movement).
This limitation forces a game to change the position of a commanded entity directly. This isn't always desirable because interesting player movement is usually physics based (ala Quake).
The most obvious answer here is to run a "partial" server update where we run through all systems but only for the commanded entity (so it can move about the world and trigger things). I'm not sure how such a mechanism would work.
This was explored on branch archive/command_processing_quakestyle and culminated in the failed commit 12c249e98199405c30577deb2602653d3af0c5e0 which has a detailed commit message describing the failure. This commit also suggests another solution which it to immediately do a full update of the whole server but that is impossible since it would also advance physics for all other entities as if another frame happened which is not true.
For more background, ca30472e0651ed5da04b1036f3c2b9dd2cafd259 changes how commanded entity updating was done. Previously the command was applied directly to an entity but that logic was moved to a new server-side interface (and client-side counterpart for prediction) that is also a system.