Closes https://github.com/ppy/osu/issues/29492.
I'm not immediately sure why this happened, but some old locally
modified beatmaps in my local realm database have a `BeatDivisor` of 0
stored, which is then passed to
`BindableBeatDivisor.SetArbitraryDivisor()`, which then blows up.
To stop this from happening, just refuse to use values outside of a sane
range.
- On entering the screen, the timing point active at the current instant
of the map is selected. This is the *only* time where the selected
point is changed automatically for the user.
- The ongoing automatic tracking of the relevant point after the initial
selection is *gone*. Even knowing the fact that it was supposed to
track the supposedly relevant "last selected type" of control point,
I always found the tracking to be fairly arbitrary in how it works.
Removing this behaviour also incidentally fixes
https://github.com/ppy/osu/issues/23147.
In its stead, to indicate which timing groups are having an effect,
they receive an indicator line on the left (coloured using the
relevant control points' representing colours), as well as a slight
highlight effect.
- If there is no control point selected, the table will autoscroll to
the latest timing group, unless the user manually scrolled the table
before.
- If the selected control point changes, the table will autoscroll to
the newly selected point, *regardless* of whether the user manually
scrolled the table before.
- A new button is added which permits the user to select the latest
timing group. As per the point above, this will autoscroll the user
to that group at the same time.
This is in addition to Shift + Right-click.
I thik middle mouse feels more natural and is a good permanent solution
to this issue.
Note that this also *allows triggering the context menu from placement
mode*. Until now it's done nothing. This may be annoying to users with
muscle memory but I want to make the change and harvest feedback. I
think showing the context menu is more correct behaviour (although
arguably it should return to placement mode on dismiss?).
Closes https://github.com/ppy/osu/issues/28916.
The previous behaviour *may* have been intended, but it was honestly
quite baffling. This seems like a saner variant.
Closes https://github.com/ppy/osu/issues/28983.
While the direct cause of this is most likely mouse confine in
full-screen, it shouldn't/can't really be disabled just for this,
and I also get this on linux in *windowed* mode.
In checking other apps, adding some tolerance to this sort of
drag-scroll behaviour seems like a sane UX improvement anyways.
Closes https://github.com/ppy/osu/issues/28938.
This is related to reloading the composer on timing point changes in
scrolling rulesets. The lack of unsubscription from this would cause
blueprints to be created for disposed composers via the
`hitObjectAdded()` flow.
The following line looks as if a sync load should be forced on a newly
created placement blueprint:
da4d37c4ad/osu.Game/Screens/Edit/Compose/Components/ComposeBlueprintContainer.cs (L364)
however, it is not the case if the parent
(`placementBlueprintContainer`) is disposed, which it would be in this
case. Therefore, the blueprint stays `NotLoaded` rather than `Ready`,
therefore it never receives its DI dependencies, therefore it dies on
an `EditorBeatmap` nullref.
Bookmarks don't show on real beatmaps, but they do show in test scenes
(namely `TestSceneEditorSummaryTimeline`).
Also does some more changes to adjust the markers to the latest updates
to other markers.
Before I go with a hammer to redesign these, I want to remove stuff that
does nothing first.
Hard-breaks API to allow rulesets to specify an enumerable of custom
sections rather than two specific weird ones.
For specific rulesets:
- osu!:
- Stack leniency slider merged into difficulty section.
- osu!taiko:
- Approach rate and circle size sliders removed.
- Colours section removed.
- osu!catch:
- No functional changes.
- osu!mania:
- Special style toggle merged into difficulty section.
- Colours section removed.
This removes the BPM display, which is commonly cited to have
no functional purpose by users, and reduces the height of the bottom bar
in exchange for more space for the playfield.
Touched on in https://github.com/ppy/osu/discussions/28581.
After a bit more usage of the editor I do agree with this and think that
making the fades a bit more gentle helps a lot.
Closes https://github.com/ppy/osu/issues/28750.
Yes this is not the perfect change to fix this (which would probably be
some framework change to take bounds of the parenting input manager into
account). I really do not want to go there and would like to just fix
this locally and move on. Due to the game-wide scaling container this
sorta works for any resolution anyhow.
Closes https://github.com/ppy/osu/issues/28741.
Regressed in a7b066f3ee.
The intent of the original change there was to ensure that addition
banks being set will put the ternary state toggles in indeterminate
state (to at least provide a visual indication that the selection does
not use a single bank). This would previously not be the case due to
the use of `.All()` in the original condition (a single object/node
was considered to have a bank enabled if and only if *all* samples
within it used it). However the attempt to fix that via switching
to `Any()` was not correct.
The logic used in the offending commit operates on extracted `Samples`
and `NodeSamples` from the selection, and would consider the ternary
toggle:
- fully off if none of the samples/node samples contained a sample with
the given bank,
- indeterminate if the some of the samples/node samples contained a
sample with the given bank,
- fully on if at least one sample from every samples/node samples
contained a sample with the given bank.
This is a *two-tiered* process, as in first a *binary* on/off state is
extracted from each object's samples/node samples, and *then* a ternary
state is extracted from all objects/nodes. This is insufficient to
express the *desired* behaviour, which is that the toggle should be:
- fully off if *none of the individual samples in the selection* use
the given bank,
- indeterminate if *at least one individual sample in the selection*
uses the given bank,
- fully on if *all individual samples in the selection* use the given
bank.
The second wording is flattened, and no longer tries to consider "nodes"
or "objects", it just looks at all of the samples in the selection
without concern as to whether they're from separate objects/nodes
or not.
To explain why this discrepancy caused the bug, consider a single object
with a `soft` normal bank and `drum` addition bank. Selecting the object
would cause a ternary button state update; as per the incorrect logic,
there were two samples on the object and each had its own separate
banks, so two ternary toggles would have their state set to `True`
(rather than the correct `Indeterminate`), thus triggering a bindable
feedback loop that would cause one of these banks to win and actually
overwrite the other.
Note that the addition indeterminate state computation *still* needs
to do the two-tiered process, because there it actually makes sense (for
a selection to have an addition fully on rather than indeterminate,
*every* object/node *must* contain that addition).
