Replace hit objects when placing at same time in editor

[Hiviexd]

Matches stable and significantly improves UX when mapping. In addition, current behavior makes it too easy to place stacked objects which is something we should not encourage.

[bdach]

I want to somewhat prioritise this because it is a recurrent (stable) editor user complaint.

That said, I'm uncertain of some of the decisions made here.

• The new behaviour is applied unconditionally without a toggle. That's probably fine by me, but I'm not sure that everyone else would agree.
• More importantly, there is zero visual guidance indicating that an object will get deleted via this flow. Unless you're accustomed to stable editor and know how this works, there's no way for you to know what's going to happen. I'd see either a red tint, a red border, or a fade-out effect applied to the object that is getting replaced via this flow (both on the playfield, and on the timeline).

@peppy do you have anything to say on either of the above points?

There's not much to look at here code-wise. I left one comment but it's of little weight.

[peppy]

@bdach I'm okay with both points. I think it's expected behaviour for rulesets where placing multiple notes at the same time value is not valid.

[bdach]

Self-resolved review comment and added a test for mania behaviour because there wasn't one.

@peppy Your comment above is worded a bit ambiguously but I'm interpreting it such that you're fine with how this works as written. To that end I'll leave this hanging for a bit and merge eventually just in case I interpreted wrong.

[peppy]

is good

[cihe13375]

I understand that this change logically makes sense, but I do sometimes "exploit" the old behavior, e.g. in making hitsound difficulties. In the example below, each location on the playfield represents a type of sample (whistle, cymbal, kick, snare), and there are dedicated tools for assigning samples based on locations and copying them to other difficulties.

Also I am not sure if 2ms leniency is enough. In theory two notes at the same tick can be at most 3.99999999999999ms apart (since unsnaps <2ms are considered "negligible").

[bdach]

I understand that this change logically makes sense, but I do sometimes "exploit" the old behavior, e.g. in making hitsound difficulties. In the example below, each location on the playfield represents a type of sample (whistle, cymbal, kick, snare), and there are dedicated tools for assigning samples based on locations and copying them to other difficulties.

This is so hacky I'm not even really wanting to entertain it. Hopefully we can provide a flow for this that's not made of loose sticks and string.

Also I am not sure if 2ms leniency is enough. In theory two notes at the same tick can be at most 3.99999999999999ms apart (since unsnaps <2ms are considered "negligible").

osu/osu.Game/Rulesets/Edit/Checks/CheckUnsnappedObjects.cs

Lines 58 to 61 in fd6cf68

	if (Math.Abs(unsnap) >= UNSNAP_MS_THRESHOLD)
	yield return new IssueTemplateLargeUnsnap(this).Create(hitobject, unsnap, time, postfix);
	else if (Math.Abs(unsnap) >= 1)
	yield return new IssueTemplateSmallUnsnap(this).Create(hitobject, unsnap, time, postfix);

osu/osu.Game/Rulesets/Edit/Checks/CheckUnsnappedObjects.cs

Line 14 in fd6cf68

public const double UNSNAP_MS_THRESHOLD = 2;

2 seems correct / sufficient to me here given that placement tools are going to be using the same snapping that the above code checks for snapping tolerance, with no room for perturbations.

[peppy]

Agree with reply here. No changes required.