In Method A, What prevents Player B from deleting the bullet locally, thus dealing no damage?
Nothing, which is why in practice youâd add some extra security specific to your game.
Can you give an example of this extra security? Having Player B handle hit detection on himself just sounds like a bad idea to me.
Wouldnât this make it extremely difficult to hit players with high latency? Not even regarding cheats here, just like, what if Player B lives in thailand? Them actually receiving the shot might happen like, upwards of a second after Player A fires, at which point they might be 16 feet or more away. This is the exact opposite of favor the shooter.
Another potential issue is that Player B could conceivably delete the remote event, or the script which responds to it, or write a script which deletes bullets as theyâre created, and now theyâre completely invulnerable. I donât think thereâs any server side solution for this. Any client side solution is a just a band-aid which is easily circumvented via a little reverse engineering.
You could handle hit detection on the server, instead of passing that job onto B, and that sounds substantially more reasonable. Yes there are potential latency problems, but it makes cheating harder. Plus you could potentially implement backwards reconciliation to maximize responsiveness.
I understand that this is largely about minimizing network requirements, but youâre giving away a lot of control to players. I donât know if this practice is worth the security cost.
1 Like
Handling hit detection on the server just makes even more lag. However, here is how I do things:
- Make a ray on the sending client, send that origin + position over a RemoteFunction, and get a key returned
- Do hit calculation clientsided
- Fire Server, with the part hit, and the ray
- The server will use ray:ClosestPoint() to see if the player was close to the client. If so, do damage, otherwise, nothing. Also do checks to see if the ray origin is near where the player was, etc etc. Generally, pretty secure.
Thatâs how I do stuff in practice (alongside the Replication), however I didnât want to include that at the time of writing as it was probably too complex for the kind of person who would be at the stage of needing this tutorial.
However again, I am (eventually) rewriting, so Iâll keep that into account 
1 Like
Handling hit detection on the server results in less network overhead though. In your solution there is one command (CMD) coming from player A, and then thereâs a Remote Procedure Call (RPC) for every single player. If you have a game with, say, 24 players, thatâs 25 remote calls for every pellet. Yes, FireAllClients is less expensive computationally than calling FireClient on a loop, but the networking cost is the same. Something like a 5 pellet shotgun on a 24 player server firing once would be 5 CMDs and 120 RPCs.
If you do the hit detection server side there is only a CMD for every shot fired (assuming you are doing client side prediction for the weapons). Raytracing is not the most expensive thing in the world (part creation is far worse in my experience), and reducing complexity is more important than efficiency in a lot of cases (so that way upkeep is easier). If your weapons are so computationally expensive that itâs slowing down the server then you should probably rework your weapons (halve the number of pellets fired, double damage, reduce fire rate, etc.), come up with a queueing system, live with the consequences, or switch to a different engine, instead of trying to push all your calculations onto the clients who may actually have worse computers than the server. So long as you arenât reaching enormous processor usage levels on ROBLOXâs servers your players wonât notice at all.
Sometimes it helps me to start from first principles and work my way up from there when Iâm dealing with messy network stuff.
Say that weâre making a hitscan gun
Assumptions:
- Raycasts are fast
- Networks are slow
- The server is roughly omnipotent
Requirements:
- Feedback to the shooter must be immediate
- Hits must be verified by the server
The following procedure meets those requirements:
- Client shoots
- Client figures out who it hit
- Client shows hit animation
- Client tells the server who it hit
- Server validates
- Server deals damage
Thoughts?
46 Likes
Exactly how it should be done.
^ My thoughts.
3 Likes
So great that I bookmarked it
Yeah, thatâs exactly how I do it in practice.
(Iâm going to rewrite this, plus add an advanced version)
1 Like
I donât get it, you didnât even solve this example problem and your methods given do not solve the bad practice of repeatedly firing remote events.
I think youâve misunderstood the topic here - the method being used here in the example does solve the problem, because rather than having to move an object every step to replicate it (for example, a turret on a tank), setting network ownership of it will produce a smoother result with fewer calls. Itâs okay though - I can understand how this could be a challenging topic.
Just a reminder, that you should look at this âlast postâ date before commenting - you can find it on the top right of posts 
(this post was last updated over 2 years ago!)
I replicate the bullets for both the server and the client, so the client just sees the bullets as cosmetics whilst the server casts the actual bullet and deals damage. I think doing this is better as people sometimes have slower connections and it might be used for their own advantage. Thatâs just my assumption please correct me if Iâm wrong.
1 Like
I donât see where the code solves this given bad practice example, all it relates to is properly replicating a Objectâs movement, not the Mouse move. I think I might be confused here, but could you explain further and give an example of code of solving that bad practice example?
The code example doesnât intend to solve the Mouse problem ⌠theyâre not the same problem?
The topic being discussed is âConstant replication without excessive remote callsâ - the mouse problem is just an example of a poor workaround if the user was not aware of the full potential of Network Ownership.
You keep saying âthisâ but what exactly are you confused about? There are several points regarding reasons as to why excessive remote calls are considered bad practice. You should provide a more explicit concern so that OP or someone else can help you address your confusion.
As far as the point brought up that I can see, I think youâre slightly mistaken there. Mouse movement is completely different from replication although the two can be interlinked. Mouse movement should not be replicated, thatâs a pointless practice. The point is to replicate something based on user input, including the mouseâs location.
Are you confused about the network ownership, or the allowing of clients to handle visuals on their end, or the concept in general? Do you have a specific scenario regarding excessive remote calls that can be plucked at?