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).
- Actually shows scores rather than playlist aggregates (which are
useful... in playlists, where there is more than one item)
- Actually allows scores to be shown by clicking on them
- Doesn't completely break down visually on smaller window sizes
The general appearance is not as polished as the old one in details but
I wanted something quick that we can get out by next weekend.
Also includes the naive method of refetching scores once a new top 50
score is detected. I can add a stagger if required.
At this point its primary usage is the daily challenge event feed, but
the leaderboard will be using this too shortly.
Because the playlists results screen that exists in `master` is
hard-coupled to showing the *local user's* best result on a given
playlist by way of hard-coupling itself to the relevant API request,
allowing show of *arbitrary* score by ID requires a whole bunch of
subclassery as things stand. Oh well.
Class naming is... best effort, due to the above.
With this new order, the logo can be easily moved to display in front of the footer in `SongSelectV2` without breaking experience when footer-based overlays are present. Such overlays (i.e. mod select overlay) will also be dimmed alongside the current screen when a game-wide overlay is open (e.g. settings).
I thought this was already being handled, but it turns out that changing
sort mode (and potentially other operations) could break the depth of
display of panels due to pooling and what not.
This ensures consistency and also employs @bdach's suggestion of
reversing the depth above and below the current selection for a better
visual effect.
As discussed in https://github.com/ppy/osu/discussions/28599.
I think this feels better overall, and would like to apply the change
before other design changes to the carousel.
This is the secondary cause of https://github.com/ppy/osu/issues/28577,
because you could do the following:
- Have a break autogenerate itself
- Adjust either end of it to make it mark itself as manually-adjusted
- Remove all objects before or after said break
to end up in a state wherein there are no objects before or after a
break.
The direct fix is still correct because it is still technically possible
to end up in a state wherein a break is before or after all objects
(obvious one is manual `.osu` editing), but this behaviour is also
undesirable for the autogeneration logic.
Regressed in https://github.com/ppy/osu/pull/28399.
To reproduce, enter a playlist that has an item with a rate-changing mod
(rather than create it yourself).
This is happening because `APIRuleset` has `CreateInstance()`
unimplemented:
b4cefe0cc2/osu.Game/Online/API/Requests/Responses/APIBeatmap.cs (L159)
and only triggers when the playlist items in question originate from
web.
This is why it is bad to have interface implementations throw outside of
maybe mock implementations for tests. `CreateInstance()` is a scourge
elsewhere in general, we need way less of it in the codebase (because
while convenient, it's also problematic to implement in online contexts,
and also expensive because reflection).
Closes https://github.com/ppy/osu/issues/6842.
This is a rather barebones implementation, just to get this in place
somehow at least. The logic is simple - 50% health or above shows pass
layer, anything below shows fail layer.
This does not match stable logic all across the board because I have
no idea how to package that. Stable defines "passing" in like fifty
ways:
- in mania it's >80% HP
(bb57924c15/osu!/GameModes/Play/Rulesets/Mania/RulesetMania.cs#L333-L336)
- in taiko it's >80% *accuracy*
(bb57924c15/osu!/GameModes/Play/Rulesets/Taiko/RulesetTaiko.cs#L486-L492)
- there's also the part where "geki additions" will unconditionally set
passing state
(bb57924c15/osu!/GameModes/Play/Player.cs#L3561-L3564)
- and also the part where at the end of the map, the final passing state
is determined by checking whether the user passed more sections than
failed
(bb57924c15/osu!/GameModes/Play/Player.cs#L3320)
The biggest issues of these are probably the first two, and they can
*probably* be fixed, but would require a new member on `Ruleset` and I'm
not sure how to make one look, so I'm not doing that at this time
pending collection of ideas on how to do that.
This was reported in https://github.com/ppy/osu/pull/28474, albeit the
code changes proposed there did not fix the issue at all.
See 8b6385f7d0 for demonstration of the
crash scenario. Basically what is happening there is:
- The starting premise is that there is a spinner placement active.
- At this time, a drag selection is started via the timeline.
- Once the drag selection finds at least one suitable object to select,
it mutates `SelectedItems`.
- When selection changes for any reason, the `HitObjectComposer`
decides to switch to the "select" tool, regardless of why
the selection changed.
- Changing the active tool causes the current placement - if any -
to be committed, which mutates the beatmap.
- Back at the drag box selection code, this causes a "collection
modified when enumerating" exception.
The proposed fix here is to eagerly commit active placement - if any -
when drag selection is initiated via the timeline, which avoids this
issue. This also appears to vaguely match stable behaviour and is sort
of consistent with the logic of committing any outstanding changes upon
switching to the selection tool.
This sort of thing has been showing up on flyte designs more and more
so I want to start using it more over that rather ugly "overlined" text
that's there on multiplayer screens right now.
The point is to apply the transitions against a container that's inside of `ScreenFooterButton`, because the `ScreenFooterButton` drawable's position is being controlled by the flow container it's contained within, and we cannot apply the transitions on it directly.
Closes https://github.com/ppy/osu/issues/25426.
Different approach to prior ones, this just disables the relevant
actions when something related to save/export is going on. Still ends up
being convoluted because many things you wouldn't expect to touch save
do touch save, so it's not just a concern between export and save
specifically.
Closes https://github.com/ppy/osu/issues/28369.
The reporter of the issue was incorrect; it's not the beat snap grid
that is causing the problem, it's something far stupider than that.
When the current selection changes,
`EditorSelectionHandler.UpdateTernaryStates()` is supposed to update the
state of ternary bindables to reflect the reality of the current
selection. This in turn will fire bindable change callbacks for said
ternary toggles, which heavily use `EditorBeatmap.PerformOnSelection()`.
The thing about that method is that it will attempt to check whether any
changes were actually made to avoid producing empty undo states, *but*
to do this, it must *serialise out the entire beatmap to a stream* and
then *binary equality check that* to determine whether any changes were
actually made:
7b14c77e43/osu.Game/Screens/Edit/EditorChangeHandler.cs (L65-L69)
As goes without saying, this is very expensive and unnecessary, which
leads to stuff like keeping a selection box active while a taiko beatmap
is playing under it dog slow. So to attempt to mitigate that, add
precondition checks to every single ternary callback of this sort to
avoid this serialisation overhead.
And yes, those precondition checks use linq, and that is *still* faster
than not having them.
I thought I had fixed this already once but it still looks broken.
Basically when hovering over main menu buttons every now and then it
will look like their backgrounds are not covering their entire width
when they expand.
The removed X position set looks wrong to me when inspecting the draw
visualiser with the element because the element looks to be off centre
horizontally, and removing it fixes that.
Not only is this simpler, but it also is more correct (for explanation
why, try holding both shift keys while dragging, and just releasing one
of them - the previous code would briefly turn aspect ratio off).
When shear factors differ between components that are close to each other (`BackButtonV2` and `ScreenFooterButton` in this case), they look completely ugly.
If the API login (and thus user set) completed between `load` and
`LoadComplete`, the re-fetch on user change would not yet be hooked up,
causing an incorrect default background to be used instead.
Of note, moving this out of async load doesn't really affect load
performance as the bulk of the load operation is already scheduled and
`LoadComponentAsync`ed anyway
Closes https://github.com/ppy/osu/issues/21794.
I'm not actually super sure as to what the exact mode of failure is
here, but it's 99% to do with working beatmap cache invalidation. Likely
this can be even considered as another case of
https://github.com/ppy/osu/issues/21357, but because this is a one-liner
"fix," I'm PRing it anyways.
The issue is confusing to understand when working with the swap scenario
given in the issue, but it's a little easier to understand when
performing the following:
1. Have a beatmap set with 2 difficulties. Let's call them "A" and "B".
2. From song select, without ever exiting to main menu, edit "A". Change
the difficulty name to "AA". Save and exit back to song select; do
not exit out to main menu.
3. From song select, edit "B". Change the difficulty name to "BB". Save
and exit back to song select.
4. The difficulty names will be "A" and "BB".
Basically what I *think* is causing this, is the fact that even though
editor invalidates the working beatmap by refetching it afresh on exit,
song select is blissfully unaware of this, and continues working with
its own `BeatmapInfo` instances which have backlinks to
`BeatmapSetInfo`.
When editing the first of the two difficulties and then the second,
the editing of the first one only invalidates the first one rather than
the entire set, and the second difficulty continues to have a stale
reference to the first one via the beatmap set, and as such ends up
overwriting the changes from the first save when passed into the editor
and modified again.
Closes https://github.com/ppy/osu/issues/22783.
If the difficulty being edited has unsaved changes, the editor exit flow
would prompt for save *after* the deletion method has run. This is
undesirable from a UX standpoint, and also leaves the user in a broken
state.
Thus, just fake an update of the last saved hash of the beatmap to fool
the editor into thinking that it's not dirty, so that the exit flow will
not show a save dialog.
Closes https://github.com/ppy/osu/issues/24274.
Bit of an ad-hoc resolution but maybe fine? This basically proposes to
bypass the problem described in the issue by just not showing tick hits
at all on the distribution graph.
Closes https://github.com/ppy/osu/issues/25633.
The reason why that particular beatmap did not have a double skip
on stable is here:
e53980dd76/osu!/GameModes/Play/Player.cs#L1761-L1770
The particular place of interest is the `leadInTime < 10000` check.
If `leadInTime < 10000`, then `leadIn == leadInTime`, and it turns out
that `AudioEngine.Time` will always be more than or equal to `leadIn`,
because it's also the gameplay start time:
e53980dd76/osu!/GameModes/Play/Player.cs#L2765
This essentially means that if the `leadInTime` is less than 10000,
that particular check is just dead. So a double skip can only occur
if the gameplay starts at time -10000 or earlier due to the storyboard.
