Closes https://github.com/ppy/osu/issues/27540.
As it turns out, some ZIP archivers (like 7zip) will decide to add fake
entries for directories, and some (like windows zipfolders) won't.
The "directory" entries aren't really properly supported using any
actual data or attributes, they're detected by sharpcompress basically
by heuristics:
ab5535eba3/src/SharpCompress/Common/Zip/Headers/ZipFileEntry.cs (L19-L31)
When importing into realm we have thus far presumed that these directory
entries will not be a thing. Having them be a thing breaks multiple
things, like:
- When importing from ZIPs with separate directory entries, a separate
`RealmFile` is created for a directory entry even though it doesn't
represent a real file
- As a result, when re-exporting a model with files imported from such
an archive, a zero-byte file would be created because to the database
it looks like it was originally a zero-byte file.
If you want to have fun, google "zip empty directories". You'll see
a whole gamut of languages, libraries, and developers stepping on this
rake. Yet another episode of underspecced mistakes from decades ago
that were somebody's "good idea" but continue to wreak havoc forevermore
because now there are two competing conventions you can't just pick one.
Closes https://github.com/ppy/osu/issues/27522.
Concerns mostly taiko and catch.
Not much of a proper fix rather than a workaround but it is what it is.
I tried a few other things, including setting `MaskingSmoothness = 0` on
the scaling container itself, to no avail.
As it turns out, the "lower" and "upper" estimates of the combo portion
of the score being converted were misnomers. In selected cases
(scores with high accuracy but combo being lower than max by more than
a few objects) the janky score-based math could overestimate the count
of remaining objects in a map. For instance, in one case the numbers
worked out something like this:
- Accuracy: practically 100%
- Max combo on beatmap: 571x
- Max combo for score: 551x
The score-based estimation attempts to extract a "remaining object
count" from score, by doing something along of sqrt(571^2 - 551^2). That
comes out to _almost 150_. Which leads to the estimation overshooting
the total max combo count on the beatmap by some hundred objects.
To curtail this nonsense, enforce some basic invariants:
- Neither estimate is allowed to exceed maximum achievable
- Ensure that lower estimate is really lower and upper is really upper
by just looking at the values and making sure that is so rather than
just saying that it is.
