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.
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.
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.
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.
