How to make exploit-proof client lighting change?

What I do for my games is this

I create a local script in which game components require–> if its deleted the game becomes unplayable

I create an event which is fired randomly to the server, if the server doesn’t get this event in x amount of time then they get kicked

1 Like

Clients can’t disable/delete objects in the server is correct but when client delete their “server replicated” objects, the object still exist in the server but not the client therefore only that client doesn’t have the object. For example, there is a blur effect on the server, the server will replicate a blur effect to all the clients, making everyone have blur on their screen. If one client blur effect somehow disappears then that one client will not have blur but the other clients will still have blur as long as the blur in their client still exist.

1 Like

They don’t necessarily need to delete the entire script, they can “hook” your RemoteEvent function and change it to whatever they’d want it to be, for example, always returning true. Thus the script still working yet the Anti-exploit function tampered with.

1 Like

Yeah I forgot lighting is client controlled, mistook it for something else. MB

1 Like

Correct.

It’s simply too much effort and performance let go, not worth it to deal with this after all.

1 Like

That’s sad because now I can’t powering my imagination :pensive:

1 Like

Why? It’s just that exploiters can delete the fog, but it won’t effect other players, considering the current roblox anticheat is decent

1 Like

The point of the blur effect is to hinder vision of a player, if the player can just get rid of the blur by exploit then the whole ability is quite useless. I also ignore Roblox anti cheat because they dont have good reputation but even if the anti-exploit works then I still want to rely on myself more.

1 Like

While you can’t make this exploiter proof, you could make it to the best of your ability. Roblox is in the process and has executed their own anticheat with byfron and even has gone out to work with a hacker groups to prevent the rise in exploits. While this doesn’t mean that everything you make now is 100% exploiter proof, these are changes roblox is making on there end to help.

Client side anticheats are impossible to enforce because simply, an exploiter has full control of their local enviroment. Meaning no solution anyone can give will work 100%. Your best bet as a creator is to prevent this, but also understanding that there will always be a way around client anticheat elements, as an exploiter has more direct access to adjust their enviroment.

→ While I’m not saying client side anticheats are not important, however as a creator the main focus should be the server related exploit issues as these changes are replicated to every client, meaning everyone can see it.

If you acknowledge the above and still wish to make one, the best you can do is

  • Ensure the blur is enabled when it should, and the blur Properties aren’t modified / make sure the blur also just exists

  • Ensure the client has recieved the remote event, and that it has fired when it should have. Making sure the remote event exists on the client and the client still has a connection to it.

  • Making sure this script that holds the anticheat information, isn’t destoryed, Enabled at all times, And the Parent doesn’t change

  • When detection of unwanted changes / exploits you should kick or punish the player if one of these events occur

You cannot protect the client in anyway, however setting a basic anticheat is something that can make it more annoying to remove / provide more chances of catching exploiters.

1 Like

Ye sure, making client side anti cheat like:

Runservice()
if BlurBoolean == true then 
   if blur.Enabled == false then
       player:kickForEternity()
   else
       return
   end
end

or any other way is easy. However, exploiters that have more then 10 iq can just spend less than 10 seconds to delete the script.

1 Like

This will cause unimaginable lag…

1 Like

only for as long as the blur lasts. Seems kind of fitting if you ask me, tbh, bc of the whole impaired state

1 Like

Like every Game Developer. Deal with it. There is always going to be cheaters, and losers sitting at a desk. The best bet is to hire moderators to ensure people aren’t cheating in your game.

There is absolutely no way to completely make a game invurnable to cheating with scripts. Since exploiters can just edit their memory to stop coroutine threads from running (Memory Write hacking) unless the Client Developer makes an anti-cheat, which is more of just an anti-hardertomakecheatswork. Which is exactly what Hyperion is. Playing DaHood for five minutes shows it doesn’t work right.

1 Like

If you were to do this I would use Unreliable Remote Events so that there isn’t too much loss over the network. I haven’t tried them but the issues with them would be order, and there newer so I’m not too sure what it means if an exploiter overloads their client if they still recieved them. Just an idea that went into my head that I would try out / learn more about them.

1 Like

Unreliable RE doesn’t guaranty to be fire everytime so not good for a competetive mechanic.

1 Like

^

If there is a sudden network change, or their internet is slow. It won’t fire.

2 Likes

While the idea from @robloxdestroyer1035 isn’t to fire it once. Its to fire it over and over again. When you fire a RE there is a bunch of checks that the remote event does to ensure it is fired. This then stalls and takes time. Unreliable RE skip this, because they are fired so much in a short amount of time. Which would be good in this case.

If we fired a remote event and a Unrealiable event 100 times over 3 seconds:

→ Each of the remote events would be fired, all 100. However a lot of resources were used to make sure all of them went through, and caused a higher ping a loss in network

→ Most of the unrealiable events went though, lets say 90, unorderly but quickly. Resources weren’t damaged too bad, and some requests dropped to make sure a stable network.


In this case (firing a RE to check the blur’s status in a short amount of time), it actually doesn’t matter how many times its fired , just that its being fired and checked on constantly. And both RE and unrealiable RE do this, just one doesn’t put as much stress on the network.

Theres still questions I have, and I’m newer with them.


Ah ok. At what point does this occur? do you know

1 Like

This is called a “RemoteEvent” and it is much more performant than creating a loop and having the URE not return something back

1 Like

Ah ok. At what pont does this occur? do you know

When someones internet lags cause they pay for a cheap provider, or their using phone service in a deadspot.

And even at that. URE’s are so useless in so many factors. The only facture I can probably vouch URE for is User UI/In game Interaction from the client to the server. Since if it doesn’t fire, we have the mental gymnastics to keep pressing the button again and again till it works.

1 Like

This thread is way longer than it needs to be.

To answer your question; your conclusion is right, it is impossible.
You can attempt to prevent exploiters from removing the blur, but it will always be possible to bypass it.

1 Like