Initial physics slowdown when spawning and applying velocity

[Unknow_sad]

When a new physics Part is cloned into workspace and an AssemblyLinearVelocity is immediately applied, the Part does not appear to move at the expected velocity during its initial physics steps. It produces a noticeable initial slowdown/hesitation before behaving according to the assigned velocity.

This is particularly noticeable with high velocities and is problematic for fast-moving projectiles such as cannon shells, grenades, rockets, etc.

The issue also occurs when using Roblox Server Authority. Since Server Authority is intended to provide authoritative server-side physics simulation, I expected the initial velocity to be applied consistently from the first simulation step.

Steps to reproduce:

1. Create a simple BasePart named “Shell” in ReplicatedStorage.
2. Make sure the Part is unanchored and can participate in physics.
3. Create a Script that spawns the projectile during the simulation.
4. Clone the Part.
5. Parent it to Workspace.
6. Position it at a spawn point.
7. Immediately set AssemblyLinearVelocity to a high value.
8. Observe the projectile’s movement immediately after spawning.

Example:

local projectile = game.ReplicatedStorage.Shell:Clone()

projectile.Parent = workspace
projectile.CFrame = workspace.Spawn.CFrame
projectile.AssemblyLinearVelocity = workspace.Spawn.CFrame.LookVector * 500

The projectile visibly experiences an initial slowdown/hesitation instead of immediately behaving as an object traveling at 500 studs/second.

The problem is particularly easy to observe when recording the projectile with a high-speed camera or comparing its position/velocity during the first few simulation steps.

The issue appears to have existed for a long time and is still reproducible with Server Authority.

This makes it difficult to implement reliable high-speed physics projectiles. For example, a tank shell should leave the barrel immediately at its specified muzzle velocity, but the initial slowdown changes the projectile’s trajectory and timing.

I have reproduced this behavior with Server Authority enabled.

Expected behavior

When AssemblyLinearVelocity is assigned to a newly spawned physics assembly, I expect the assembly to immediately participate in the physics simulation using the specified velocity, starting from the first applicable physics step.

For example, if AssemblyLinearVelocity is set to:

AssemblyLinearVelocity = direction * 500

the projectile should immediately move according to a velocity of approximately 500 studs/second without an unexplained initial slowdown or hesitation.

This should behave consistently when using Server Authority.

[Tavikron (Octav)]

You never seem to set the network owner to the client firing that projectile

[Unknow_sad]

That’s normal it’s called server authority.

[tudouuuu211]

Hi, I am trying to figure out if this is a regression or has been like this for a long time.

If you don’t enable Server Authority and also set ImprovedPhysicsReplication to disabled. Does this still repro?

[Unknow_sad]

Yes, I tested that configuration as well. With Server Authority disabled and ImprovedPhysicsReplication disabled, the issue still reproduces.

Interestingly, there is no noticeable slowdown when observing the projectile on the server side. The slowdown seems to only be visible from the client, which makes it appear to be related to physics replication to clients.

That makes the behavior quite strange with Server Authority enabled, since the server is authoritative over the physics simulation. I would not expect this kind of initial slowdown to occur in that case.

[tudouuuu211]

So it doesn’t look like Sever Authority will fix this. This is more like a client side interpolation issue and they are many reasons for this…We could improve this by improving the client side prediction, however that work isn’t planed at the moment.

[Unknow_sad]

Thanks for the clarification! I understand better now. I hope this can be revisited in the future, especially on the client-side prediction/interpolation side, as it would make projectiles much more responsive and consistent from the moment they spawn, especially for high-speed projectiles.

[Unknow_sad]

I just found another issue that I had never noticed before.

When using a simple projectile setup like this:

local projectile = game.ReplicatedStorage.Shell:Clone()

projectile:PivotTo(workspace.Attachment.WorldCFrame)
projectile.AssemblyLinearVelocity = workspace.Attachment.WorldCFrame.LookVector * 200

projectile.Touched:Connect(function()
	projectile.Anchored = true
end)

projectile.Parent = workspace

The projectile does not end up at the same position on the server and on the client when it gets anchored.

For example, when the shell hits a wall:

• On the server, the shell is already partially inside the wall when .Touched fires and the shell gets anchored.
• On the client, the shell is still clearly in front of the wall when it gets anchored.

So the final position of the projectile is completely different between the server and the client.

What is especially strange is that this is just using .Touched to anchor the projectile. I don’t remember seeing this behavior before.

Could this be related to a recent physics/replication change or regression? Has something changed recently regarding .Touched, AssemblyLinearVelocity, or client-side physics replication?

I’m wondering if .Touched is now being handled at significantly different simulation steps between the server and client, causing the server to detect the collision earlier/later than the client.