Reported via e-mails.
The web-side change that wasn't ported here is
https://github.com/ppy/osu-web/pull/11151. I wanted to port it at the
time but then ran into issues because this logic should *ideally* also
be applied to the beatmap set overlay leaderboards, but those are
hard-glued to `ScoreInfo`, cannot be easily weaned off it to use
`SoloScoreInfo` instead, and I did not want to make `ScoreInfo` even
more of a mess than it already is.
This time I'm just ignoring it and adding a TODO instead because I have
no confidence I will get review eyes on any refactor of the beatmap set
overlay. All I'll say that such refactors would have potentially
beneficial effects on results screens too which also (ab)use
`ScoreInfo`.
Mods don't necessarily have to change speed, to change beatmap attributes. Also, speed mods don't affect beatmap attributes in mania, making the text misleading.
Closes https://github.com/ppy/osu/issues/32920.
I don't know if there's going to be other cases of breakage, but from
what I can tell these settings *not* showing infinite precision
representations was a bug with the previous implementation of number
formatting.
Closes https://github.com/ppy/osu/issues/32908.
Have you ever been in a situation wherein you find out you fixed a bug
that you didn't know existed, but that makes *another* bug appear
because it was relying on the other bug? This is where I'm at right now.
But, to start from the top.
`TextFlowContainer.Text` (the setter) is a convenience property that you
use to set the text in one go. Internally it uses `AddText()`:
https://github.com/ppy/osu-framework/blob/681900ffb70adfeede4e3fa32a69da66252691ee/osu.Framework/Graphics/Containers/TextFlowContainer.cs#L81-L94
`AddText()`'s xmldoc says:
The \n character will create a new paragraph, not just a line break.
If you need \n to be a line break, use <see cref="AddParagraph{TSpriteText}(LocalisableString, Action{TSpriteText})"/> instead.
https://github.com/ppy/osu-framework/blob/681900ffb70adfeede4e3fa32a69da66252691ee/osu.Framework/Graphics/Containers/TextFlowContainer.cs#L226-L239
That's right. This portion of xmldoc was *straight up false* and
*silently broken* before https://github.com/ppy/osu-framework/pull/6556.
If you want to check that out yourself, apply the following patch to
framework:
diff --git a/osu.Framework.Tests/Visual/Containers/TestSceneTextFlowContainer.cs b/osu.Framework.Tests/Visual/Containers/TestSceneTextFlowContainer.cs
index 464f47c2c..e1ad521a7 100644
--- a/osu.Framework.Tests/Visual/Containers/TestSceneTextFlowContainer.cs
+++ b/osu.Framework.Tests/Visual/Containers/TestSceneTextFlowContainer.cs
@@ -180,6 +180,22 @@ public void TestAlignmentIsCorrectWhenLineBreaksAtLastWordOfParagraph(Anchor tex
});
}
+ [Test]
+ public void TestSetTextWithNewLine()
+ {
+ AddStep("set text", () => textContainer.Text = "this text\nhas a newline");
+ AddStep("clear and add text", () =>
+ {
+ textContainer.Clear();
+ textContainer.AddText("this text\nhas a newline");
+ });
+ AddStep("clear and add paragraph", () =>
+ {
+ textContainer.Clear();
+ textContainer.AddParagraph("this text\nhas a newline");
+ });
+ }
+
private void assertSpriteTextCount(int count)
=> AddAssert($"text flow has {count} sprite texts", () => textContainer.ChildrenOfType<SpriteText>().Count() == count);
On `master`, there will be a difference between the first two steps, and
the third. On 2025.321.0, *there will be none*.
My working theory as to why this was always busted is that the
corresponding code that was there before in
https://github.com/bdach/osu-framework/blob/c31a48178889ca2f9b4d257d2d64915eee90338a/osu.Framework/Graphics/Containers/TextFlowContainer.cs#L454-L458
just straight up ran too late. *The height of the container is being
changed after the flow has laid itself out, without adjusting subsequent
children in any way.*
There is potentially a discussion to be had as to whether the emergent
behaviour of `TextFlowContainer.Text` with respect to `\n` character is
correct, but I'm just going to start with this diff and see what the
reaction is.
Audio offset is integer based in configuration, so let's make sure not
to show that there's an applicable offset when the value difference is
too low.
I've also fixed rounding to match expectations (`AudioOffset` is
precision limited to integer), and handled the case where a user adjusts
the slider but also has a suggested offset – previously it would not
enable the button after slider adjustments but now it will work as
expected.
Saves having this defined in 20+ places. If we ever make any changes to
shear, it's 100% going to need to be applied to every usage (there will
never be a case of multiple different shears in the game).
Also fixes a mismatching definition in `ShearedNub`.