In the skin editor, right-clicking an object when holding it randomly teleports it

[snalgae]

Type

Game behaviour

Bug description

I was making a skin layout and I wanted to adjust an object's origin, but I right-clicked when I was still holding it which teleported it. I tested this with other objects and it teleports them too.
Also as I result I have two random healthbars in random places, one of which is not visible in the editor, but visible in gameplay, because I play on a widescreen monitor, is there a way to remove them?

Screenshots or videos

2024-01-20.18-07-36.mp4

Version

2024.114.0

Logs

compressed-logs.zip

[Gabixel]

Very strange. (Probably has something to do with how context menus work, but I'm not an expert yet).

Anyway, to fix your out-of-bounds problem with components, you can follow these (unintuitive) steps for the time being:

• CTRL-A to select all objects
• Hold again CTRL and click on each visible object so that you can deselect them, and do it until you get to the point where you are only keeping selected what is off the screen
• Delete the selected objects with Del — or move the object back to view by holding the desired arrow key (which is pretty slow to do)
• (You can also just export the skin and manually edit the JSON structure, but it's probably easier for tinkerers)

In the future, I imagine it can be improved by adding more selection methods (I can think of a dropdown option to "reverse" the current selection), or even adding a tree view (like on Figma, for example).

Here's a video of the steps:

2024-01-20.15-41-37.-.Trim.mp4

[Gabixel]

Also related: #12795

[Gabixel]

This is more of a question to the devs, but I think this is another scenario for ppy/osu-framework#6102? I can also reproduce this with the middle mouse button, therefore the context menu is irrelevant here

[frenzibyte]

This is more of a question to the devs, but I think this is another scenario for ppy/osu-framework#6102? I can also reproduce this with the middle mouse button, therefore the context menu is irrelevant here

Thought the same but turns out it was another part of the movement logic causing the issue (see #26661).