PC Info: Windows 10
Date First Experienced: 01/18/2024 9:42 AM
Date Last Experienced: Current
Video Showcasing This Issue:
Brief Explanation
When putting a ClickDetector inside of a Model/Folder and turning CanCollide off inside of any of the parts present inside, and then making that part transparent, ClickDetector will no longer show up, expected behavior is suppost to be if CanQuery is off, ClickDetector stops showing up, instead of CanCollide.
Reproduction Steps
Open up Roblox Studio And Insert 2 Parts
Group The Parts
Insert ClickDetector Into The Group
Insert A Script Into The Group And Put The Code From The Last Dropdown Into The Script
Turn Off CanCollide For Both (Or One Part) (And Anchor So It Doesn’t Fall)
local Visible = true
function ChangeVisiblity(Number)
for _, Part in pairs(script.Parent:GetChildren()) do
if Part:IsA("BasePart") then
Part.Transparency = Number
end
end
end
script.Parent.ClickDetector.MouseClick:Connect(function()
if Visible then
ChangeVisiblity(1)
else
ChangeVisiblity(0)
end
Visible = not Visible
end)
If you want a ClickDetector to be not selectable by the cursor, you can set it to a Collision Group that can’t collide with the Default collision group.
The current behaviour seems intended and changing it might break games
Specifically, Transparency > 0.95 non-collidable parts are ignored by ClickDetector / DragDetector unless the ClickDetector / DragDetector is directly underneath the part (LocalTransparencyModifier is not taken into account, so the actual visual transparency is not relevant, only the Transparency proprerty)
If you want to understand the behavior, an engineer many years ago tried to make it so you could click ClickDetectors through transparent non-collidable things. They ignored the transparent non-collidable things, but added a special case to still include things with DragDetectors under them. However, they accidentally forgot about the case of a Model/Folder with a DragDetector under it and ignored the intended click targets in that case.
Consider that the intended behavior.
I agree that the behavior is messy and probably not desirable but there’s no way we could change it at this point without breaking a considerable number of experiences so you’ll have to adjust whatever you were doing to work with this behavior.
This is pretty awful, I wish it was fixed beforehand so it wouldn’t have been involved within experiences, wasn’t looking forward to having to add a click detector every individual part for a workaround, wish there was some sort of detector setting that could be changes to both but automatically set to said original behavior so it doesn’t break games.
Unfortunately this is a case where it’s hard to even have a setting, because the filter is used to decide which ClickDetector is supposed to sink the input in the first place: Before you know which ClickDetector is going to be sinking the input you don’t know which ClickDetector’s setting to use during the search.
Eh, fair enough I guess, it might tie in due to the unfunctionality I’ve seen within the replies of why nothing is possible to redo, but I’m just salty due to the issue.
