…all of them. Each one. This is Innnovation labs with no modifications other than a delete tool to get past the now broken doors and Filtering Enabled:
I cannot find any clickdetectors in that game that still fire when clicked.
Same goes for my other places, clicked events fail to fire there aswell.
Wasn’t just me. I fixed this my making a manual one.
ooooooooooooooooooooo
So that’s why when I enabled filtering all my buy buttons in the store stopped working?
While were talking about glitchy click events, I also cant get MouseButton1Click to fire inside of BillboardGuis Even if filtering is off.
While we’re at it, why does MouseButton1Down not fire inside of BillboardGuis at all?
Edit:
Oooh it must be a direct descendant of PlayGui. Damn.
All my guis stopped working, beside the shop shedletsky made a long time ago.
Any admins response? This is kinda a big issue.
I think your events are not disconnected, they’re just not firing. The issue is that ClickDetector events are not whitelisted, so they don’t get replicated back to the server.
You’re certainly correct there. So why are they not whitelisted?
Your certainly correct there. So why are they not whitelisted?[/quote]
Probably because nobody knew to whitelist them. Now they know. (or they are just pretending to be on)
“Your certainly correct there. So why are they not whitelisted?”
Why should they be whitelisted?
There is no reason that they should be whitelisted. It’s exactly like with GUIs with FilteringEnabled: You should listen to clicks on them from a LocalScript, as it is an inherently local event.
Or better yet use PlayerMouse::Button1Down/Click inside of your normal GUI code rather than a ClickDetector. The only reason that ClickDetectors exist is that there wasn’t a PlayerMouse at the time they were added.
There are reasons for whitelisting ClickDetectors.
-
Your proposed solution does not align with the function of ClickDetectors.
-
ClickDetectors serve as physical input events, not GUI events
-
They serve as a useful second-option for those who are not advanced enough at scripting to use remote events to do the same function
-
They change the cursor icon. This is the biggest reason to whitelist them. PlayerMouse.Icon doesn’t exist, so who is ever going to know if their mouse is hovering over a button that is clickable
So, mr. Stravant, I propose one of two short-term solutions to this problem:
[ul][li]enable PlayerMouse.Icon, and once again ignore the requests of developers who want backwards-compatibility[/li][/ul]
or
[ul][li]whitelist ClickDetector.MouseClick, and save everyone the trouble[/li][/ul]
Hang on there Stravant, Click Detectors are for use in physical bricks aswell. So if I want to use click detectors in bricks in my game I have to make a local script inside the starter gui, and then connect that local script to every single click detector in the place and then use remote functions to connect that local script to every single script in the place that would use a click detector.
Because that is completely impossible.
“2. ClickDetectors serve as physical input events, not GUI events”
This is sort of true, and sort of not. ClickDetectors are halfway between GUI interactions, and proper ContextActions. Really you should probably be using ContextActions for most things that you are using ClickDetectors for.
“3. They serve as a useful second-option for those who are not advanced enough at scripting to use remote events to do the same function”
If you are not “advanced enough” to handle the clicks on the client then it seems unlikely that you will be able to turn FilteringEnabled on in the first place.
“4. They change the cursor icon. This is the biggest reason to whitelist them. PlayerMouse.Icon doesn’t exist, so who is ever going to know if their mouse is hovering over a button that is clickable”
If you want the same behavior as before then you can still use ClickDetectors and listen to the clicks on the client. They are still usable. Also, this is a very bad line of reasoning, as your game should at least be giving some thought to working on Touch devices too, where there is no “hovering over” the ClickDetector.
But what reasons are there not to white list them? Do they pose a security vulnerability?
I really can’t understand why you are against whitelisting ClickDetectors.
People don’t like exploiters, but not everyone knows how to use RemoteEvents and RemoteFunctions and how to get around the obvious gaps (like this one) in FilteringEnabled’s usefulness.
I will give it further thought.
The main reason that I don’t like fixing it is that ClickDetectors are not a good solution to the problems that people are using them to solve. What people really want when they’re using ClickDetectors is context actions (that is, GUI interactable actions specific to the area that you’re currently / what you’re currently looking at).
On the other hand thinking about it there are quite a few cases where a game would otherwise work with FilteringEnabled on other than the fact that ClickDetectors don’t work.
I’ll discuss with some other people and let you know.
Click Detectors are player inputs, why would you not be listening locally?
The main question I have now is, why are ClickDetectors being referred to as “GUI elements?”
As far as I know, ClickDetectors are not graphical in nature?