The objective
Hey there! I’m working on a revamp to brickbattle tools, currently focusing on the Superball. One thing I noticed with the usual tools is that since the client firing the Superball is the NetworkOwner of their own projectiles, other clients see the projectile being interpolated, which makes the projectile look further back than it should be. In hopes of making my Superball tool look more accurate while preserving some robustness in higher-ping environments, I tried to bypass this interpolation and trade it for extrapolation instead:
-When our client detects another client’s superball, they make the projectile invisible on their device and create a fake copy of it, to run physics on their end.
-The real projectile contains a CFrame value and a Vector3 value, respectively for projectile CFrame and Velocity. The firing player updates these at a regular pace by firing remote events to the server.
-If our client sees the CFrame/Vector3 values updated, we’ll teleport the fake superball to the corrected position. Otherwise, we let physics handle its (uninterpolated) movement.
Here’s what the result looks like. The first superball shot in the video doesn’t use any hacks, so it’s interpolated on the non-firing client and we seem to take damage before the ball hits us, which looks unnatural. The second one uses extrapolation and still looks relatively smooth.
The issue
As I initially had no idea at what frequency the server would send physics information to the client, I made the firing client send information to the server on each renderstep, and the server equally sends this info to every client as they receive it. I did have plans on improving this, but I was hoping this simple method wouldn’t send or receive too much data with only one or two clients in game. Sadly, this isn’t the case, and while I tried other methods like grouping my remote calls, using string.pack on my data, or just sending data less often, nothing seems to really bring the amount of data down to an acceptable level; when updating the CFrame/Vector3 values within a projectile, I’m still sending twice as much data as the legacy toolset, which is to be expected, but I wish it didn’t come to that.
Two questions come to mind:
-Is there any decent way to bypass the current physics interpolation? I’ve seen on other threads mentions of interpolation being done with a Hermit spline curve, and while I haven’t delved into the math just yet, I’m hoping that getting enough samples of the projectile’s position overtime might help me solve for the uninterpolated points of the spline.
-…Should I do it? I realize the interpolation is here for a reason, and while we’re no longer able to obtain the uninterpolated CFrame from the client, I’m guessing there might be a reason behind this too. I’m afraid I might be running head-on into a problem that I’ll only see later down the road, so I’d like some advice on this. Is using extrapolation on fast-moving projectiles an appropriate solution?
Thanks for your time! Let me know if you’d need me to provide more info on the script in its current state.