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.
