Problems with replicating part movement to server

I have a projectile that spawns on the server, than the network owner of the projectile is set as the client, then on the client I position it and shoot it.

https://gyazo.com/f7ab01fcbfe8a1376d24f52770b3e127

But as you can see, it does not work. For other players the projectile is spawning at its default position and does not move.

1 Like

Your problem here is that even though the network owner is the player who throws the projectile it’s still only being changed on their client because the part does not start or remain attached directly to the player’s character and thus is not in a direct link to their movement input. To fix this you set the network owner to the player who threw it like you’ve already done, but then you unparent the physical parts that are on the server from the workspace(part.parent = nil) after referencing them so that they still exist within the game but are not within the physical simulation. Then once you have them saved as a script variable only you have them fire to replicate to all other clients as if they were on the server so everyone sees the projectiles the same way but it’s not being messed up by the server’s weird latency physics solving system that’s too broken to even really be useful for those kind of things.

Essentially what network ownership does is prioritizing which client who receives the part’s updated physics-based position and orientation first for a smoother experience. However, it’s not “disabling” filtering enabled and you will still have to use remotes.

What you have to do is set the part’s velocity and position on the server.

I also noticed that your “flying” isn’t replicating properly. You have to use a bodymover or similar (which you actually can update on the client as long as you have ownership).

2 Likes

So I have to add a Body Velocity server side, then update it client side?

Should he maybe just add the Body Velocity on the local client side of things after spawning the part on the server? Just a suggestion but it’s worth a try, what’s the worst that could happen?

I think it wont work, it will in the client, but the server wont detect youre adding a body force inside the part, thats why he suggested to add in server then alter the values in client

I’m running into a similar problem here. I’ve got the server controlling a player’s unit placements (for both replication and security) and then firing the client to animate the projectiles from that unit (for latency for the player), but I still want other players to see those projectiles even if there’s more latency involved. Here’s my code that does the projectile:
(Many thanks to EgoMoose on Modeling a projectile's motion - #21 by TerminusEstKuldin for help with the projectile motion!)

local function shoot(projectile, t, source, target)
	
	local x0 = source.Position	
	local v0 = (target.HumanoidRootPart.Position - x0 - 0.5*g*t*t)/t

	local function x(t)
		return 0.5*g*t*t + v0*t + x0
	end

	local function v(t)
		return g*t + v0
	end

	local t = 0
	Heartbeat:Connect(function(dt)
		t = t + dt
		local position = x(t)
		local velocity = v(t)
		
		if velocity:Dot(velocity) == 0 then
			velocity = v(t - dt) * Vector3.new(1, 0, 1)
		end
		
		projectile.CFrame = CFrame.lookAt(position, position + velocity)	
	end)
end

projectileEvent.OnClientEvent:Connect(shoot)

Now it works beautifully on the client side, but the animations don’t play for other players. What’s important here for my purposes is that the projectile’s model is created on the server, then the part is sent to the client to do the animations. I thought that since the part is parented to the Workspace, it will automatically replicate to all clients even though the movements are done on one player’s client. Or is there some other kind of behavior?

two good ways to handle this:

  1. make the projectile on the server, and move it on the server.
  2. fire a remote to the server, which fires a remote to ALL clients, and each client makes its own projectile (that only they can see), but they all have the same destination/speed, so it will be pretty well in sync (except someone with 500ms ping will see projectiles from half a second ago).

With method #2, you can ensure that the client firing it doesnt have any latency by immediately doing the projectile for the person who fired it, then telling the server to fire a remote to the OTHER clients, as it doesn’t really matter if they are seeing it in sync.

However, if this is a weapon projectile, it should probably be handled on the server-side otherwise people can tell the server they are shooting X player from Y position even if they aren’t even in that area. Or, you can still do it client-side (which I recommend), but do security checks on the server-side (i.e raycast) to verify it is possible to shoot that location from where that player is. That way, people don’t make “aimbot” scripts that just shoot through your walls and such.

If you’d like I can explain in better detail if this is unclear. Just remember, NEVER trust anything a client sent from a remote. Always do validation and security checks. Even just cosmetic stuff can be abused in major ways

1 Like

The problem is the projectile faces the user’s mouse while he’s holding the key, doing it on the server is extremely laggy, and other clients can’t get another’s client mouse, so the only way is doing it on the user’s client and replicating it to the server using network ownership

Thank you so much, it worked. For anyone wondering, just parent a body force to the part and give ownership to the client, than in the client you can modify the force however you’d like and it will replicate!