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.
That’s not true. Frameworks will help in the development process but not necessarily in the security process. Using a framework has no implications of security or otherwise. A game with or without a framework is as exploitable as any other, what matters more is what your code is doing.
again, I’m talking about the deletion of remote events. not their security. I have my remotes secured. the fact that they exist is important here, not how they work 
If you change the discussion from talking about remote security to preventing their deletion, the response doesn’t change. What does change however is the circumstances which instead of talking about how the server validates client requests, it’s about their presence in the DataModel.
The remotes still need to exist in the DataModel for the client to access and connect to them: in that same vein, the remotes also need to be accessible to the client. If it’s accessible to the client, then they can delete them too. A framework doesn’t change whether or not your remotes can be deleted.
And again, ultimately, the root of your problem still comes down to preventing the client from removing remotes or the Gui you want to give them which is the unsolvable problem. It doesn’t really matter if they don’t access the remote, they can stop other incoming traffic they don’t like.
If a remote event is deleted on the client, the server won’t know, due to filtering enabled.
And exploits only run on the client. So… yeah.
Plus. Why would any exploiter need to delete your remote events?
As i said above, the remote blinds people, so if they delete it, they wont be blinded!
But i bet most of the exploiters Dex the game and that they don’t know .Knit
So a lot of noob exploiters are gone
I can always fire the remote back, and if it doesnt reach the server (which is ALWAYS should) then we know that the exploiter has deleted the remote.
As @MrMouse2405 said, there could be a better way to solve this problem. You’ll just need to give more information. What are you trying to hide from the player? Perhaps you could prevent it from replicating to the client.
alright.
So I basically send a client event and the client makes a UI which fills up the whole screen. If the remote is deleted, the event isn’t sent and the gui isnt made.
Yes, I understood that. But what is the reason why you need to blind the player? What is the player not supposed to see? Are they not supposed to see another player’s actions?
theres like a block, which they shouldn’t see.
The server makes the block become visible and invisible between intervals. when it becomes visible, the client event is sent, and then if the block is in the player’s viewport, then the client creates a gui to be blinded.
This may be a dumb question, but if the block isn’t supposed to be seen, why do you make it visible? Is it supposed to be seen by some people and not by others?