181 Commits

• Store pause timestamps (rounded to ms) instead of general count
  Bartłomiej Dach · 2025-07-22 09:26:12 +02:00
  d8900defd3
• Store score pause count to replays
  Bartłomiej Dach · 2025-07-07 11:00:31 +02:00
  2b6dab1e9d
• Fix very old lazer replays failing to decode

  See
  https://discord.com/channels/188630481301012481/1097318920991559880/1389240665061462047.
  
  I hope this was worth it.

  Bartłomiej Dach · 2025-07-01 10:14:27 +02:00
  654faa553a
• Merge pull request #33612 from bdach/stable-scores-with-zero-legacy-id

  Fix stable scores importing with a `LegacyOnlineID` of 0

  Dean Herbert · 2025-06-25 16:50:45 +09:00
  4b665842fb
• Add support for showing leaderboard in playlists and daily challenge

  As touched on in https://github.com/ppy/osu/pull/33581.

  Bartłomiej Dach · 2025-06-11 11:21:26 +02:00
  4810c7c847
• Fix stable scores importing with a LegacyOnlineID of 0

  Closes https://github.com/ppy/osu/issues/33435.
  
  The root cause of the issue is that the user's database contained a
  whole lot of scores with `LegacyOnlineID` of 0, which would trip up
  
  	https://github.com/ppy/osu/blob/97e6187f0d7c3dbee896596a623e34627135bf0e/osu.Game/Extensions/ModelExtensions.cs#L128-L129
  
  as that method would thus consider scores that are not the same as the
  same because of the zero, which later trips up
  
  	https://github.com/ppy/osu/blob/97e6187f0d7c3dbee896596a623e34627135bf0e/osu.Game/Screens/Ranking/SoloResultsScreen.cs#L79
  
  which ends up inserting `Score` into the list several times, which
  causes the crash.
  
  You might remember that I tried to fix this once before in
  https://github.com/ppy/osu/pull/24794. What I did not realise, however,
  is that stable *can still produce replays* that have an online ID of
  zero in them, because zero *is just `default(long)`*:
  
  	https://github.com/peppy/osu-stable-reference/blob/7205341bb70000a87fa1bd54e7642772e2af85d7/osu!/GameplayElements/Scoring/Score.cs#L123
  	https://github.com/peppy/osu-stable-reference/blob/7205341bb70000a87fa1bd54e7642772e2af85d7/osu!/GameplayElements/Scoring/Score.cs#L350
  
  The alternative way of fixing this would be just to change
  `MatchesOnlineID` to reject zeroes, but I think this is a saner overall
  direction.

  Bartłomiej Dach · 2025-06-10 11:54:11 +02:00
  d4fc6693b4
• Fix possible replay playback inaccuracy with very large lead-in time

  Closes https://github.com/ppy/osu/issues/22086
  
  While this *is* a case of aspire-tier breakage, I hesitate to dismiss it
  as wontfix, because the fix is somewhat easy, and probably results in
  better accuracy across the board.
  
  The issue in question here manifests when there is a significant amount
  of lead-in time, like what the beatmap linked in the aforementioned
  issue (https://osu.ppy.sh/beatmapsets/948643#osu/1981090) does.
  
  Both stable and lazer record replay frames using absolute timestamps,
  *but* the legacy replay format after the first frame uses time *deltas*,
  i.e. amounts of time elapsed since the previous frame. This means that
  the decoding process of the replay has to reconstruct absolute timestamps
  by doing cumulative summation starting from the first frame.
  
  When the very first frame has a timestamp that is very large in
  magnitude (say, like the negative 2 billion that the beatmap in question
  uses), this will lead to error if the cumulative summation is using
  floating point numbers, because it will be adding a small magnitude
  frame delta to a large magnitude cumulative absolute time. Which means
  that sometimes adding the frame delta to the cumulative time *will not
  change the cumulative time*, leading to the loss of time and thus replay
  de-synchronisation.
  
  Knowing that the legacy replay format only deals in integral time
  values, however, this can be circumvented by just using a large enough
  integral number type for the cumulative time tracking instead. I think
  `long` in this case can be safely used "large enough" for our purposes:
  
  	> Console.WriteLine(long.MaxValue);
  	9223372036854775807
  
  	9 223 372 036 854 775 807 ms equals 292 277 024,6269277149 years

  Bartłomiej Dach · 2025-05-16 12:52:49 +02:00
  56e17dd7ba
• Move BeatmapVersion from BeatmapInfo to IBeatmap

  Closes https://github.com/ppy/osu/issues/32420.
  
  The failure cause here is that in editor the beatmap version for the
  beatmap affected (or... any beatmap, really), is 0 (ZERO). That is
  probably a regression from https://github.com/ppy/osu/pull/32315, but
  like... can we universally agree that calling that change "a regression"
  in any capacity is dumb? Like what was that code *doing* playing dumb
  reference games and copying stuff into an arbitrary instance that could
  get or not get used later on? And now you have a 50/50 chance of
  accessing the *correct* model's field, depending on whether you go via
  `BeatmapInfo` or `Beatmap.BeatmapInfo`?
  
  Moving the field to `IBeatmap`, i.e. what is by now - by consensus,
  since https://github.com/ppy/osu/pull/28473 - supposed to be the "decoded
  and materialised" beatmap, fixes this issue.
  
  I probably should have done this as part of
  https://github.com/ppy/osu/pull/28473 but it slipped my mind. Probably
  for the better too because this change has rather large chances of
  breaking stuff so maybe better to examine it in isolation (via diffcalc
  runs or whatever).
  
  For added humour points, you'd say that the field on `BeatmapInfo` was
  not `[Ignore]`d, so this is a realm schema change, right? No. As far as
  I can tell, it's not. I opened realm studio and `BeatmapVersion` *is not
  a listed column` on `Beatmap` models.
  
  I'm also not gonna get into the fact that I think `EditorBeatmap` doing
  dumb games with juggling two `BeatmapInfo` references since
  https://github.com/ppy/osu/pull/15075 is bad, because I don't think I
  have the mental capacity to hotfix this by going down that train of
  thought.

  Bartłomiej Dach · 2025-03-17 15:04:48 +01:00
  91f3be5fea
• Fix mouseX legacy replay parsing for high key counts in mania
  clayton · 2024-08-11 09:45:43 -07:00
  9620c58751
• Merge branch 'master' into negative-frame-handling
  Dan Balasescu · 2024-05-29 13:14:59 +09:00
  655b0f5343
• Merge branch 'master' into pre-mod-multiplier-score
  Bartłomiej Dach · 2024-05-08 13:39:44 +02:00
  c9414da5d4
• Use score.User.OnlineID instead of score.UserID

  You'd hope that they'd be the same thing, but
  post-https://github.com/ppy/osu-server-spectator/pull/230 it turns out
  that cannot be guaranteed, so just attempt to use `User` in the encoder
  consistently everywhere...

  Bartłomiej Dach · 2024-05-06 16:29:03 +02:00
  9c6968c13a
• Decode user ID from score if available
  Bartłomiej Dach · 2024-05-06 12:28:13 +02:00
  554ead0d9d
• Encode user ID to replays
  Bartłomiej Dach · 2024-05-06 12:28:13 +02:00
  4d9ccdc3b2
• Preserve score rank on encode/decode
  Salman Ahmed · 2024-05-01 23:31:23 +03:00
  0106f1fe3e
• Export and import TotalScoreWithoutMods to replays (or recalculate if it missing)
  Bartłomiej Dach · 2024-04-17 09:08:15 +02:00
  2f1a4cdaa4
• Bump legacy score version to recalculate all scores
  Bartłomiej Dach · 2024-03-25 19:27:38 +01:00
  73926592b9
• Rewrite handling of legacy replay frame quirks to match stable closer
  Bartłomiej Dach · 2024-03-21 21:11:29 +01:00
  990a07af0e
• Merge branch 'master' into negative-frame-handling
  Bartłomiej Dach · 2024-03-21 16:45:35 +01:00
  c47463ee0e
• Compare against MaxCombo instead
  Dan Balasescu · 2024-03-19 17:46:18 +09:00
  f6069d8d93
• Remove added property, use local decoding instead
  Dan Balasescu · 2024-03-19 17:44:37 +09:00
  6e33509417
• Fix incorrectly encoded score IsPerfect value
  Dan Balasescu · 2024-03-19 17:20:59 +09:00
  af713a7869
• Merge pull request #27513 from bdach/osu-score-conversion-bad-very-not-good

  Fix osu! standardised score estimation algorithm violating basic invariants

  Dan Balasescu · 2024-03-07 17:05:32 +09:00
  e0fe33a7a7
• Bump score version
  Bartłomiej Dach · 2024-03-06 21:30:09 +01:00
  3121cf81e6
• Merge pull request #27489 from bdach/fix-catch-pp-mismatch

  Fix catch pp calculator not matching live with respect to miss handling

  Dan Balasescu · 2024-03-06 19:39:20 +09:00
  d8003ab8e8
• Use new ToDictionary() overload without delegates
  Berkan Diler · 2024-03-05 10:27:12 +01:00
  6fabbe2616
• Fix incorrect implementation of GetCountMiss() for catch
  Bartłomiej Dach · 2024-03-04 11:49:12 +01:00
  dcd6b02809
• Bump score version
  Bartłomiej Dach · 2024-02-24 13:20:42 +01:00
  4bc92a263f
• Make LegacyScoreDecoder.PopulateMaximumStatistics() public

  For `osu-tools` consumption.

  Bartłomiej Dach · 2024-01-29 21:42:38 +01:00
  6888cda02c
• Move transferal of LegacyTotalScore back to original spot

  This subtle detail was messing with server-side score import flows.
  Server-side, legacy total score will *already* be in `LegacyTotalScore`
  from the start, and `TotalScore` will be zero until recomputed via
  `StandardisedScoreMigrationTools.UpdateFromLegacy()` - so in that
  context, attempting to move it across is incorrect.

  Bartłomiej Dach · 2024-01-23 12:42:57 +01:00
  cb87d6ce50
• Remove redundant assertion

  It does look pretty dumb to be checking if something is `null` *after
  calling an instance method on it*...

  Bartłomiej Dach · 2024-01-22 22:01:03 +01:00
  4d253ebf3c
• Remove legacy computation of accuracy & ranks
  Bartłomiej Dach · 2024-01-22 20:52:54 +01:00
  cdd6e71d01
• Unify legacy total score / accuracy / rank recomputation flows
  Bartłomiej Dach · 2024-01-22 20:52:51 +01:00
  db4849442e
• Use lazer accuracy & rank implementations across the board
  Bartłomiej Dach · 2024-01-22 20:30:16 +01:00
  2958631c5d
• Move maximum statistics population to LegacyScoreDecoder
  Bartłomiej Dach · 2024-01-22 20:01:24 +01:00
  aa8eee0796
• Add migration
  Dean Herbert · 2024-01-22 21:43:32 +09:00
  644e7d6fe6
• Change S rank to require no miss
  Dean Herbert · 2024-01-22 21:43:32 +09:00
  c8521b49cd
• Fix incorrect accuracy and rank population when decoding lazer replays

  Closes https://github.com/ppy/osu/issues/24061.
  
  The gist of this change is that if the `LegacyReplaySoloScoreInfo`
  bolt-on is present in the replay, then it can (and is) used to recompute
  the accuracy, and rank is computed based on that.
  
  This was the missing part of
  https://github.com/ppy/osu/issues/24061#issuecomment-1888438151.
  The accuracy would change on import before that because the encode
  process is _lossy_ if the `LegacyReplaySoloScoreInfo` bolt-on is not
  used, as the legacy format only has 6 fields for encoding judgement
  counts, and some judgements that affect accuracy in lazer do not fit
  into that.
  
  Note that this _only_ fixes _relatively_ new lazer scores looking wrong
  after reimport.
  
  - Very old lazer scores, i.e. ones that don't have the
    `LegacyReplaySoloScoreInfo` bolt-on, obviously can't use it
    to repopulate. There's really not much good that can be done there,
    so the stable pathways are used as a fallback that always works.
  
  - For stable replays, `ScoreImporter` recalculates the accuracy of
    the score _again_ in
  
    https://github.com/ppy/osu/blob/15a5fd7e4c8e8e3c38382cfd3d5d676d107d7908/osu.Game/Scoring/ScoreImporter.cs#L106-L110
  
    as `StandardisedScoreMigrationTools.UpdateFromLegacy()` recomputes
    _both_ total score and accuracy.
  
    This makes a _semblance_ of sense as it attempts to make the accuracy
    of stable and lazer replays comparable. In most cases it also won't
    matter, as the only ruleset where accuracy changed between the legacy
    implementation and current lazer accuracy is mania.
  
    But it is also an inaccurate process (as, again, some of the required
    data is not in the replay, namely judgement counts of ticks
    and so on).
  
    For whatever's worth, a similar thing happens server-side in
  
    https://github.com/ppy/osu-queue-score-statistics/blob/106c2948dbe695efcad5972d32cd46f4b36005cc/osu.Server.Queues.ScoreStatisticsProcessor/Commands/Queue/BatchInserter.cs#L319
  
  - However, _ranks_ of stable scores will still use the local stable
    reimplementation of ranks, i.e. a 1-miss stable score in osu! ruleset
    will be an A rather than an S. See importer:
  
    https://github.com/ppy/osu-queue-score-statistics/blob/106c2948dbe695efcad5972d32cd46f4b36005cc/osu.Server.Queues.ScoreStatisticsProcessor/Commands/Queue/BatchInserter.cs#L237
  
    (it's the same method which is renamed
    to `PopulateLegacyAccuracyAndRank()` in this commit).
  
    That is all a bit of a mess honestly, but I'm not sure where to even
    begin there...

  Bartłomiej Dach · 2024-01-16 22:38:53 +01:00
  17b9d842ab
• Fix incorrect score conversion on selected beatmaps due to incorrect difficultyPeppyStars rounding

  Fixes issue that occurs on *about* 246 beatmaps and was first described
  by me on discord:
  
      https://discord.com/channels/188630481301012481/188630652340404224/1154367700378865715
  
  and then rediscovered again during work on
  https://github.com/ppy/osu/pull/26405:
  
      https://gist.github.com/bdach/414d5289f65b0399fa8f9732245a4f7c#venenog-on-ultmate-end-by-blacky-overdose-631
  
  It so happens that in stable, due to .NET Framework internals, float
  math would be performed using x87 registers and opcodes.
  .NET (Core) however uses SSE instructions on 32- and 64-bit words.
  x87 registers are _80 bits_ wide. Which is notably wider than _both_
  float and double. Therefore, on a significant number of beatmaps,
  the rounding would not produce correct values due to insufficient
  precision.
  
  See following gist for corroboration of the above:
  
      https://gist.github.com/bdach/dcde58d5a3607b0408faa3aa2b67bf10
  
  Thus, to crudely - but, seemingly accurately, after checking across
  all ranked maps - emulate this, use `decimal`, which is slow, but has
  bigger precision than `double`. The single known exception beatmap
  in whose case this results in an incorrect result is
  
      https://osu.ppy.sh/beatmapsets/1156087#osu/2625853
  
  which is considered an "acceptable casualty" of sorts.
  
  Doing this requires some fooling of the compiler / runtime (see second
  inline comment in new method). To corroborate that this is required,
  you can try the following code snippet:
  
      Console.WriteLine(string.Join(' ', BitConverter.GetBytes(1.3f).Select(x => x.ToString("X2"))));
      Console.WriteLine(string.Join(' ', BitConverter.GetBytes(1.3).Select(x => x.ToString("X2"))));
      Console.WriteLine();
  
      decimal d1 = (decimal)1.3f;
      decimal d2 = (decimal)1.3;
      decimal d3 = (decimal)(double)1.3f;
  
      Console.WriteLine(string.Join(' ', decimal.GetBits(d1).SelectMany(BitConverter.GetBytes).Select(x => x.ToString("X2"))));
      Console.WriteLine(string.Join(' ', decimal.GetBits(d2).SelectMany(BitConverter.GetBytes).Select(x => x.ToString("X2"))));
      Console.WriteLine(string.Join(' ', decimal.GetBits(d3).SelectMany(BitConverter.GetBytes).Select(x => x.ToString("X2"))));
  
  which will print
  
      66 66 A6 3F
      CD CC CC CC CC CC F4 3F
  
      0D 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00
      0D 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00
      8C 5D 89 FB 3B 76 00 00 00 00 00 00 00 00 0E 00
  
  Note that despite `d1` being converted from a less-precise floating-
  -point value than `d2`, it still is represented 100% accurately as
  a decimal number.
  
  After applying this change, recomputation of legacy scoring attributes
  for *all* rulesets will be required.

  Bartłomiej Dach · 2024-01-10 19:30:18 +01:00
  7c9adc7ad3
• Merge branch 'master' into catch-scoring
  Bartłomiej Dach · 2024-01-09 15:49:37 +01:00
  00a4c055b3
• Fix mania score conversion using score V1 accuracy

  Partially addresses https://github.com/ppy/osu/discussions/26416
  
  As pointed out in the discussion thread above, the total score
  conversion process for mania was using accuracy directly from the
  replay. In mania accuracy is calculated differently in score V1 than in
  score V2, which meant that scores coming from stable were treated more
  favourably (due to weighting GREAT and PERFECT equally).
  
  To fix, recompute accuracy locally and use that for the accuracy
  portion.
  
  Note that this will still not be (and cannot be made) 100% accurate, as
  in stable score V2, as well as in lazer, hold notes are *two*
  judgements, not one as in stable score V1, meaning that full and correct
  score statistics are not available without playing back the replay.
  
  The effects of the change can be previewed on the following spreadsheet:
  
  https://docs.google.com/spreadsheets/d/1wxD4UwLjwcr7n9y5Yq7EN0lgiLBN93kpd4gBnAlG-E0/edit#gid=1711190356
  
  Top 5 changed scores with replays:
  
  | score                                                                                                                            | master  | this PR | replay  |
  | :------------------------------------------------------------------------------------------------------------------------------- | ------: | ------: | ------: |
  | [Outlasted on Uwa!! So Holiday by toby fox [[4K] easy] (0.71\*)](https://osu.ppy.sh/scores/mania/460404716)                      | 935,917 | 927,269 | 920,579 |
  | [ag0 on Emotional Uplifting Orchestral by bradbreeck [[4K] Rocket's Normal] (0.76\*)](https://osu.ppy.sh/scores/mania/453133066) | 921,636 | 913,535 | 875,549 |
  | [rlarkgus on Zen Zen Zense by Gom (HoneyWorks) [[5K] Normal] (1.68\*)](https://osu.ppy.sh/scores/mania/458368312)                | 934,340 | 926,787 | 918,855 |
  | [YuJJun on Harumachi Clover by R3 Music Box [4K Catastrophe] (1.80\*)](https://osu.ppy.sh/scores/mania/548215786)                | 918,606 | 911,111 | 885,454 |
  | [Fritte on 45-byou by respon feat. Hatsune Miku & Megpoid [[5K] Normal] (1.52\*)](https://osu.ppy.sh/scores/mania/516079410)     | 900,024 | 892,569 | 907,456 |

  Bartłomiej Dach · 2024-01-08 16:38:43 +01:00
  8c82bb006c
• Implement approximate score conversion algorithm matching score V2
  Bartłomiej Dach · 2024-01-05 20:46:11 +01:00
  ea7078fab5
• Fix standardised score conversion failing for scores set with 0.0x mod mutliplier

  Closes https://github.com/ppy/osu/issues/26073.

  Bartłomiej Dach · 2023-12-23 13:28:39 +01:00
  3a2ed3677b
• Merge branch 'master' into add-score-version
  Bartłomiej Dach · 2023-12-21 13:06:53 +01:00
  fbf19ea598
• Serialise and deserialise ClientVersion to replays
  Bartłomiej Dach · 2023-12-21 12:58:08 +01:00
  2baf579f7c
• Reconvert all legacy scores
  Dan Balasescu · 2023-12-21 15:32:34 +09:00
  c3c1752a5a
• Bump score version in order to recompute legacy scores
  Bartłomiej Dach · 2023-12-20 16:01:59 +01:00
  9515f7dbfa
• Fix osu! standardised score conversion sometimes exceeding bounds

  Co-authored-by: Zyf <zyfarok@gmail.com>
  
  Closes https://github.com/ppy/osu/issues/25860
  
  Users reported that some stable scores would convert to large negative
  total scores in lazer after the introduction of combo exponent. Those
  large negative total scores were actually mangled NaNs.
  
  The root cause of this was the following calculation going below zero
  unexpectedly:
  
  	https://github.com/ppy/osu/blob/8e8d9b2cd96be4c4b3d8f1f01dc013fc9d41f765/osu.Game/Database/StandardisedScoreMigrationTools.cs#L323
  
  which then propagates negative numbers onward until
  
  	https://github.com/ppy/osu/blob/8e8d9b2cd96be4c4b3d8f1f01dc013fc9d41f765/osu.Game/Database/StandardisedScoreMigrationTools.cs#L337
  
  which yields a NaN due to attempting to take the square root of a
  negative number.
  
  To fix, clamp `comboPortionInScoreV1` to sane limits: to
  `comboPortionFromLongestComboInScoreV1` from below, and to
  `maximumAchievableComboPortionInScoreV1` from above. This is a less
  direct fix than perhaps imagined, but it seems like a better one as it
  will also affect the calculation of both the lower and the upper
  estimate of the score.

  Bartłomiej Dach · 2023-12-18 22:05:19 +01:00
  017003deea
• Merge branch 'master' into scorev3
  Bartłomiej Dach · 2023-11-24 10:37:10 +09:00
  ca37e1afc2
• Fix classic scoring overflowing in osu! ruleset due to integer multiplication overflow

  Closes https://github.com/ppy/osu/issues/25545.

  Bartłomiej Dach · 2023-11-23 08:16:25 +09:00
  e28e0ef1cc