How to implement Chaos Vehicle movement replication in Lyra?

Development Programming & Scripting
1

I’m having trouble Chaos Vehicle movement replication, when I add and possess a vehicle is very laggy/jerky on the client (server works OK and replicates to clients OK). The client eventually gets kicked off with

Closing connection. Can’t send function ‘ServerUpdateState’ on ‘ChaosWheeledVehicleMovementComponent SportsCar_Pawn_C_0.VehicleMovementComp’: Reliable buffer overflow. FieldCache->FieldNetIndex: 4 Max 5. Ch MaxPacket: 1024.

I tried changing the plugin
Engine/Plugins/Experimental/ChaosVehiclesPlugin/Source/ChaosVehicles/Public/ChaosVehicleMovementComponent.h

UFUNCTION(reliable, server, WithValidation)
void ServerUpdateState(float InSteeringInput, float InThrottleInput, float InBrakeInput, float InHandbrakeInput, int32 InCurrentGear, float InRollInput, float InPitchInput, float InYawInput);

to unreliable and throttling the RPC calls (only sending to the server when the input changes), that fixed the RPC error but connected client replication still didn’t work.

Odd thing is if I combine the Advanced Vehicle and ThridPerson project and use the client to possess the vehicle replication works fine (maybe due to either less RPC traffic or something due to using the default subsystem instead of EOS).

I understand this plugin is still in Experimental, any help would be much appreciated.

1 Like
2

Did you ever get this to work. How did you possess the vehicle in Lyra?

3

that overflow is update rate vs the reliable channel. ServerUpdateState is marked reliable, so every vehicle tick queues into the reliable buffer, and on a laggy client the buffer never drains, 1024 packets later the connection dies. reliable is wrong for state updates by design (a dropped state packet is obsolete anyway), but you cant change the UFUNCTION flag without engine code.

workarounds that actually help: lower the send rate (check NetUpdateFrequency on the pawn, lyra pawns often run high, bring the vehicle toward 30-60), and fix the stall first, the overflow is usually a symptom of the client not acking because it hitches on spawn or possess, not the cause. also possess on the server through the game mode flow, a client-side possess of a server-simulated vehicle doubles the update path.

why state traffic has to be treated as losable is covered in the fundamentals here: Networked Physics - Fundamentals