All that jitter is caused by client fighting server correction. The server is the authority. Whatever it says is true… is true. So as HOST your inputted actions are the authority. But as a connected client they are not.
Skeletal mesh movement (animation) is state driven. You do something in the character class, it sets a state. The animation class uses those states to determine mesh movement.
Based on your post and the vid you’re not setting states properly and you’re not sending the server RPC’s to tell it what your doing.
For example Sprinting changes the cmc Max Walk Speed variable. Because CMC utilizes client-side prediction we have to apply the new speed locally, then rpc the server to sprint. The server checks if it can sprint. If so it applies the new speed to Max Walk Speed.
Here’s a simplified, but functional Sprint setup for multiplayer.
The Macro’s (Can Sprint & Is sprinting) are custom made. They are simply branch checks that determine a success/fail, true/false return.
Can I sprint… is the character in the air/falling? Is it firing a weapon? Is it doing anything else that you’d want to block sprinting from occurring?
Is Sprinting… Main aspect is bIsSprinting == True.
Your flashlight should be a replicated actor class that’s spawned and attached by the server.
e.g. You get the flashlight by having the server copy of your character (Authoritative Proxy) spawn the class, then attach it.
Turning it on/off has to go through the server as well.
Input to turn on: RPC Server → Server activates the light component.
Input to turn off: RPC Server → Server deactivates the light component.
The flashlight class should be a replicated actor that is NOT a default component of the character class.