wanton shell
Im getting a jittering in the player I control.
Both are a custom Pawn bp class, parent is a capsule with Simulate Physics, moving by Add Impulse. Input sent to Event Run on Server, from there to a Multicast.
As you see my right player, that I control, is jittering but the replicated version in the Left window is smooth.
Actor replication settings:
-Replicate Movement and everything else by default
Capsule settings:
-Replicate Physics to Auotnomous Proxy true
-Component Replicates.
I managed to avoid the jittering with this option... but is first time I find it, Im in 5.4
looks smooth
mortal trench
This is a Pawn, not a Character?
wanton shell
This is a Pawn, not a Character?
Custom Pawn bp class
CA = Child Actor, for a camera
mortal trench
And the Pawn is supposed to be fully Client Authoritive?
wanton shell
And the Pawn is supposed to be fully Client Authoritive?
Im not an expert on replication, so from your question I am understanding you are asking me if Client has the priority of saying where he/her is
is that right?
in my prototype is important a physics behaviour, with characters but kind like any Car Racing game
Characters can push them self, can push trees, which has physics too. this is tested and looks good
mortal trench
The point of my Question is if the Client is 100% Authoritive over the Movement, with the Server not needing to impose some rules.
wanton shell
I want to keep this behaviour, where player can push trees or other players
wanton shell
The point of my Question is if the Client is 100% Authoritive over the Movement,...
what is behind your question, what would be the advantage or limitation of one way or the other
mortal trench
In most cases, Movement is Server Authoritive, and the Client predicts the movement locally and gets corrected if they mispredicted.
That's what the Character + CharacterMovementComponent (CMC) does for you.
When you do Physics stuff, all of this goes out of the Window, cause Physics is almost impossible to predict like this, at least atm. Epic Games has some Physics stuff in their Lego game, but that is not with Client Prediction and only for the blocks that fly away.
So if you don't care about cheating, then the Client can have full authority over the movement, which means you don't need to worry about Prediction and Corrections.
In that case, your Multicast needs to FILTER the IsLocallyControlled Pawn, to ensure it doesn't get the move data again that it already executed.
The only thing you are missing then is SMOOTHING, which you won't get around implementing for any SimulatedProxy Pawns. That's all the Pawns that other people see but not directly own/control.
The Multicast doesn't come in every frame, so you need to smooth between receiving two sets of Data. Usually you smooth from whatever you last received to whatever you just received over a fixed amount of time. That time can vary I guess. It's easier if you use some sort of FixedTick setup, where you always Tick every x ms, and process whatever you received last there, and then do the smoothing between 2 FixedTick frames in your normal tick.
That's complicated to quickly explain, but even without Prediction etc. you gotta implement some form of smoothing.
wanton shell
In most cases, Movement is Server Authoritive, and the Client predicts the movem...
In that case, your Multicast needs to FILTER the IsLocallyControlled Pawn, to ensure it doesn't get the move data again that it already executed.
it looks like this was my jittering
the impulse passed twice
mortal trench
The stuff you send via the Multicast, btw, has to be the RESULT of the Physics Movement of the Pawn.
You should not send the instructions in your case.
You would do that if you do Prediction, so the Server performs the Move and replicates the result back to SimulatedProxies (result being Location, Rotation, and whatever other state, like IsCrouched).
But since the Client is authoritive in your setup, you need to only perform the Move on the Client, and then tell the Server where the Client ended up at and what the new state is. Otherwise you will have stuff desync really quickly
Cause the result of the Physics impulse will almost always be different on Server and Clients.
If two places collide, there is Ping that plays a big role, so the result would be different. You can't make that perfect, but if you only communicate the Result from the Local Player to the Server and then back to the SimulatedProxies, you would at laest make it somewhat sync.
And since you end up sending Transforms to the Server/SimProxies, you gotta smooth that, as already mentioned.
Multiplayer Movement is sadly pretty complex.
wanton shell
The stuff you send via the Multicast, btw, has to be the RESULT of the Physics M...
(I commented the code to be clearer)
Are you saying something like... I should:
A)have the Capsule with Simulate Physics **only **on owning client and in other clients to fake it, setting same transform?
B)to simulate physics on Server...and fake it, setting transforms through multicast in capsules that doesnt have SimulatePhysics
or something else
mortal trench
I mean, I kinda already said everything. I would start repeating myself now.
wanton shell
A) fake it = I mean, the character capsule would be without physics in other clients
if this is what you say, it makes sense, because if I endup with 100 players, it doesnt make sense you to simulate physics of all players. it should be on server
mortal trench
You should not have "ReplicateMovement" ticked I guess, cause that's going to replicate the Transform and will screw things up
Local Client would get older Transforms back when the Server sets them and it replicates via the boolean, which you don't want
wanton shell
Player Input -> Impusle on Capsule should happen only locally, not ServerRPC
so SimulatePhysics only true on Client, not in the others clients for him
mortal trench
But yeah, the other Clients and Server don't need to SimulatePhysics I guess
mortal trench
This is of course only one of many setups, but since you are in Blueprints, you gotta live with what you can do
wanton shell
I got a perfect behaviour with this option, is new from 5.3 I think, instead of default. Practically only a few paragraphs of documentation
but I think I just was lucky
as is only 2 clients
thank you very much, I will prepare a setup following your guidelines
mortal trench
Ah yeah, that could help your smoothing. Idk what it does though.