I am using ClickDetectors due to the events being able to be listened to on the server.
I am proposing that ClickDetector.Button1Down, ClickDetector.Button1Up, ClickDetector.Button2Down, ClickDetector.Button2Up be added to the API.
Currently there are only Click and Hover APIs for ClickDetectors with really weird event names (MouseClick, RightMouseClick, etc) . What made me want to suggest this is the fact that I cannot tell if someone is holding down their mouse button over the button without using RemoteEvents, which I do not want to do.
I feel safer with ClickDetectors because script kiddies couldn’t abuse them as much. I haven’t seen anyone who is able to manipulate a ClickDetector on the client.
What are you afraid of them manipulating? You can add server side sanity checks to your remote events.
I would recommend making a system with a BillboardGui (more friendly than SurfaceGuis to mobile if you are going for that market)
Click detectors seem to be on their way out, partially because you loose customization with the mouse, and something about that feels clunky.
If they’re exploiting, it’s best to assume they can edit anything locally and fire anything they can see locally. All you really need though is just sanity checks on the server.
Anything that originates from the client is inherently unsafe, that includes ClickDetector clicks. There is data that’s transferred over the wire from the client to the server when the user clicks. Anything that’s sent over the network can be faked by exploiters.
It’s possible that specific exploits may not have first party support for automating ClickDetectors, but that doesn’t mean that they are actually safe from exploits. It’s generally best to follow the mantra “if it’s from the client, it is unsafe unless proven otherwise”.
This seems like sort of a hackish way around the issue. BillboardGui’s and SurfaceGui’s don’t use the same shape as the object like ClickDetectors do, and seeing as we have ClickDetectors (as well as them being updated relatively recently), they don’t seem to be going anywhere.
ClickDetectors, if they stay, should be the go-to way to handle user input on parts or models. If we have to resort to other methods to reach results on objects that ClickDetectors are intended to handle, what’s the point in keeping ClickDetectors?
This what the UserInputService is for. It is a more abstract service which contains better fundamentals for handling user inputs. Had it been added before ClickDetectors, we would have probably never had ClickDetectors in the first place.
Backwards compatibility. Features rarely get removed on Roblox because it would break games. The only feature I remember being completely removed was voxel terrain, but it was replaced with smooth terrain.
My post was in response to SurfaceGui/BillboardGui vs ClickDetectors. I don’t really think we should keep ClickDetectors because there’s better ways to go about things, but gui’s aren’t one of those better ways in my opinion.
I mean I know that, but I meant why not deprecate it if we’re expected to use gui’s to hack our way around getting more events.