Titanfall VR Weird timing between Client and Server

So im making a TitanfallVR game and currently I am working on some multiplayer stuff and running into some weird disparity between client and server.

So to give some context, for 1 particular mech the weapon can be charged up and upon firing will discharge before being able to charge again. Now the mech and its weapon are separate actors, and the weapon is a child actor of the mech. As shown in the images attached, the logic flow is that the player holds the trigger which sends a signal to the mech to start charging the weapon, the weapon is checking its charge every frame and upon reaching 100 it will shoot and start discharging. Now the issue is in the charging and discharging behavior.

For some reason, even though both charge and discharge are ultimately executed by the server only, depending on how I setup my nodes the client and server’s charge and discharge times would deviate. In my mind it makes sense to adjust them based on the server’s delta time so its consistent between client and server, but it doesn’t seem to behave in the expected way. Can anyone explain what is going on and why?

If anyone has some insight, I’d greatly appreciate if you shared :smiley:

After some research and investigating I think the issue is related to tick rates being different on client vs server, though I thought calling Get World Delta Seconds from the server event would ensure its the server’s delta seconds but I guess that isn’t the case.

Anyhow I ended up changing methods for handling the charging and discharging and that ended up fixing things

Client frame rate == tick (hz). It varies frame to frame and machine to machine. Server tickrate is typically static (default 30Hz). You can change this via ini.

If you want to sync timed events you have to account for instigator ping (player state -> ping). If your games network clock is in sync (client and server) you can send the gametime in the rpc. Have the server account for ping (receive - send = n) and use a timer (total time - n).

This will have the timer on the client and the server executing at the same time (very small margin of error).

Is it possible and beneficial to constantly be checking incoming ping to try and sync up timed events?

Also what’s the correct way to time events without having to worry about frame rate? Are timelines the right way to do it? cuz that’s what I ended up using.

It’s always beneficial to sync timed events in multiplayer. The key here is to not simply subtract 50% ping. Pings have jitter, packets get lost and have to be resent. And in some cases packets aren’t sent until the start of the next tick/frame. Use “network time” at the point of input.

Set Timer by Event or Set timer by Function Name would be a better approach.…ent/index.html…ame/index.html

@dkzhu Here’s an article on network time in ue4.

O wow thank you so much for those resources! The article was very insightful and practical as well!

I’m not quite sure these meets the needs of my design. The charging and discharging only happen when the player initiates them(with a button press or release) and don’t run on a repeating timer basis, also it can switch from charging to discharging and then back to charging if the player presses the button, releases it, then presses it again.

The only thing that needs to be synced is that the charge accumulates and dissipates with the same speed on both server and client. So I currently have a 2 second timeline that outputs an alpha(from 0 to 1) that I used to lerp my charge from 0 to max. I then just reverse it for the discharge. And tbh it has worked quite well for me so far dunno if there are scenarios where the timeline breaks down though.

If I am misunderstanding anything please elaborate.

You don’t have to loop the timer.

  • Pressed -> timer -> fire event to server.
  • Released -> Clear timer -> fire event to server to clear handle.

ooooo i get it now, ill have to give it a try.

Is this method more reliable than using a timeline? Are there other advantages over timelines?

Easily control time and less memory usage are the top two.