So, I am working on a game that involves alot of viewmodels and as viewmodels are client sided, it is quite difficult to have a sync between the Tool the server has and the Viewmodel of the client.
What I did for Gun Bullets
I launched the bullet from the client viewmodel towards the Mouse.Hit.p, and passed it to the server, the server then carries out sanity checks and then launched the Bullets starting from the Tool towards the Mouse.Hit.p, Raycasting is on client (thats sanity checked too). So that doesnt cause any issue and as bullets are fast projectiles.
What I currently have for a Rocket Launcher
As the rocket is a slower projectile, I decided to use the Touched event as hit detection. The client launches from the viewmodel and the server launches from the tool, both have a slight difference in position but they head towards the same direction. This is the thing that causes the main issue, the server is doing the hit detection, what if the server rocket hits something, the client doesnt? Or even the other way around. This will cause a major issue.
How this works
When a tool is equipped, the client makes it invisible and equips the viewmodel it corresponds. For shooting, the server returns the server bullet which gets destroyed locally and I haven’t faced any kind of issue with this scheme.
I am not very experienced with Viewmodels and would like some advice on whether I should follow this aswell as a solution for the rocket launcher. Im curious how other FPS games sync up this stuff without the slightest notice.
What I tried doing
I tried syncing them up using tool grips and Offsetting the viewmodel a bit more. That however doesn’t solve it, it messes the animations, although its somewhat effective so I would do this in the worst case.
what I personally did for mine is to have the projectiles/bullets be entirely invisible on the server, instead it fires a render remote to all players with the projectile itself and the method to move said projectile along with the player who fired the projectile as the passed arguments. I have a LocalScript to catch the remote signal and checks if the original projectile sender is the same as your local character, and if it is, move the projectile’s position to your viewmodel’s projectile firing origin point. I clone the server’s projectile and set its position to the server’s projectile (if the client is not the original projectile shooter), and move it with the given method (i.e cframe, body movers) .With the server side projectile received from the remote, I make an AncestryChanged connection and check if its parent is nil to see if it’s destroyed; and if it is, destroy the client’s cloned projectile
tl;dr
-client fires projectile
-server creates an invisible projectile; fire a render remote to all client
-client receive said remote, check if the original shooter is the local player and if so, move the projectile to the viewmodel’s firing position
-client render projectile, destroy client projectile when server projectile is destroyed
I would suggest building your function before your aesthetic. If you create animations and allow that to decide where the tool is, you will have solved the problem of tool sync (obviously). Then all you have to go is get a ViewModel that ALMOST matches the tool version.
I would pretty much flip the problem solving logic. Instead of thinking how to sync the projectiles with viewmodels and tools, think how to sync viewmodels with a functioning projectile system that uses tool positions.
I didn’t quite get what you meant, do you mean I should make the bullets working without the animation then make the animation based on the position I retrieve that turns out best for the sync?
Oh I see, but don’t you think there might be latency issues for laggy players where the responsiveness will severely go down for the player because of the damage and bullet delay?
definitely, you can probably negate this by updating the client’s projectile every frame to make sure it syncs up with the server, which will also removes the need to replicate the movement method on the client side
In our games, clients do all of the hit detection. The server just uses the starting point and solves the differential equation with the time of hit the client gives it to determine if it is realistic. As long as the client and the server are in agreement on where the start and end point are, this causes no issues. That’s why I recommend solidifying that before considering the viewmodels at all. The viewmodels should have no bearing on the sync between the server and client.
However you want to handle that sync is up to you, though.