It turns out that CommandHistory::replays returns a reverse-order history of commands, that is, the latest command is iterated first in the resulting Vec. This is not a problem in bevy-demo since the order of commands doesn't affect the final result in its logic. That's not always the case. For example, if the commands include turning the character and moving toward where it faces, the outcome of replaying will be different if one is first moving forward then turning, or first turning then moving forward, and will eventually cause discontinuous movement when server data arrives. The way CommandHistory is used can mislead people trying to learn how to use CommandHistory from the demo and implementing some logic that is a little bit more complicated. I suspect this to be a bug, by how it is used in the demo and what its name implies. If it is, however, intended, I think we'd better document this fact and also comment it in the demo.
It turns out that
CommandHistory::replays
returns a reverse-order history of commands, that is, the latest command is iterated first in the resultingVec
. This is not a problem in bevy-demo since the order of commands doesn't affect the final result in its logic. That's not always the case. For example, if the commands include turning the character and moving toward where it faces, the outcome of replaying will be different if one is first moving forward then turning, or first turning then moving forward, and will eventually cause discontinuous movement when server data arrives. The wayCommandHistory
is used can mislead people trying to learn how to useCommandHistory
from the demo and implementing some logic that is a little bit more complicated. I suspect this to be a bug, by how it is used in the demo and what its name implies. If it is, however, intended, I think we'd better document this fact and also comment it in the demo.