Replicating new movement types

[Bleeder91[NL]]

So I added UT4 like movement such as Sliding to my playerpawns, and I'm having this issue where high ping players (>150) will have stuttering/rubberbanding when they try to slide. I've tried a couple of different approaches that I know of but they all end up the same way so I'm a bit clueless how to fix this. Any ideas? My current setup is this:

Code: Select all

var float SlideTick;
var bool bCanSlide;
var bool bWasSliding;
var vector SlideVel;
var float SlideRoll;

Replication
{
      Reliable if(Role (1.0/120))
      {      RepClientMovement(Level.TimeSeconds-LastRepTick,bHeldJump,bCanSprint);
            LastRepTick=Level.TimeSeconds;
      }
}

final function RepClientMovement(float dT, bool bRepJump, bool bRepSprint)
{
      local vector HL,HN,Start;
      
      // Sliding.
      bCanSlide=bIsCrouching&&(Physics==PHYS_Walking);
      if(bCanSlide)
      {      if(!bWasSliding) SlideVel=Velocity;
            Velocity+=20*Normal(SlideVel)*FMin(VSize(SlideVel),GroundSpeed)*FMin(dT,SlideTick)*(SlideTick**2);
            SlideTick=FClamp(SlideTick-dT/0.8,0,1);
      }      else
      {      SlideTick=FClamp(SlideTick+dT,0,1);
            SlideVel=vect(0,0,0);
      }      bWasSliding=bCanSlide;
}

[Masterkent]

Do you store the corresponding PlayerPawn movements into something like SavedMoves?

Probably, you have to properly implement autonomous movement in order to make such non-standard moves working well in online game. From time to time (usually several times per second), the server sends some synchronization data to the client by means of calling ClientAdjustPosition which basically tells the client that at the given timestamp TimeStamp the PlayerPawn's state, Physics, Location, Velocity, and Base must match the transferred values. The client changes PlayerPawn's state and properties according to the received data. However, the given data corresponds to a situation that took place in the past. In order to determine PlayerPawn's state and properties that would be actual at the current moment, the client applies all recorded movements of the player (stored in SavedMoves) since the given Timestamp (which is copied to CurrentTimeStamp by ClientAdjustPosition) - see function ClientUpdatePosition.

This mechanism of synchronization is aimed to offer two important things: firstly, as a player, you see your own movements immediately without waiting response from the server; secondly, if the client erroneously assumes that the player should be in a certain state or at a certain location, etc, while the server (which has the exclusive rights to determine what actually must happen in the game world) thinks that player's state/location/etc. should be different, the client-side PlayerPawn's state/properties will be quickly adjusted to match the situation on the server as close as possible.

If you don't reproduce your special player movements during such synchronizations, then the whole sequence of player movements may be reproduced in a wrong way (probably, as if there were no any special movements), and after completion of a synch operation player may have erroneous location and velocity which then will be corrected by a subsequent synchronization. Since client-side correction of player's location may imply that the player may be immediately moved far from the erroneous location, it may be very noticeable.

[Bleeder91[NL]]

Honestly I have no clue how to go about SavedMove. PlayerTick is called right before PlayerMove in state PlayerWalking so technically it should all go through, no?

[Masterkent]

In case if ReplicateMove already saves all info that is necessary to reproduce player movement between two adjacent ticks, the only thing you need to do is to make sure that ClientAdjustPosition correctly restores the initial player properties before applying accumulated moves.

For example, if you have two possible conditions "player is currently sliding" (bIsSliding == true) and "player is currently not sliding" (bIsSliding == false) (I don't play UT4, so I don't know how that thing works there), ClientAdjustPosition may need to change bIsSliding from true to false, because at the moment corresponding to the given TimeStamp the player might not start sliding yet. Similarly, it may need to change bIsSliding from false to true, because at the given timestamp the player was sliding.

Then you have two alternatives:

1) You can send the server-side value of bIsSliding from server to client via a reliable remote procedure call (RPC) right before calling ClientAdjustPosition (requires overriding ServerMove), assign it to a temporary variable (e.g. bUpdIsSliding) in that RPC, and then update client-side bIsSliding in overridden ClientAdjustPosition based on the value stored in the temporary variable bUpdIsSliding.

[Note 1: reliable replicated function calls are executed on the remote machine in the same order they were initiated on the host machine; you could not make bUpdIsSliding a replicated var and rely on its replicated value, because updating the value of a replicated variable and execution of an RPC may take place in any order]

[Note2: the temporary variable like bUpdIsSliding would be needed because two RPCs may be executed during different ticks and you probably wouldn't want a premature update of the variable bIsSliding that affects player's behavior immediately]

2) You can save pairs of client-side values {TimeStamp, bIsSliding} to some dynamic array in your PlayerMove function and then update player's bIsSliding in overridden ClientAdjustPosition based on the value stored in the array item whose saved TimeStamp matches the value of parameter TimeStamp of function ClientAdjustPosition.

The first approach implies better synchronization with the server, but it needs sending more data via network and overriding ServerMove may be inconvenient.


If your special player movement may cause observable changes of properties which cannot be properly reproduced during synchronizations (e.g. changes of EyeHeight), you may need to prevent such changes when applying saved moves. For example, I had to explicitly disable some effects of real crouching (related to updating EyeHeight and PrePivot) when bUpdatePosition is equal to true.