Roblox Studio is an entirely different application that works different from the Roblox Player.
2 Likes
I have the bind for a custom camera script, I was just curious and asked if it could work. Thank you for telling me and don’t worry I won’t but a loop at the end of each script.
2 Likes
People should move their focus away from client side anti cheat, those would only just repel script kiddies and you would waste your time focusing on them rather than your real players…
1 Like
mostly just players going out of sync with the server inresult my magnitude calc are having large spikes, but i’ve come to find that most of those spikes are calculated twice so i would just ignore if they’re duplicates
Raycast from the last position you stored for stopping teleports to current position. That would be more effective, depending on how frequently stuff updates
A clever trick I found using ray casting and no clipping prevention is to be selective.
To increase performance and accuracy of reports, you should only raycast if certain criteria is met. For example, don’t raycast if there is a corner nearby or if there is narrow crawl space.
For the raycast method, also, you could think about it like this: If you can physically draw a straight line from one valid point to another which passes through a block, don’t use that for no clip detection.
But obviously this doesn’t work always, because if you followed this all the time, you would have nothing left to detect with.
Another thing. If you think about the kind of things an exploiter likes to do, you could try and detect them. For example, in many games the maps have some hidden “out of bounds” areas which the player physically couln’t access. If you detect a player entering into that area, you could safely assume they are no clipping.
But, as for most things, all of this needs to be formed around your individual needs.
Hope this helps
1 Like
What about glitching into the said areas? A large playerbase can almost always find a way to get into an area they shouldn’t be able to access.
Then it is the developer’s responsibility to patch that up. If players are glitching into an area they’re not supposed to, figure out the cause of the glitch, and patch it ASAP so it does not happen in the future. Simple.
@Amiaa16 That’s why you have catch-alls for that sort of thing. Don’t make any assumptions. Whether they exploited or glitched, if they are in an area they shouldn’t (yet) have access to, perform your magic in extracting them from the area and back into a place they do have access to.
@AbiZinho Yes but do you know how? It’s one thing to say that it’s a developer’s responsibility to patch things (obviously), but it’s another to understand how given the related context. It’s not so “simple”. Exploiters wouldn’t be widely rampant if so, nor would the need to perform maintenance against certain exploits over time.
1 Like
This post is directed toward @Amiaa16 as well.
We can have .Touched events or Region3 checks in the restricted areas to check if any player ended up there, and if so, just respawn the player by breaking its joints.
While Region3s can be expensive, it does not have to run as soon as a loop finishes (as it can still detect the player), and it can check with accuracy and more effectively than expecting the player to start the .Touched event.
While this may be a band-aid fix, to ideally “fix” the problem is to actually see what’s wrong and what’s causing the player to glitch, as I stated before. As @CodeNinja16 stated, you can check if players are in certain areas and temporarily prevent them from doing anything related to raycasting. Another way is to fill up as many gaps as possible (there’s never too much security!), as the smallest of crevices can lead to no clipping/glitches leading players to restricted areas.
The way I make my anti exploits is to use a Local Script to control the client itself but put all the client scripting in that one script. If the exploiter deletes the local script, The whole game is unplayable which will also reduce “Auto Kills” if fired through remote events. Another exploit patch is the randomize the remote events by changing the name using,
game[‘Run Service’].RenderStepped:Connect(function()
My system also can log to Trello or Discord Servers to detect who is exploiting the game itself. This can be really useful for situations. Most popular games try to make the coding into one local script to reduce the exploits. As long as the anti exploit is inside one script, Exploiters will have a hard time bypassing since they can’t delete the local script like that. If the anti exploit is in a single script, That will not be guaranteed to work.
To increase remote event security, Make sure to fire arguments to the server as
’game.ReplicatedStorage.RemoteEvent:FireServer(“CheckForDailyReward”)'
Instead of:
’game.ReplicatedStorage.RemoteEvent:FireServer(“UpgradeStrength”, 1)’ <-- This is the worst mistake you’ll make when it comes to security.
Hopefully this helped you out!
3 Likes
This is completely ineffective as the exploiter can stop the name change and hijack your environment to stop any and all detections from occuring.
3 Likes
I find that trying to shoehorn all your client-side coding into a single LocalScript just to mitigate exploitation is not really a wise idea. Client-side exploitation prevention merged with LocalScripts is fine to deter those who can’t be bothered to spend time cracking your security, but don’t shove it all into one LocalScript. Shooting yourself in the foot over fighting off a few hundred people isn’t worth it.
Sorry to nitpick, but you should be fetching services using GetService. GetService is a canonical way of retrieving services and not indexing them by their name. The names of services are already inconsistent and services have the potential to be renamed. GetServices always fetches services by their ClassName which cannot be changed.
Unless your game requires manual moderation, you really don’t need to. Discord is also not for logging. Based on what you’re doing, you could run into issues such as requests not being processed or disciplinary action from Discord staff. Above all, 500 requests per minute for HttpService may be a big budget but you’re better off saving it for other items you may need in the future.
What’s your basis for this? As far as I know, games split their code up into ModuleScripts or have as many LocalScripts as they reasonably need. I don’t think it’s appropriate to speak of this from a factual standpoint without any substance to base it on, because it leads to misinterpretation and false acknowledgement of circumstances. It could even teach bad practice if taken at face value.
Circumstantial, it depends on what you’re doing. Firing an amount like this to the server is not harmful; what’s harmful is if your server processes the request without performing any checks. I’ll give you a scenario:
I have an RPG game, where players can spend points on various attributes for their character. So that players don’t waste time spam clicking buttons, they can set a increment value. For each upgrade button clicked, the attribute should go up by that number and the total points should go down.
Dangerous Model (Client Authoritative):
- Client fires a remote passing an upgrade request, the stat to upgrade and the points to spend
- The server receives this request and increments/decrements values accordingly
Acceptable Model (Server Authoritative):
- Client fires a remote passing an upgrade request, the stat to upgrade and the points to spend
- The server receives this request, but does not yet process it
- The server checks if the arguments passed are acceptable (i.e. “Is Strength a stat? Did they pass a non-zero value?”)
- The server looks at the points-to-spend argument and confirms if the player has more than or equal to those number of points
- If the client requests to spend equal to or more than the amount of points that they currently have, there is nothing wrong with this request
- The server processes the request, incrementing and decrementing values accordingly
-
Note: you should handle this kind of thing from a RemoteFunction, so that the client can receive a status call back (
return true, "Success"/return false, "Insufficient balance").
That can work as well, Just do all the scripting in the server side for example do stat checks like if SpendableAttributes >= RequiredAttributes then
That would work as well.
Other than what I mentioned, I’m not quite sure what you mean by this statement. Coding should be split respectively between the client and the server depending on what it is that you’re trying to accomplish.
I mean, it is quite good practice to do things on the server where possible. There isn’t much that you can do on the client that you can’t do on the server. The only exceptions are things like camera manipulation, user input and local effects (like tools which locally remove parts). So, I think that @SYKOxXVenomXx is partially right in saying that you should do as much as possible on the server.
Exploits are actually detected on the client side. There is a lot you can do with an anti exploit located in the local scripts. Server scripts cannot detect client actions such as locally added items, Gyro parts for example which triggers a no-clip system. If you need it to log, you make an remote event that fires using a “No-Clip” argument. From there you code the server scripts to handle the actions the exploiter takes.
1 Like
If you detect your exploits on the client side (unless you were very clever about it), you detections are doomed to fail. An exploiter can disable or even delete your script off their machine and therefore disable your anti-cheat system.
Whereas, on the server, they would either have to use poorly programmed remotes to remove scripts, or physically hack into roblox over the internet (which is illegal, not just cheating).
What I mean by being clever about client side anti-cheats is that you could place your anti-cheat system into a custom version of the default roblox movement scripts, for example. Then, if they disable it, they can’t move (which is more of a shame for them).
So, I guess you are right about doing anti-cheat on the client, but you are still best sticking to the server when it comes to things like this.
My overall response already implies that client should be used for input and server should be for validation. I was confused when this statement was made because I perceived it differently.
Depending on the circumstances, I wouldn’t even say it’s good practice but rather a necessity to split the work appropriately, exploiters aside. You don’t want to stress the server too hard though, so some work is acceptable to be pushed to the client. The objective is not to make the client authoritative where it shouldn’t be.
Sorry, I seemed to misunderstand you. I thought you were saying you should do exploit prevention on th client 
1 Like