I’ve tested it in studio and ClickDetectors detect clicks in parts that have .95 transparency or less. Parts with transparency of .96 to 1 do not detect clicks.
This is new, will it be permanent?
I bet it’s something like “> .95”
1 Like
I remember this behavior from 2012. Hasn’t changed.
1 Like
@osiris
Yeah. Anything greater than .95.
1 Like
Can you send a place link or code sample with the problem in question?
There’s been a minor change recently but at least in this example place:
clickdetectors are working. There are transparent and semi-transparent blocks in this place, and clicking on them will update the billboard on the right.
1 Like
Repro: Parts with ClickDetectors and CanCollide = false and Transparency > .95 don’t show mouse hover or register mouse clicks.
Do you have FE enabled?
1 Like
Sorry, I edited my post and left out part of the explanation. I CAN get the zero, half and full messages, but there is another part called ‘flusher’ that is floating on the left side of the zero transparency block that I’m not getting a message from. Click on flusher in the explorer to highlight it so you’ll know where to click. Flusher is set to CanCollide = false and Transparent 1.The pointer doesn’t change when it’s hovering over flusher and it isn’t printing anything when I click in that area. If I set the transparency to .95 or less, or set CanCollide = true then the pointer changes when hovering over it an it prints when clicked.
1 Like
Yes, in my published game I have FE on but not in the repro place I uploaded. They both exhibit this behavior.
1 Like
RE:
I see the inconsistent behaviour when CanCollide is disabled.
I’ll take a look at this and let you know when the fix is up.
And just checking, this was working as of a few weeks ago?
2 Likes
Yes. I rebuilt my place in early january and it was working when I moved everything over to the new build. I know because I tested everything at that time. I don’t know exactly when it stopped working, but the first time I noticed any comments about it was the same day I started this thread.
I’ve already remedied it and everything is working now, so it’s not a big issue, I just thought it was something I should bring to attention in case this behavior was unintended.
1 Like
So , sorry, I’ve made a mistake. 
I just looked at a backup and the parts were set to CanCollide = true. I don’t recall changing them, but obviously I did at some point after testing it. Idk what to say, I’m an idiot sometimes.
1 Like
Bit of a delayed update, but the fix (clickdetectors behave consistently no matter what the transparency or CanCollide status) is in and going in the next player update this wednesday.
1 Like
hate to necropost but this is a problem again. using collisiongroups to get around it doesnt work, it seems that it checks if the humanoidrootpart can collide with the part.
edit: its not the humanoidrootpart collision group, its the default collision group. if you make a collisiongroup that collides with default but not others, and add things to others, you can work around this.
1 Like
A bit of a necrobump, but just for any future readers, it appears this bug was fixed recently of me posting this message.
1 Like
It seems the bug still occurs when parenting the click detector to models which contains parts with transparency > .95. Parenting a clickdetector to the same parts inside the model works.
1 Like