Physics upon initial creation dilemma

I am looking for advice on getting physics to not lag super hard when they are initially created as in this example down below:

I know that setting the network ownership to the player will make it smooth, but it only makes it smooth for one player and makes it even laggier looking for everyone else than when it is set to the server. I currently have it set using part:SetNetworkOwner(nil) giving it to the server, but it is even stuttering like in the example in studio, not in an actual game.
This also happens when I use part:SetNetworkOwnershipAuto() as well, but I was advised not to use it.
I am creating a part, giving it a bodyvelocity, and then parenting it to the workspace.

I was wondering if there was a method to employ to prevent the parts from stuttering at the start without setting the network ownership to the player.

I also want to refrain from cframing them as I want them to have collision detection and cframing can bog down the server sometimes too.

If you aren’t using rays I would start by doing that. Then I would use a trail in order to give it the glowing trail like effect it has. By simply following the rays. If you aren’t going to actually see the arrow while in mid air then there is no reason to have it. Just put it wherever the ray ends.

1 Like

Try using a VectorForce i think they have better replication than the old bodymovers

This would also work quite well, assuming he doesn’t want any type of drop on his weapons. If he does then that’ll become a mess.

1 Like

He could make the arrows massless by using the new property

When the attack starts, create the projectiles while they aren’t yet needed and call :SetNetworkOwner(nil) right away, so that they won’t be seen stuttering. Then, half a second later when the projectiles become visible, they’ll already have server ownership and won’t stutter.

You might need to switch the projectile code over to server-side, but it shouldn’t be too hard.

They clearly have travel time, if I wanted them to travel along a ray I would have done that by now and I already stated that I wanted to refrain from cframing it. This isn’t answering my question at all.

I will give this a shot

You do realize you can add travel time via Rays right…?

1 Like

Can you elaborate, I am not sure you’re talking about the same thing I was.

1 Like

Lets propose you’re trying to arch your bows, like I stated.

If you merely add a simple wait, or have the arch register a new angle during a runservice, etc… that adds a good amount of travel delay. But as I stated, that’s with archs (which I’m assuming you’ll have due to it being a bow)

1 Like

The projectile code is already on the server side. It would be difficult to sync it with the animation if there was any server delay if I had to create the arrows and then wait an unknown time for them to appear.

What about the option of the server just using :FireAllClients(), and each client creating their own version of the arrows, so that it looks smooth on their screen? You could just provide the starting position and make each client use the exact same function so it all replicates - pretty much - the same.

I don’t want any delay. That is the whole point of this post. This is happening even if i simply just shoot a block out using a velocity. I just want it to travel in a straight line. If I had it following a ray I would have to interpolate its cframe from start to end and constantly check to see if it is colliding using rays, which I already stated that I wanted to refrain from doing.

1 Like

I would have to check collision on all of them, and say all of them hit something to deal damage. The server would receive 8 hits from 1 ability.

Wouldn’t using :FireAllClients() be used for cosmetics only? You only need to do the actual damage mechanics with the player who is firing it, and you could choose how the damage is worked out.


I will give this a try, thank you. A quick question though. How will i detect when the arrow has touched something if it isn’t created on the server? Would I just create an invisible server version that is happening? That might make it look like things hit something when they really didn’t or vice versa.

Setting it to massless doesn’t affect it when you’re using a bodyvelocity because the bodyvelocity negates gravity anyways

Hm, that is a valid point.
I tested this with a gun system before, with a server side check on if there is actually somebody where the person says there is, however, due to the latency between client and server, and because gun fights are very active and people move around a lot, the server wouldn’t “see” anyone at that position and reject it.

An alternative would be to do the check on the client for the collision - but that opens up a major vulnerability - so I guess this method may not be the best solution, unless you come up with a good solution. Sorry

1 Like