You can reproduce this bug with default “Crouch” and “Un crouch” functions, if you setup CharacterMovement->Crouched Half Height to 34. After change your Z position in game (e.g. walk up stairs) and Crouch/Un crouch - mesh will be placed in wrong place until next movement/rotation update. e.g. until you walk forward.
Any solution please?
Thank you.
Please can you show where need to change code (lines etc…)? Thank you.
Here we have test project ue4 v4.13.2 Dropbox - MyProject4_v4_13_2.rar - Simplify your life
Run project for 2 players.
player 1 click host, after load map, click C for Crouch, capsule size changed
player 2 click Join and look to Player 2
Profit: With Rep_Notify capsule size and SetRelativeLocation not work.
Hello, sir! Just like XelaSpain, I would like to know if you could provide more viable information about “rerecoding of relative location” through code. Please, give us more details how did you manage to set relative location which replicates successfully. I tried my best in custom Character Class, but have not succeed. Thank you.
P.S. Your others solutions works just fine, but only in Editor. Mesh looks very laggy in packaged project with both solutions.
Was running into similar issues trying to set up a prone animation for my character. I ended up making a copy of prone animation and editing it in persona to change Z height with an additive layer track. This workaround is working for me in multiplayer environment.
To manipulate collision capsule and return it to normal in a way that worked for multiplayer I had to do it in this order:
In Character Blueprint make RPC “Run On Server” event. In that event I “SetRelativeLocation” on Capsule Component by getting it’s world location then adding or subtracting from vector (for this case + or - Z) Right after that I call Multicast and in there “SetCapsuleRadius” and “SetCapsuleHalfHeight”. When leaving prone I can return settings to normal using same flow. I’m very new to all this and perhaps this isn’t proper - but after much hair pulling this method does appear same across all clients in a dedicated server and in listen server. Posting in case this is helpful for anyone else running into similar problems.
Disabling network smoothing on CharacterMovement solves this problem, but…
Can we expect this to be fixed, please? We would just need to notify CharacterMovement of new value whenever SetRelativeLocation is called.
4.20 still dont work. Any news?
4.21 not worked 
Late to party, but since problem still exist in 4.24 I bumped into this as well. Luckily I found a solution that doesn’t involve a lot of changes.
It’s actually one line of code
Unfortunately for some, this only works on C++ as there is no equivalent function in blueprints and you need a C++ Character class working.
In whatever function changes relative location you just do this:
Skeleton->SetRelativeLocation(FVector{ 0,0,Z });
////This is what fixes it. Just update with same value
BaseTranslationOffset = FVector{ 0,0,Z };
Update:
Doing : Skeleton->SetRelativeLocation(FVector{ 0,0,Z }); will cause stuttering from other player’s perspective if emulating lag.
If you don’t expect many quick changes to value you could do:
if (IsLocallyControlled())
{
Skeleton->SetRelativeLocation(FVector{ 0,0,x.Z });
}
else
{
BaseTranslationOffset = FVector{ 0,0,x.Z };
}
But if you have that value change quickly if will also stutter when value is changed. So far only way I’ve found to mitigate this is:
if (IsLocallyControlled())
{
Skeleton->SetRelativeLocation(FVector{ 0,0,x.Z });
}
else
{
BaseTranslationOffset = FMath::VInterpTo(BaseTranslationOffset, DesiredValue ,deltaT, DesiredInterpSpeed);
}
Still not fixed in 4.26 :c
Easy guys use, tick function and place there SetRelativeLocation, if is locally controlled do not do it, but if it is not locally controlled in tick function place it.
Should work: Within bp, call Cache Initial Mesh Offset whenever you change character mesh loc/rot. I believe GetBaseTranslationOffset is value that gets used when smoothing
bumped into this thread experiencing problems with adjusting mesh relative location on tick when network smoothing is applied, above node shown by TheRealOzzy1 (Cache Initial Mesh Offset) does fix this, however causes issues with smoothing - workaround suggested by shark0151 to interp this seems to alleviate problem but network smoothing is still worse than normal if cache is repeatedly set (i.e. on tick)
I found better alternative to this in my case was to transform root bone of mesh in animation blueprint. Instead of setting mesh relative location, set a vector for transform offset, and use this in your animation blueprint to simply offset whole skeleton. No more issues with network smoothing, etc.
This solution works for me, if you tried to modify mesh with absolute rotation independent of capsule, change it to relative as it normally is and modify root bone, mesh will still work with capsule as usual and you will be able to change rotation of your character (visually) as you like 
It Works Bro, Thanks a lot
Thanks a lot! Works like a charm! 
You should place both the Cache Initial Mesh Offset and the Set Relative Location nodes in sequence and set the same value in both. If you only place the Cache Initial Mesh Offset by itself, you’ll get the opposite effect to what you’re getting only with the Set Relative Location node. It’ll work on all the other clients but not on your own. 
EDIT: Forgot to mention, add -90 into the Z-axis rotation of the Cache Initial Mesh Offset otherwise the player will rotate 90° on other clients.
This solved my problem. Thanks a lot.
