Velocity Prediction on the server

So I am currently trying to predict a characters velocity on the server. I am using this in combination with my module voxbreaker so that I can send players through walls. Here’s a simplified version of the script:

			while true do
				
				Hitbox.Position = self.Character.Instance.HumanoidRootPart.Position + self.Character.Instance.HumanoidRootPart.AssemblyLinearVelocity/8 

				task.wait()
			end

And this works perfectly for characters that don’t have network owners, like NPCs:

But, when it comes to characters that do have network owners, there seems to be a delay, and the hitbox lags behind a bit.

Like I said, this is all being done on the server, I am trying to find a way for the hitboxes to accurately follow the players velocity without delay.

1 Like

From watching the videos it looks like you ragdoll the opponent on the last M1? Maybe while they’re ragdolled you could do:

HumanoidRootPart:SetNetworkOwner(nil)

and then when the ragdoll ends set it back to normal:

HumanoidRootPart:SetNetworkOwnershipAuto()

Let me know if this helps at all, I’m planning on making a voxel destruction system for a personal project sometime soon so I’m going to try implement this if it works.

While technically the most secure solution, setting a player’s network owner to something other than themselves looks really ugly on their side. To preserve smoothness, the client should do the calculations for themselves locally, relay that information to the server for replication, and then the server will be the final judge. Like this:

  1. Client is launched into wall.
  2. Client calculates what voxels to break and does so, but only on their side.
  3. Each time a voxel is broken (or maybe there’s a better way of relaying what to destroy), send an event to the server telling what got broken where.
  4. Have the server check if the requested voxel could be reasonably destroyed by the client, and update those changes on the server.
  5. Update the original client’s version with the one approved by the server to eliminate discrepencies.

Can’t you just lie to the client by separating what the player sees and what others see? Basically show the client their own calculated physics, and to everyone else the server calculated physics.

There would be discrepencies because of general differences on how each side calculates their physics. For example, what if the character hangs over a cliff, but one side says they fall off and the other doesn’t? That would be a major desync, even if we favor one side afterwards.

I tried this on my ragdoll and it doesn’t seem to change anything, it actually makes it smoother for all clients.

Could you provide a comparison?

This is my alt and I made it on my dev account which I’d like to keep confidential, I’ve not really got time to separate the ragdoll from my other account’s game but I can show you some of the code:

HumanoidRootPart:SetNetworkOwner(nil)
Humanoid:SetStateEnabled(Enum.HumanoidStateType.Jumping, false)
Humanoid:SetStateEnabled(Enum.HumanoidStateType.GettingUp, false)
Humanoid:SetStateEnabled(Enum.HumanoidStateType.Physics, true)
Humanoid.PlatformStand = true
Humanoid.AutoRotate = false

also set the collisiongroups of all baseparts to not collide with themselves, and set them to massless.

I’m not sure if its the combination of these things but it seems to not affect the client since they don’t really need to control the character during ragdoll (though if you forget to set network ownership back after ragdoll some REALLY weird stuff happens)

1 Like

The issues are most notable when multiple forces are involved. For example, if the character is moving, the client will see their character snap to where the server thinks they are and then be pushed.

A much worse issue is when the character is being pushed in direction X, but then pushed again in a different direction Y. The client will recieve the commands to move in direction Y AFTER they’ve spent a latency unit moving in direction X, which results in even more snapping. A situation where a character is pushed when already being pushed is very frequent in combo fighters, which is what OP’s game appears to be.

1 Like

yeah just tried this, it actually seems to work quite well.

Will mark this as solution if i don’t run into any issues

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.