Connection.RemoteFrame is way behind Command.ServerFrame in ExecuteCommand

in BOLT Engine
Hi,
I am using Bolt for a server authoritative movement/shooting in my game. Recently I decided to use the client's frame for better lag compensation; However in the ExecutecCommand method, when I compared the value of RemoteFrame property of the client which generates the commands with the value of ServerFrame property of the received command I can see that they are not in sync and most of the times (especially when the client or server is the Unity editor) the RemoteFrame is way way behind the ServerFrame (I've seen differences from 30 to 200 frames).
I was under the impression that that these two values should be same or very close to each other. Could you please explain to me what I am missing here?
Look forward to hearing from you.
Regards,
Aydin
I am using Bolt for a server authoritative movement/shooting in my game. Recently I decided to use the client's frame for better lag compensation; However in the ExecutecCommand method, when I compared the value of RemoteFrame property of the client which generates the commands with the value of ServerFrame property of the received command I can see that they are not in sync and most of the times (especially when the client or server is the Unity editor) the RemoteFrame is way way behind the ServerFrame (I've seen differences from 30 to 200 frames).
I was under the impression that that these two values should be same or very close to each other. Could you please explain to me what I am missing here?
Look forward to hearing from you.
Regards,
Aydin
0
Comments
The current frame in which the simulation is running on each peer is independent.
Every time an update package is received from a remote peer, the frame number is updated on the local reference for that remote connection. It's used to simulate forward all entities that have that connection as the origin.
In summary, the simulation frame is local and independent.
When a command is enqueued by the controller on the local command queue, it's marked with the estimated frame from the server, and don't take into account anything from the local simulation frame.
And when this command arrives on the server, you just need to know when the client has created this command based on the server frame, so it can check in the past for a particular tracked hitboxes and perform the raycast check, for example.
If you are implementing a Lag Compensated Raycast check, just use the already implemented system that exists in Bolt: https://doc.photonengine.com/en-us/bolt/current/community-wiki/bolt-essentials/lag-compensation
By using Bolt Hitboxes and the mentioned methods, you can easily check for Raycast/Spherecast hits that take into consideration the lag between the client and server.
--
Ramon Melo
Photon Bolt Team
As for using Bolt's HitBoxes for the lag compensation, it seems they are not a good fit for the kind of gameplay I have in my game - at least with the features the current documentation presents.
Thanks,
Aydin
Can you elaborate on this?
--
Ramon Melo
Photon Bolt Team
Yes, that should be easy to do, a circular buffer with X past positions/rotations of a certain entity.
You just need to record this at the "SimulateOwner" for example.
--
Ramon Melo
Photon Bolt Team