I’ll keep it as simple as possible. I’m working on a neat project called combat vector and it’s coming along quite nicely. Heres some old footage from the game:
My only issue right now is getting the positions of the jet to replicate to all clients. My current system sends out the current CFrame over a remote event every 2 frames then has a small amount of prediction in order to streamline it but it just stutters like crazy still when there is more than one other player. What’s the best way to achieve this system?
Current system:
RS.RenderStepped:Connect(function()
for i,s in pairs(KnownShips) do
if s.Ship and s.Ship.Parent then
if s.Updated == 0 then --Once a new position is received from the server, this gets changed to 0 and FCF get updated with the real ship pos
print("Updated")
KnownShips[i].Updated = 0.05 -- Used for lerp alpha
else
KnownShips[i].FCF = KnownShips[i].FCF * s.Offset -- FCF is Fake CFrame
KnownShips[i].Updated = KnownShips[i].Updated + 0.05
s.Ship:SetPrimaryPartCFrame(s.Ship.PrimaryPart.CFrame:Lerp(KnownShips[i].FCF,KnownShips[i].Updated))
print((s.Ship.PrimaryPart.CFrame.p - lpt.p).Magnitude) -- Used for debugging
lpt = s.Ship.PrimaryPart.CFrame
end
end
end
end)
You might want to increase the amount of frames in between each update. Or you can scale it relatively based on the player’s local FPS. A player running 60FPS won’t notice the difference between 2 frames and 5 frames (0.03 seconds, minimum wait() time, and 0.08 seconds). However, a player running 20 FPS definitely might (0.1 seconds, 0.25 seconds)
To highlight the issue, 30 FPS is a solid replication interval. The reason it’s not so smooth is because of latency variation between clients and the server causing major inconsistencies. What’s the best way to remove the latency variable or mitigate it?
Also, I’d like to add that the replication interval is 30 FPS, but the actual speed at which the planes visually change is 60 FPS, this is due to the partial “prediction”. Removing this prediction makes the plane way more choppy as the latency variation becomes more impactful.
While most of these answers point in the “right” direction by increasing replication rate, they gloss over the actual code that you have written in order to replicate positions. Instead of having the server work harder, we can instead be smarter.
In your code, you use Lerp with an Alpha in order to interpolate between positions. Since you are sending the information every 2 frames, then in the perfect scenario Alpha will simply be 0.1 before it returns back to 0.05. This means that your linear interpolation will never fully reach the end position vector (we are not too sure about this, as we don’t know how your “prediction” alters the final position). This would cause the ship to always be “lagged” behind the real ship position. This shouldn’t be too noticeable. The real killer is the variable latency, as this variable latency will cause some frames to have a higher final alpha. This mean alpha will always be larger than your 0.1 desired final alpha.
Some researchers have suggested that network latency may be Gaussian distributed in some cases… (doubtful, its really more log-normal). If you want to assume this, you can employ a standard observer in order to estimate the position with gains calculated based on the latency. I would use then use Kalman filter in order to best estimate the latency.