Feels like it's easier to understand this way. The difference of the
maximum scoring values for the entire beatmap and the max values for the
part of the beatmap that has already been played represents the act of
filling the rest of the unjudged objects with maximum results.
Closes#21920.
Weirdly enough this was semeingly fixed once before in ancient times in
3891f467a3, but then unfixed again in
566e09083f. The second change is no longer
needed since the toolbar became opaque in #9447.
- It was being glued in an ugly way that would have prevented sanely
localising it.
- Even on Linux, the filesystem (whichever one the user has chosen out
of the multitude available) still needs to support hard links for them
to have a chance of working.
With .NET 6, the way Xamarin package versioning works has changed.
- The `ApplicationVersion` MSBuild property aims to replace
`android:versionCode` in the manifest.
- The `ApplicationDisplayVersion` MSBuild property aims to replace
`android:versionName` in the manifest.
More about this can be read in Xamarin docs:
ec712da8c1/Documentation/guides/OneDotNetSingleProject.md
To this end:
- Manual `version{Code,Name}` specs are removed from
`AndroidManifest.xml`, as they were preventing MSBuild properties
from functioning properly.
- `Version` now defaults to 0.0.0, so that local builds don't appear
like they were deployed (see `OsuGameBase.IsDeployedBuild`).
- `ApplicationDisplayVersion` now defaults to `Version`.
This addresses the Android portion of #21498.
- `ApplicationVersion` can now be specified by command line,
but still needs to be supplied manually for version detection to
work correctly. See `OsuGameAndroid.AssemblyVersion` for more info.
Putting the pieces together, the complete publish command to deploy
a new build should look something like so:
dotnet publish -f net6.0-android \
-r android-arm64 \
-c Release \
-p:Version=2022.1228.0 \
-p:ApplicationVersion=202212280
