As I look into re-implementing the ability to choose combo colour for an
object (also known as "colourhax") from the editor UI, I stumble upon
these wretched ternary items again and sigh a deep sigh of annoyance.
The structure is overly rigid. `TernaryItem` does nothing that
`DrawableTernaryItem` couldn't, except make it more annoying to add
specific sub-variants of `DrawableTernaryItem` that could do more
things.
Yes you could sprinkle more levels of virtuals to
`CreateDrawableButton()` or something, but after all, as Saint Exupéry
says, "perfection is finally attained not when there is no longer
anything to add, but when there is no longer anything to take away."
So I'm leaning for taking one step towards perfection.
It proved to be too difficult to deal with the flow that clears user
states on stopping the watching of global presence updates. It's not
helped in the least that friends are updated via the API, so there's a
third flow to consider (and the timings therein - both server-spectator
and friends are updated concurrently).
Simplest is to separate the friends flow, though this does mean some
logic and state duplication.
No issue thread for this, was pointed out internally:
https://discord.com/channels/90072389919997952/1259818301517725707/1316604605777444905
Due to the custom setup that editor has with its nested
"screens-that-aren't-screens", the logic that selects the closest
timing point to the current time would only fire on the first open of
the screen. Seems like a good idea to have it fire every time instead.
No issue thread for this again. Reported internally on discord:
https://discord.com/channels/90072389919997952/1259818301517725707/1320420768814727229
Placing this logic in the beatmap processor, as a post-processing step,
means that the new combo force won't be visible until a placement has
been committed. That can be seen as subpar, but I tried putting this
logic in the placement and it sucked anyway:
- While the combo number was correct, the colour looked off, because it
would use the same combo colour as the already-placed objects after
said break, which would only cycle to the next, correct one on
placement
- Not all scenarios can be handled in the placement. Refer to one of the
test cases added in the preceding commit, wherein two objects are
placed far apart from each other, and an automated break is inserted
between them - the placement has no practical way of knowing whether
it's going to have a break inserted automatically before it or not.
I managed to do this by accident three times today while testing using
the dashboard display, so it's time to action on it.
Touched on in
https://github.com/ppy/osu/discussions/30740#discussioncomment-11345996.
Was also mentioned recently in discord or another discussion explicitly
but I can't find that.
Originally this was an intentional choice (see
https://github.com/ppy/osu/pull/18088) when these controls were more
transparent and didn't for a solid toolbox area.
But this is no longer the case, so for now let's always block scroll to
match user expectations.
Closes#31262.
Fixes the main part of https://github.com/ppy/osu/issues/31144.
Support for selecting a video will come later.
Making this work was an absolutely awful time full of dealing with
delightfully kooky issues, and yielded in a very weird-shaped
contraption. There is at least one issue remaining wherein storyboard
videos do not actually display until the track is started in editor, but
that is 99% a framework issue and I do not currently have the mental
fortitude to diagnose further.
Would close https://github.com/ppy/osu/issues/31312.
Not super happy with the performance overhead of this, but this is
already a heuristic-based implementation to avoid every-frame
`.ChildrenOfType<>()` calls or similar, so not super sure how to do
better. The `Array.Contains()` check stands out in profiling, but
without it the indicators can collapse *too* eagerly sometimes.
- Closes https://github.com/ppy/osu/issues/21189
- Supersedes / closes https://github.com/ppy/osu-framework/pull/5627
- Supersedes / closes https://github.com/ppy/osu/pull/22235
The reason why I opted for a complete rewrite rather than a revival of
that aforementioned pull series is that it always felt quite gross to me
to be pulling framework's audio subsystem into the task of reading ID3
tags, and I also partially don't believe that BASS is *good* at reading
ID3 tags. Meanwhile, we already have another library pulled in that is
*explicitly* intended for reading multimedia metadata, and using it
does not require framework changes. (And it was pulled in explicitly for
use in the editor verify tab as well.)
The hard and dumb part of this diff is hacking the gibson such that
the metadata section on setup screen actually *updates itself*
after the resources section is done doing its thing. After significant
gnashing of teeth I just did the bare minimum to make work by caching
a common parent and exposing an `Action?` on it. If anyone has better
ideas, I'm all ears.
RFC. This closes https://github.com/ppy/osu/issues/31186.
To explain why: The issue occurs on
https://osu.ppy.sh/beatmapsets/594828#osu/1258033, specifically on the
slider at time 128604. The failure site is
fa0d2f4af2/osu.Game.Rulesets.Osu/Edit/Blueprints/Sliders/SliderCircleOverlay.cs (L65-L66)
wherein `LastRepeat` is `null`, even though the slider's `RepeatCount`
is 1 and thus `SpanCount` is 2.
In this case, `SliderEventGenerator` is given a non-zero `tickDistance`
but a zero `length`. The former is clamped to the latter:
fa0d2f4af2/osu.Game/Rulesets/Objects/SliderEventGenerator.cs (L34)
Because of this, a whole block of code pertaining to tick generation
gets turned off, because of zero tick spacing - however, that block also
includes within it *repeat* generation, for seemingly very little reason
whatsoever:
fa0d2f4af2/osu.Game/Rulesets/Objects/SliderEventGenerator.cs (L47-L77)
While a zero tick distance would indeed cause `generateTicks()` to loop
forever, it should have absolutely no effect on repeats.
While this *is* ultimately an aspire-tier bug caused by people pushing
things to limits, I do believe that in this case a fix is warranted
because of how hard the current behaviour violates invariants. I do not
like the possibility of having a slider with multiple spans and no
repeats.
Closes https://github.com/ppy/osu/issues/31290.
Tend to agree that this is a good idea for gameplay test at least. Not
sure about other similar interactions like exiting - I don't think it
matters what's done in those cases, because for exiting timing is in no
way key, so I just applied this locally to gameplay test.
This was very weird on master - `ModDisplay` applied a fade-in on the
`iconsContainer` that lasted 1000ms, and `HUDOverlay` would stack
another 200ms fade-in on top if a replay was loaded. Moving that first
fadeout to a higher level broke fade-out because transforms got
overwritten.
This reverts commit c0b6e784a5.
The change affects editor and other stuff and I'm not sure it's correct.
It's not like client needs to match the appearance really. It already
doesn't in many places.
Reported at https://osu.ppy.sh/community/forums/topics/2015478?n=1.
Would you believe it that this button that has been there for literal
years never did anything?
Implemented at a per-beatmap level. Also additionally added to context
menu (at @peppy's suggestion), and also copy reworded from "Delete from
unplayed" to "Mark as played" because double negation hurt my tiny
brain.
I actually thought things were bugged with the previous display method,
since the hinting was very similar to the hover colour/state.
I've adjusted this to hopefully give users a better idea of what this is
intending to show them.
Closes https://github.com/ppy/osu/issues/31098.
Low effort fix because it was already half broken. The test was testing
in isolation but in actual editor usage it wasn't working as expected.
This brings it down to be in line with the flowing elements that usually
do their best to not get in the way.
Decided against putting it in the `HUDOverlay` flow for simplicity. It
will work fine until it doesn't.
