The title is fairly self-explanatory. Even for a seasoned programmer, it’s incredibly hard to make sense of CharacterMovementComponent at times. The code is extremely complex and jumps all over the place, but you can never really follow the code and quickly lose track of what’s happening.
I personally would love to see a deep and detailed explanation and anatomy of the CMC system. It’s a very well made system since it’s practically flawless in operation, but it would be extremely helpful to those wanting to make their own Movement Components (particularly for Multiplayer Prediction / Reconciliation) if we had detailed notes or comments throughout the code, or a specific documentation page for it.
…but if this does not qualify to you as the “deep and detailed explanation and anatomy of the CMC system” you’d hope for, let me know and I will enter an official request for extended documentation. -Thanks for the feedback.
Thanks for the link - that did actually help me out a lot! At the same time though I’d still like a little more detail into the inner workings if possible. My main questions are how the TimeStamps are generated and how the Server / Client remain in Sync with one another even at varying framerates - the ‘GetNetworkSafeRandomAngleDegress()’ function seems to generate the Timestamp, but looking at it, I don’t really know how it works… it doesn’t appear to be a timestamp at all, more a unique identifier for a packet or something?
I also don’t fully understand the use of the PredictionData_Server / Client variables and classes and how they’re used. NetworkPredictionInterface seems to be the way to use those objects, but there’s not much detail on them.
The final part I don’t really follow is the ‘ConsumeInputVector()’ function, which seems to be very oddly named. I can’t work out exactly what it does…
ConsumeInputVector just takes the input vector for the current frame (which is derived from, for example, the current position of a controller analog stick), makes a copy of it (so that we can have access to the vector from a previous frame), and returns it while setting it to zero at the same time.
The naming just represents that rather than passively getting it, we are consuming it (reset to zero), so subsequent calls to Consume/Get on the current frame will return zero. This is necessary because the input vector is created additively (potentially from multiple sources), so it needs resetting to zero at the end of each frame to prevent additions building up. There are some comments relating to this in PawnMovementComponent.h.
That was the easy one. Can’t help you with the other questions I’m afraid!
There is currently a Quality Assurance report filed for this documentation: [UEDOCQA-745] I have added your feedback as information to be specifically addressed. When the documentation and this report have been updated, we’ll update this post as well. In the meantime, if there is any other information you’d like to see on this topic, post it here and I’ll request it be added to the documentation also.