Hey there! I’m trying to use a remote event to make the client clone a gui from replicated Storage, and then show it. However there’s a huge problem. If the client deletes the remoteEvent, the gui is never shown. This gui is truly truly truly crucial to my game, and if it is disabled, it would ruin the other people’s play session. Is there any way I could literally protect my remoteevent from being deleted?
Remember that if a client deletes anything on their end, it’s only for their end. The server and other clients will still have the remote. There’s no way to prevent an exploiter from deleting anything, but have some sanity checks on the server.
2 Likes
I’m making a Blinding system trhough a gui, so it IS really crucial. It doesnt need any sanity checks
I could cover the person with a part, but they could delete that too. So I need to find a way to properly implement this
2 Likes
You can’t prevent the client from manipulating things.
And for a blinding system, you’d probably be better off changing lighting settings of all or just a specific client.
But the client can still always change that, you cannot prevent it.
3 Likes
aw. alright thanks for replying 
1 Like
.Changed event is a good alternative for Remote Event.
It could be an alternative for any kind of dangerous remote events.
2 Likes
Not sure what this means. Changed and RemoteEvents serve two different non-interchangeable purposes in development. RemoteEvents aren’t dangerous, what’s dangerous is poor code structuring such that an exploiter is able to send manipulated data and cause sufficiently visible issues for others.
4 Likes
but here it isnt about any data sent.
there are no arguements in the remote event. the cause of the blinding is already sanity checked. The problem is that the remote event that actually blinds the target, doesnt exist, because the client has deleted it
2 Likes
Sorry, the post I made was not made in response to your thread but to correct a misconception raised in the thread that two completely different objects served the same purpose.
People have already answered your thread so I felt it wouldn’t be necessary to parrot the responses but as you’ve been told, nothing you can do here. The Gui as well as the decision to receive the data from the server via the remote is up to the client and therefore an exploiter can remove or stop elements that may cause the Gui to get added.
2 Likes
alright alright thanks for replying !! 
1 Like
he means to put any object and change its property whn it needs to blind it and in local script-
object.Changed:Connect(function()
--blinding and stuff
end)
1 Like
This is a complicated question to understand since there is no proper context given. What are you really trying to make? A game like Breaking Point where the player chooses to do an action in public or in private, or are you trying to basically make a flash-bang grenade that blinds the target?
I don’t want to mention what everyone already did again, but there are other ways that we can figure out to fix this problem.
If you can give us information on what you are trying to make with an example, we can figure out together other ways to solve your problem.
Ultimately that doesn’t quite change the circumstances though, just the nature of how you’re determining when a player gets blinded. ValueObjects and RemoteEvents are still different in their uses and the initial problem remains. Changed connections are still subject to disconnections, overrides and other terminations.
The core of the discussion is preventing exploiters from removing the blinding Gui which is not possible because exploiters can do as they please on their own machine.
1 Like
do a check if the remote event is there or not if it isnt just sorta kick the player
yea but how? cuz if i detect something’s missing, I have to send a message to server to kick. for that i gotta use remote events. 
1 Like
I’m currently switching to Knit Framework because it is also known for protected Remote Events aka Services. But thanks for letting me know! gonna check Rex out
1 Like
With dangerous, I mean the ones that can make a big differeance in the server, In which a exploiter could abuse It.
Knit doesn’t protect remotes either. The purpose of a framework is meant to organise your code’s flow, security is up to the developer to the best of their ability. Even if you incorporate Knit, it still faces the root problem that a client can remove or block the server’s request to blind.
Service API to the client is incorporated as references to remotes in ReplicatedStorage. Effectively when you’re calling service API it’s just a convenient and clean way of firing remotes. There’s no actual layer of security that it’s giving.
This problem is not solvable. Not every problem has a solution.
yea I’m aware it is unsolvable, but using a framework will help shave off a lot of script kiddies.