I had issues with .Touched when I handled it on the client. I tried it out on the server and some finnicky behavior such as a part with the listener attached obviously hitting another player (on the client’s machine too) but nothing detected. On the server, although there is some added overhead, I’ve found hit detection to be much better.
1 Like
You say the server should only handle damage, how about stun?
Stun? Depends on how stun is calculated. I would say the server still.
Remember, anything that is handled by the client can be manipulated by exploiters. That is why Roblox destroyed half of their games back in like 2015 with forcing FilteringEnabled. Before, the client could change anything they wanted on the server without issue.
Nowadays, with filtering enabled, an exploiter cannot change anything but their own client. Here is a list of what they can edit:
- User Interface (don’t have the client handle stamina, etc)
- Their own workspace (but do note that this will not replicate with FilteringEnabled)
- Their Character and Humanoid
a. this is one of the only things that bypasses FilteringEnabled (which I’ve hackishly used for client sided rendering of ladders)
b. this is subsequently the purest source of exploits in modern roblox
c. it is allowed to bypass Filtering for the network latency advantage (which I think is not a good reason for the headaches it causes sometimes) - They can delete, add and decompile local scripts, but not edit (though with decompiling, might as well be able to edit)
- They can interact with your Remote Functions and Remote Events (hence the need for sanity checks on the server)
Overall, I’d say Roblox is almost on par to most modern AAA games when it comes to security. The only way exploiters can exploit, is by tricking the server or messing with the character. If they didn’t give the client direct access to the character/humanoid, I would say Roblox would be better than AAA games.
I do note I am overly annoyed that they had to patch it in 2015, rather than originally have it at launch
2 Likes
I had a basic understanding on how filterimg enable works, thank you so much for the further explanation, though. Also thank you for the input in stun.
This should be my last question regarding these Client - Server interactions, but how would fireballs be handled as well? For reference let’s say a Sonic Boom or such (Guile’s projectile, from Street Fighter). Where would the projectile be created? When would it be created? Also what about hit detection? Would it be handled in the client as well?
The main flow for which fireballs should be handled is like this:
- Client registers that user wants a projectile
- Client fires a remote event/function with that information
- Server handles instancing a projectile and it’s physics
- Server handles hit detection only
- Do projectile behavior on server
Don’t forget that since filtering enabled is active, local scripts that do damage or instance parts won’t replicate to the server either. It MUST be handled by the server. Also, anything that you don’t want to be messed with by an exploiter should be handled by the server.
Hit detection on the client? Unless info is sent to the server, no one will be damaged other than on that client. If client does handle hit detection and sends it to the server, an exploiter can mess with it.
Projectile created on the client? No one else can see it. (Which may be useful for ghosts/effects that only one player should see, or client-side rendering to save server memory/bandwidth)
The only thing that the projectile could possibly be a good idea is Physics Handler set to the client. Except that makes physics really laggy for everyone else if that client has high latency/ping. Not to mention, that may let exploiters mess with the physics of the projectile. Best to leave the physics handler as the server for projectiles.
3 Likes