Addresses #36267
The drag now checks all the selected objects in the blueprint container
to see if they have the same `StartTime` and `Duration` as the dragged
note, and if so, adjust them accordingly.
---------
Co-authored-by: Bartłomiej Dach <dach.bartlomiej@gmail.com>
Before:
https://github.com/user-attachments/assets/d87bd7e3-37f8-4634-9e6a-5859d5bade57
After:
https://github.com/user-attachments/assets/4de940af-1e30-4266-9aac-5ccd12f38742
---
The title is convoluted but basically I'm angling to close
https://github.com/ppy/osu/issues/36705 with this.
The point is that on current `master`, the keyboard-hotkey-based toggles
on the left of the screen get disabled if you select a range of objects
which contains no addition samples. The report linked above finds this
annoying because it means you basically always need to add an addition
sound *first* and *then* pick a bank.
This is not necessary, and this commit changes the behaviour such that
the bank selection toggles are no longer blocked when you select a range
of objects without additions. Choosing an addition bank when there are
no additions still does nothing to the selected object, *but* adding a
sound *after* that bank preselection will use the preselected bank
rather than auto.
Closes https://github.com/ppy/osu/issues/36830.
This is a regression from https://github.com/ppy/osu/pull/36681.
Due to the aforementioned pull request's changes, rotating an object
that could not scale on the X or Y axis (due to having that dimension
zero) would trigger `CanScale{X,Y}` to change as said rotated object's
width or height became not zero. This in turn would cause `SelectionBox`
to *fully recreate* all of its handles and buttons, *including* the
rotation handle that initiated the rotation operation, therefore
dropping the ongoing rotation operation completely and leaving the
editor in a half-broken state.
The suggested solution here is to recreate handles more granularly to
prevent this from happening. (I've probably not improved it as much as I
could have, but this is as far as I'm willing to go for now unless
review finds it unpalatable.)
It was taking up way too much vertical space previously.
I'm using the same font specs that are in the new dropdown header, which
seem to work quite well. Negative padding because without it everything
is way too vertically sparse.
Why? I was looking at [this
discussion](https://github.com/ppy/osu/discussions/36708) and like "we
need to have SV visible here" but there's really not much room with all
this text in the way.
- [x] Depends on https://github.com/ppy/osu/pull/36741 for merge
conflict avoidance
RFC, cc @OliBomby
## [Adjust behaviour of automatic bank assignment during
placement](https://github.com/ppy/osu/commit/547f55e9b3ded668fe6e1c8865a2d625e64a2f45)
Diatribe time!
This is fallout of the discussion about auto bank in
https://github.com/ppy/osu/issues/36705.
Auto bank in lazer as written before this commit is confused. On stable,
auto bank is closer to "no bank", as in "go look up the current sample
timing point, get the bank of that, and use that". lazer has no timing
points anymore, but people still want auto bank. So what do?
Auto bank for normal samples is somewhat sane still. It only works
during placement, and will just copy the normal bank of the previous
object - if one exists. That said, one *might not* exist, but the
resulting object will still have its normal sample created with
`editorAutoBank: true`. That is largely cosmetic and without
consequences, but this commit fixes that.
Auto bank for *addition* samples, however... Hoo boy.
- For placed objects, auto bank means "take the normal sample, read its
bank, and use that". Simple enough, right?
- Hoooooowever. During placement, auto bank before this commit used to
mean "look at the *previous object*, check if it has an addition sound
and then use its bank, if not use *the previous object's* normal sample
and then use its bank" which is a completely different thing with its
own implications. Like, say, what happens if the previous object uses
the auto addition bank too? What should be copied over? Should it be the
notion of "auto bank" in that the addition bank should match the normal
bank, or should it be the literal bank that the previous object is
using?
This change attempts to define this unambiguously. "Auto additions bank"
means "the same bank as the normal bank of this object", full stop.
## [Do not touch sample toggle state if there are no selected
objects](https://github.com/ppy/osu/commit/052cde5987e48800ec68ab2528c7e0ce3140e6e0)
Fixes issue described in
https://github.com/ppy/osu/issues/36705#issuecomment-3953917163 wherein
opening a sample popover will disable addition bank toggles and toggle
off all addition samples.
---------
Co-authored-by: Dean Herbert <pe@ppy.sh>
The new ones added in this change don't play the UI sounds, likely
because they make it nigh impossible to actually hear what the gameplay
samples will sound like.
This removes the same sounds from the existing buttons to match.
- Below 20 custom sample sets, they are shown as ternary buttons.
- Above 20 custom sample sets, they are shown in a dropdown (yes there
are actual cases of this as I've been informed by the NAT; one example
being https://osu.ppy.sh/beatmapsets/1018061#osu/2197383)
As a bonus, to make determining what the heck is actually changing when
adjusting these controls, the full set of applicable sounds now plays on
adding/removing additions, changing their banks, as well as changing the
custom set (if any).
For now there are no user-facing controls to add the samples to the map
yourself, you have to know how to name the `.wav`s and edit-externally
them in yourself. *For now.*
Closes https://github.com/ppy/osu/issues/33393.
This is admittedly a half-assed diff. This was apparently "fixed" once
before, eons ago, in https://github.com/ppy/osu/pull/11032, but I'm not
sure whether it regressed, or where, because I don't want to bisect four
years back. (At that time `ControlPointInfo.ControlPointsChanged`
did not exist yet.)
Also there's the part where changes to control points do not undo or
redo (see https://github.com/ppy/osu/issues/31942), but I'm not touching
that *either*, because if I start touching that, then I will get yelled
at for not reviewing the 2.5k line PR that rewrites the entirety of
change handling in editor instead
(https://github.com/ppy/osu/pull/30314). I will attempt to get through
that mental block sometime within the year. Please do not rush me.
The cheap cop-out argument is that hooking this up to `ControlPointInfo`
specifically is probably "more efficient" anyway.
The normalization formula didn't handle the 180° boundary consistently,
and produced asymmetric results for top vs. bottom rotation points.
Changes made: replaced the angle normalization with symmetric normalization,
and forced 180º to be the displayed angle across all rotation points.
I'm not sure why this condition was written this obtusely, but
importantly it was also wrong. It fires when the selection contains
multiple items and only some are removed from it, like when
ctrl-click-unselecting an item from a multiple selection.
Requested too many times to count.
I'm not sure what to do about the code quality of this. It's a bit weird
that there's no way to check the current composition tool from a higher
level.
Also it was discussed IRL that there should be some kind of hinting that
existing notes will be deleted when they are hovered, but I'm not sure
how well this will work in normal mapping flows, since it will display
even in cases that users aren't intending to delete an object. Still
willing to explore this direction though (it's just non-trivial to
implement so I haven't yet).
Closes https://github.com/ppy/osu/issues/28791.
The reason why nudging was not changing hyperdash state in catch was
that `EditorBeatmap.Update()` was not being called on the objects that
were being modified, therefore postprocessing was not performed,
therefore hyperdash state was not being recomputed.
Looking at the usage sites of `EditorBeatmap.PerformOnSelection()`,
about two-thirds of callers called `Update()` themselves on the objects
they mutated, and the rest didn't. I'd say that's the failure of the
abstraction and it should be `PerformOnSelection()`'s responsibility to
call `Update()` there. Yes in some of the cases here this will cause
extraneous calls that weren't done before, but the method is already
heavily disclaimed as 'expensive', so I'd say usability should come
first.
Closes https://github.com/ppy/osu/issues/31915.
Reproduction of aforementioned issue requires 1280x720 resolution, which
should also be a good way to confirm that this does anything.
To me this is also equal-parts-bugfix, equal-parts-code-quality PR,
because tell me: what on earth was this code ever doing at
`ComposeBlueprintContainer` level? Nudging by one playfield-space-unit
doesn't even *make sense* in something like taiko or mania.
Closes https://github.com/ppy/osu/issues/31909.
Previously: https://github.com/ppy/osu/pull/30062.
Happening because of rounding errors - in this case the beat index
pre-flooring was something like a 0.003 off of a full beat, which would
get floored down rather than rounded up which created the discrepancy.
But also we don't want to round *too* far, which is why this
frankenstein solution has to exist I think. This is probably all
exacerbated by stable not handling decimal control point start times.
Would add tests if not for the fact that this is like extremely annoying
to test.