Hi there! I’ve been working on a fishing rod for my upcoming project, however, I’ve ran into some issues with replication.
The Problem
As you can see in the video below, player on the right is seeing a very noticeable delay before the fishing rod bobber starts flying. This of course is not visually appealing at all and thats what I’m trying to fix.
How it currently works
The bobber is initially connected to the fishing rod via a weld. When a player is casting the bobber, that weld is disconnected locally and the bobber is moved via BodyVelocity. In order to replicate this on other clients, a signal is sent to the server (through a RemoteEvent) so that the server will also un-weld the bobber and set the client as the network owner of the bobber. However as you can see, theres a noticeable delay.
What if you just made the bobber only exist on each client (each client creates/renders a copy of the bobber)? This is a method commonly used for projectiles, and seems to fit your purpose.
(I know a bobber really isn’t a “Projectile” like a bullet or something but for your purposes looking into projectile replication in general might be helpful to you)
Initially I was just setting the CFrame of the bobber directly and doing so on every client. This works great for simple projectiles like a bullet, but in this case it resulted in more replication issues down the line when I was trying to stimulate fish movements and reeling the line. The code got pretty messy and the bobber just didn’t always appear in the same position across all clients, etc. So I switched to using BodyVelocity since it made things a lot easier. The only issue I’m having is this delay that’s happening, and I’m wondering if theres any way to fix it without going back to the previous method of having a copy on each client.
One thing you could try is playing the animation on the server to sync the motion of the casting and the flying of the bobber.
Why don’t you just release/create the weld every time the tool is equipped/unequipped and then attach the bobber using a rope constraint or something? There usually isn’t any replication lag when moving an already server-owned object via BodyVelocity.
You could also try moving the bobber on the client (along with the animation) and then add in the server effects and a server animation right after.
You could keep the client animation from replicating by loading an animation created only on the client into the player’s humanoid.
You could have the client render its own copy of the bobber and save the server the trouble of doing anything at all. Is the presence of the bobber on the server important?
I don’t think that would work because I don’t think its due to the RemoteEvent delay that’s happening. The client fires the remote slightly earlier during the animation to give it enough time to deliver to the server. As you can see in the video, the player who is spectating on the side sees the bobber disconnect from the rod and a line rendered between the rod and the bobber. This means that the server has already un-welded the bobber and made the rope visible. Which means that it’s not the due to the RemoteEvent delay but rather due to the SetNetworkOwner delay.
Connecting a RopeConstraint will make the player fly with the bobber. I would have to continually increase the length as the bobber flies in order to prevent this, and it seems pretty inefficient. That’s why I just connect the RopeConstraint after the bobber has been landed.
Yes it’s pretty important to have the presence of the bobber on the server so that the position of the bobber can be replicated properly across all clients. It makes things a lot easier because, as I’ve said in post #3, I did attempt that before but it caused more replication issues down the line when I was trying to stimulate fish movements and reeling the bobber back in.
So… I tried this but the issue still happens? That’s weird.
What’s even more weird is when I disabled the code that sets the BodyVelocity on the client so that only the server controls the BodyVelocity, the delay was still there for the server and other clients but not the client that was casting the fishing rod.
You could try having the bobber part created in advance for each player, and positioned somewhere where players won’t see it. Then the client can instantly teleport to where it is needed, and throw it.
A very common thing to do, which is a really good idea to hide lag, is to play animations.
Animations and visual effects in all games are just to hide the lag, and they are never affecting anything (except hitboxes and those kind of things).
The server should not animate the bobber, the clients should.
In your case, you should just get the server to emit that a player is about to throw, and then all the clients will wait for the animation to finish or wait for a specified amount of time, before showing the bobber and adding BodyVelocity.
I think maybe you misunderstand me because I wasn’t clear enough when I wrote my answer. Your original solution has to wait for the server to weld & set network owner, and other solutions either create the bobber on each client, replicate the movement for each client, uses animations on the bobber, puts the object on the server, or would be inefficient because the ropeconstraint must be continually increased/decreased.
What I mean by my solution is you would create the bobber on the server when the player joins, and then from there onwards, do all physics from the client who holds the tool by setting the network ownership to that client, teleport it as soon as the tool is equipped, then connect the bobber to the tool, maybe using a ropeconstraint like @ndrwcswll suggested, but create it on the client, then disable it when you throw the bob, and enable the rope again with new distance once it has landed.
This solution requires little work on the servers end, wouldn’t have to wait for the server to do its thing, doesn’t make use of animations with the bobber, doesn’t require manual replication between each client, and wouldn’t require a ropeconstraint to be constantly adjusted to prevent the character throwing. I don’t really think you have tried what I suggested.
Assuming the position isn’t critical to the game mechanics, each client can perform its own animation of the bobber. With FE, each client can play the casting animation and control the position of the bobber, welding it back onto the rod like it was before when reeled in. I’d recommend having a remote event that fires on the server to tell all the clients to play the casting animation so that the entire operation of casting and positioning the bobber can be done independently on each client. You may need to send some additional info like the direction the player is facing and the direction of the cast.
In general, non-critical animations like this can be handed off to clients without repercussions.
