Recently, I’ve been reading a lot on this issue both here and on the Wiki. From what I understand, relying on the server to create your bullets in a gun game is inefficient. Right? For example, firing a remote event from a client script with just a target position from a ray or your mouse position in the parameters, and allowing the server to create the bullet itself. Is this only inefficient if the bullet is moving? My games, for example, utilize static rays/lasers (they are meant to look like bullet trails) for the bullets and the server creates these as anchored parts. Is it inefficient for the server to handle that as well?
So, the other option I can find is to fire the remote event from a client, and then in a server script fire a remote event to all clients. Then, each individual client renders the bullet (Except for the original firer of the bullet, that client rendered the bullet immediately so there’s no latency on the firing player’s end). Is this really more efficient? I’m in the middle of overhauling one of my games to do this, and I just want to know if it’s worth it. There are actually more remote events being fired in this case: from a client, to the server, to all the clients, and then back to the server if any of them register a hit. Cutting down on the latency between mouse click and seeing the bullet is a huge plus, but will this actually end up causing MORE lag for my players, with all of the extra remote events? That’s my main concern.
The thing about tools is that it’s tricky to make them FE compatible just because there’s so many loopholes the Client can go through to exploit the Remotes. My advice for your scenario is that you should be performing consistent sanity checks through your server scripts.
And if you already know how to handle that, then hey, more power to you.
My server scripts just have a debounce/cooldown to prevent the remote event being spammed, is that enough?
Is it like, inherently a bad idea in general to use tools? I took a six year break from Roblox from 2012 to 2018 so some of the things that changed during that time I’m still catching up on
Well, in that case, the server shouldnt create these anchored parts to emulate bullets, client should. although i rather doing raycasting clientside for performance purposes
About server side cooldowns, I rather avoiding that since it could delay more than you expect, using tick() to know the interveal between shots should do it
It’s not so much that it’s more efficient, you’re just able to shift the performance impact off of the server. There’s no reason to handle visuals on the server if you can avoid it.
It shouldn’t be significant, clients would have to communicate to the server if the visuals were handled by the server anyways. RemoteEvents vs replication is probably an arbitrary difference, not something significant.
For the record, this is true for anything that relies heavily on user input, not just tools. It’s an inherent issue with online games in general; you can’t really be sure what the client is doing on their machine.
Other checks would be helpful (checking for ammo, make sure they’re alive, etc.), but for the basics that’d be fine.
You should absolutely not rely on the client to raycast. This is a terrible security practice and leads to exploiters being able to constantly get perfect hits regardless of walls or distance. Visuals are one thing, the underlying detection is another.
This is still a cooldown, so I’m unsure what your point here was.
oops forgot to explain myself on the tick() part, you’re not applying cooldowns, you’re just making sure the remote event is not getting spammed, and you could make a strike system off this, perhaps you could get false positives but it’s worth trying