Hold to draw a slider feature conflicts with expected behavior of placing a slider

[Judge1st]

Type

Game behaviour

Bug description

If cursor had any velocity at the moment when you tried to place a slider it will assume you're trying to use a drawing feature. This unexpected behavior obstructs normal slider placing, as even a little amount of movement in your cursor causes this to happen.
Instead it creates a small slider or doesn't create any slider at all, none of these are expected behavior for a single mouse button click.
Same applies when you hold left click just for a few ms longer even without any movement in your cursor.

Most optimal way to fix that would be adding minimal hold time (ex. 0.5s) required to activate drawing behavior, that would prevent it from triggering just by a single click.

Screenshots or videos

current lazer behavior:

osu._UJWWRekrVn.mp4

example of an expected behavior from stable:

osu._1v71SnndW4.mp4

Version

2024.1115.3

Logs

compressed-logs.zip

[bdach]

I dunno how we'd ever fix this. Aside from a toggle to turn off drawing mode.

[Judge1st]

This would be definitely a great solution if changing how it works isn't easily possible

[peppy]

I've never false-triggered this. You already need to exceed the drag lenience, which I think should cover false-drags. If it doesn't, then this is broken everywhere in the game.

[bdach]

yeah and yet nobody has complained about it for that entire year...

[Banana090]

I can confirm I have false triggered this a lot as well if you need more confirmation that something is clearly wrong. I am not an experienced mapper tho

[amateurre]

I encountered this issue several times while trying out the editor again after hearing the new changes. Confused me a lot of times which tilted me a bit cause it slowed me down.

If this is helpful, here's a clip taken from my recent mapping stream, where I made an entire guest difficulty in the lazer editor:
https://www.twitch.tv/amateurre/clip/SmilingHealthyWoodpeckerPanicBasket-r_G51zoSqwyCHg9P

There are more instances of this happening throughout the stream if you're interested in checking out the entire thing.

@bdach About the entire year thing, most mappers probably just give lazer editor a try every once in a while and go back to stable like I did. Last time I tried lazer editor was back in October 2022 and only just got back into it recently. Because of this, most changes and issues wont be noticed as immediately as with player stuff.

[peppy]

I guess the most i'd be willing to offer is a setting for those who have fumbly inputs.

But before that, we should check the code surrounding drag lenience. I raised concerns over this being based on native pixels, which means it gets smaller the larger your window is.

Users triggering this behaviour here may be running at very high resolutions.

[Judge1st]

I think it has nothing to do with screen resolution, for example video I recorded was done in a smaller window and my normal full screen is 1920x1080, which is standard resolution for lots of users. Setting to switch this behavior would be awesome, I talked to few other mappers and it seems like opinions on this are split, some people don't notice it while for others like me it slowing down mapping process and generally makes experience of using editor less comfortable.

[kongehund]

Some thoughts on the minimum hold time idea:

I think it could make sense to implement a time-based logic to drag lenience in the osu framework, in addition to pixels or distance traveled, similarly to how we have time logic for double-clicking.

Such time logic could be something along the lines of "A drag won't start before 75 milliseconds. If MouseUp is encountered before 75 milliseconds, it was not a drag, but a click", or similar.

I think the mappers who encounter this issue are the ones who have muscle-memory that makes them click and start their mouse movement at the same time (especially those with high mouse sensitivity), instead of clicking first, then moving, which may be the muscle memory for others. Having a drag be cancelled within a time-limit allows regular slider placement regardless of distance that the mouse traveled between MouseDown and MouseUp, and I think it's unlikely that mappers would genuinely need or want to create freehand sliders in that short of a timespan.

Assuming this was implemented in the framework as a general way to handle mouse movement, the only potential problems I can think of would be:

• Highlighting a small section of text, like a few letters, with a quick mouse stroke.
• Making small, quick adjustments to positions of Drawables in the map editor or skin editor, but I think users will understand pretty intuitively "I clicked too fast, so it registered as a click instead of a drag", and then without thinking about it, adjust by holding the click down for just a bit longer.