HandleAdornments deal inconsistently with under/overlying ClickDetectors

Description:

When a part with a ClickDetector is put over a HandleAdornment (with AlwaysOnTop = false), say ImageHandleAdornment, then all clickdetector events will function as expected apart from ClickDetector.MouseClick. This event will not trigger when the player is clicking on the area of the part that overlaps with the HandleAdornment behind it.

When a part with a ClickDetector is put underneath the ImageHandleAdornment, then all ClickDetector events will still trigger apart from MouseClick.


Expected behaviour:

The expected behaviour, in both cases, is that all events are treated consistently: either all events are blocked from executing or all events are passed through to the ClickDetector, MouseClick shouldn’t be the odd one out. Especially when the HandleAdornment is underneath the part in terms of view space, all events should be passed through. I would suggest to let all events pass through instead of blocking them, because this is most flexible for developers.


Repro file:

ImageHandleAdornment_ClickDetector_Bug_Repro.rbxl (13.5 KB)

There is some code in workspace.Part that prints the events of the clickdetector. Furthermore there are two ImageHandleAdornments in game.StarterGui with workspace.Part set as the Adornee, with different offsets.


Repro walkthrough - Part 1

Open the repro file and start “Play” mode. Subsequently, mouse-over and interact with the part in front of your character and watch the output for event messages of the ClickDetector.

Clicking on the outside area of the underlying ImageHandleAdornment will trigger the MouseClick event:

a3c9285f53daf4e66fc0f267b0fa08a191ebf679.jpg

Clicking on the inside area w.r.t. the underlying ImageHandleAdornment will not trigger the MouseClick event:

21e3aace7451f12e8e6c52941ec7d38cf154b4ac.jpg

Notice that all other events (MouseHoverEnter, MouseHoverLeave, RightMouseClick) have the expected functionality and therefore trigger output messages at the right moments, not just depending on whether you’re hovering over area covered by the underlying ImageHandleAdornment.


Repro walkthrough: Part 2

Continuing from the previous part, run the following code in the command bar:
game.StarterGui.White2.Visible = true

We now have the following situation:

e5c86ba749070607224e7e6ee68eebb37371663e.jpg

Try to interact with the brick through the ImageHandleAdornment (i.e. mouse-over and left/right-click on the area of the brick covered by the ImageHandleAdornment in front of it). All events still work apart from MouseClick.


Additional notes:

This bug occurs in any game and in Studio, 100% of the time, Studio version 0.288.0.118399 (but this has probably been this way ever since HandleAdornments were added). I’m on Windows 10 Pro, if that matters.

How did you find out this problem? HandleAdornments created by yourself or HandleAdornments used by studio?

I create ImageHandleAdornments myself and I happened to notice that once it covered / was underneath a brick with a clickdetector, it would have this inconsistent behaviour. It can cause issues when a player is trying to click on a part with clickdetector which has an ImageHandleAdornment behind it by coincident.

HandleAdornments are intended to be used as small draggers in studio. What do you use them for?

I need to have a lot of 3D-oriented textures on-screen that are not affected by lighting, that the player can possibly interact with by clicking on them (i.e. to change their color when they are clicked). The alternative is to use a lot of additional base parts and SurfaceGuis + ImageLabels, and I tried this, but it is way too performance-intensive for the amount of individual objects I want to display.

ImageHandleAdornments (and HandleAdornments in general) are not marked as internal classes on the wiki nor is it described that they shouldn’t be used for other purposes than draggers. Either way, they are usable in live servers, so the bug is still relevant in games where you can have dragger tools + bricks with clickdetectors.

EDIT: I’ve also seen other people use other handle adornments, such as LineHandleAdornments, to simulate bullet fire in a cheap way. They are used in more ways than just dragger tools because they are cheap to update.

Surfaceguis shouldn’t be significantly less performance intensive than Decals.

Sorry, I should have clarified that the “additional base parts” is where the performance impact comes from AFAIK. (Moving them around / resizing them) ImageHandleAdornments are quite a bit cheaper to update in size/position from what I can tell, because you can offset ImageHandleAdornments anywhere using its CFrame property (without moving the Adornee, you can set the handle adornment anywhere).

1 Like

We fixed this issue. Hopefully it will come out in a future release.

1 Like

Please check this, should be solved.

1 Like

Yep, it’s fixed, thanks :slight_smile:

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.