I tried making a RemoteEvent that makes a bullet on the server side which goes wherever the player is aiming (the second argument is the direction the bullet goes, which is the player’s mouse position), but that’s way too unsafe to use because exploiters can fire the RemoteEvent with whatever direction they want, basically making it an aimbot. It’s also very laggy and won’t hit properly sometimes.
The second thing I did was making it so the client makes the bullets, making the bullets client-side only, and then whenever it hits anything, a RemoteEvent is fired with the first argument (or second, considering the first argument is always the player who fired the Remote) being what it hit, and the RemoteEvent will damage that, but obviously, that is even worse, because then exploiters would be able to kill everyone in the server by continuously spamming the RemoteEvent.
What is the best way to create a secure FE compatible weapon?
Also, sorry if this topic is kinda confusing.
For the game that I have, the client decides the ray and the end part, then that is sent to the server. After that the server sends an event to each client in order for them to replicate the ray themselves, along with play the gun sound themselves excluding the user who fired the weapon. The server handles the damage in the middle of that, using the endpart that the client provided along with the start position.
Doing it with the server allows lag to be created and the client shooting the gun to notice the delay. If you create the ray and bullet by the client, and then have the server send that to all other clients, the shooter has the ray appear on-time and only other people can experience the lag, which would be minimal to them but noticeable to the user firing the gun if it were to be shown by the server.
While this is true, the server is more powerful than the client, meaning it can handle more. If all clients are having it recreated for themselves, there would be a lot of confusion from the shooter’s end. All players still have latency to the server, and some more than other. Some players would take longer to receive the shot while others would get it very quickly. Meanwhile when that difference comes up, who would the server trust? The shooter? Or the person getting shot? It would be very common that the player getting hit looks like they dodged the bullet, while the shooter thinks they hit.
The reason it’s done on the server is because the server has one point of view, if that makes sense
Sounds like your system could be easily exploited. You should just tell the server what direction the client clicked in and have the server handle ray-casting. You can fire a ray for instant feedback on the client, but it shouldn’t determine the actual hit.
This is incorrect, roblox servers are really bad at handling lots of activity at one time and tend to lag very badly when this gets out of hand. The best way to keep things on-time and running smoothly is to do as much work as possible on the client, not the serer.
@posatta I have multiple checks by the server to make sure the rays are legit and can hit, but with a normal system the client just sends a world position of their mouse which can also be easily exploited. There are ways to add checks my way just as easily.
I’m not sure what kind of “normal system” would tell the server where the bullet hit, that would be super insecure. If your checks involve firing a ray from the character’s position to the ray’s hit and making sure there’s no obstruction, there’s no reason you couldn’t just ignore the place the client thinks the bullet hits (not fire it to the server at all) and do all raycasting on the server. I guess if you’re firing a ray on the server as a part of your checks, it’s not really insecure, it just seems kind of pointless.
I am checking the make sure the ray can hit that part, which isn’t any less secure than the client just choosing a random world position to tell the server and then the server creating a ray for that. My way isn’t insecure as long as I am checking properly. Exploits such as aimbot are hard to detect and would not be solved this way, but rather on the client side also.
If servers lag so badly, then sending a ray would lag just as much. The only difference is that you’re now sending it to then server THEN sending it to all clients, making it lag even more. I see what you’re going for though
Back to the topic though, shooting weapons is something controlled by the player mouse, so having an aimbot free game is almost impossible without some sort of crazy algorithm. I guess you could send the mouse target along with the CFrame to check if they’re really hitting the player, but other than that, not sure what other suggestions I can give.
The server isn’t being sent a ray but rather a start and endpart, and the server isn’t creating a ray most of the time, and when it does it’s to check the legitimacy of the ray. It is beneficial to have the client who fired the gun see the ray they fired instantly rather than wait for the server to process it, also I don’t show the bullet rays by the client who receives it so they can’t even tell if there is lag.
It’s still information being sent to it, and information it has to handle it. When the player hit receives the info and converts a ray, they’ll most likely be out of the way anyway, because they have to process all the rays being shot and getting that ray shot at them wont be very quick due to the server taking and send all that information too. What do you lose from having the ray made in the server if you claim the server isn’t stronger than the client, it definitely isn’t weaker. You’re putting a lot of stress on all clients instead of putting stress on the server and having it replicate to the clients.
The clients receiving the data need not to process the ray for that reason. The only reason for the clients to get the ray is fro bullet holes and hit effects on parts. It isn’t putting much stress on the clients anyways and no lag is noticeable, the worst thing you can do it put stress on the server and have that replicate to the clients. This is why it is recommended you do big operations such as magnitude on the client because it can really be affected by lag on the server.