59 Commits

• 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
• Bump legacy score version to recalculate all scores
  Bartłomiej Dach · 2024-03-25 19:27:38 +01:00
  73926592b9
• Compare against MaxCombo instead
  Dan Balasescu · 2024-03-19 17:46:18 +09:00
  f6069d8d93
• Fix incorrectly encoded score IsPerfect value
  Dan Balasescu · 2024-03-19 17:20:59 +09:00
  af713a7869
• Bump score version
  Bartłomiej Dach · 2024-03-06 21:30:09 +01:00
  3121cf81e6
• Bump score version
  Bartłomiej Dach · 2024-02-24 13:20:42 +01:00
  4bc92a263f
• Add migration
  Dean Herbert · 2024-01-22 21:43:32 +09:00
  644e7d6fe6
• 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
• 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 remote-tracking branch 'upstream/master' into scorev3
  Zyf · 2023-11-19 23:53:05 +01:00
  cadd9b4ace
• Move legacy online ID encode/decode to legacy property
  Bartłomiej Dach · 2023-10-16 11:20:02 +02:00
  fa519984df
• Update score conversion to consider legacy multiplier
  Dan Balasescu · 2023-10-02 16:56:15 +09:00
  b9ab4a2b7c
• Bump version to allow migration to re-run
  Dean Herbert · 2023-08-22 16:13:01 +09:00
  5dee43815c
• Merge branch 'master' into editor-save-local-score-management
  Dean Herbert · 2023-07-06 12:28:44 +09:00
  9ff6b3fcd3
• Move preconditions to realm migration step to simplify marker version logic
  Dean Herbert · 2023-07-04 17:53:53 +09:00
  a0c3fa9c13
• Make ScoreInfo.BeatmapInfo nullable
  Dean Herbert · 2023-07-04 14:50:34 +09:00
  d74b1e148d
• Refactoring
  Dan Balasescu · 2023-06-28 16:14:32 +09:00
  09bc8e45de
• Add migration for total score conversion
  Dan Balasescu · 2023-06-26 21:53:21 +09:00
  8e79510793
• Revert nullability enable in Score (and related changes)

  Causes several knock-on inspections in `OsuGame` et al. Probably best
  addressed in a separate pass, because treatment is mixed at best (some
  places nullcheck, some expect non-null).

  Bartłomiej Dach · 2023-06-24 15:35:07 +02:00
  66ef199fa4
• Manual fixes to reduce warnings to zero
  Dean Herbert · 2023-06-24 01:52:53 +09:00
  df5b389629
• Bump replay version in encoder after Score V2 changes

  One release too late, but this may help in the future if we need to
  discern replays set with Score V2 from older lazer replays.

  Bartłomiej Dach · 2023-06-09 14:49:49 +02:00
  52412c673d
• Add description for lazer score version 30000001
  Dan Balasescu · 2022-12-14 18:30:33 +09:00
  fb85eaee95
• Allow keeping stream open after encoding scores
  Dan Balasescu · 2022-12-13 16:15:14 +09:00
  ad7554cc7d
• Fix incorrectly modified first lazer version
  Dan Balasescu · 2022-12-08 11:30:18 +09:00
  e00c075482
• Append lazer score data to .osr files
  Dan Balasescu · 2022-12-07 12:12:32 +09:00
  df181acffe
• Use debug.assert for better readable.
  andy840119 · 2022-07-03 19:27:56 +08:00
  8c2f4b48fc
• Use AsNonNull() instead.
  andy840119 · 2022-07-02 19:48:32 +08:00
  0a1543c6e8
• pretend that the beatmap property will not be null.

  Not really throw exception will be the better way?

  andy840119 · 2022-07-02 13:20:46 +08:00
  c6d0f0f81b
• Automated #nullable processing
  Dan Balasescu · 2022-06-17 16:37:17 +09:00
  f8830c6850
• Use a constant for the early version timing offset
  Dean Herbert · 2022-03-24 16:43:41 +09:00
  a7554dcdf7
• Apply beatmap offsets to legacy replay frame handling
  Dean Herbert · 2022-03-24 16:16:40 +09:00
  a7d5f2281c
• Replace remaining manual online ID check with extension method
  Bartłomiej Dach · 2022-03-03 23:09:56 +01:00
  36263b4dbf
• Use constant for maximum legacy ruleset id
  Dean Herbert · 2022-03-01 12:07:03 +09:00
  eb75a29b20
• Enable nullable for LegacyScoreEncoder
  Dean Herbert · 2022-02-28 18:42:23 +09:00
  52e50db6b9
• Only convert non-legacy frames (and throw on conversion failure)
  Dean Herbert · 2022-02-28 18:42:23 +09:00
  723e96309a
• Allow LegacyScoreEncoder to be used without a beatmap if frames are already legacy frames
  Dean Herbert · 2022-02-28 18:42:23 +09:00
  2e96f74c94
• Update all usages of RulesetID and Ruleset.ID to use Ruleset.OnlineID
  Dean Herbert · 2022-01-27 15:38:03 +09:00
  5288eedd31
• more fixes (almost compiles, except ruleset and manager)
  Dean Herbert · 2022-01-12 16:57:27 +09:00
  53792811b2
• Fix score encoder being dependent on current culture

  As it turns out, on some cultures, the "negative integer" sign is not
  encoded using the U+002D HYPHEN-MINUS codepoint. For instance, Swedish
  uses U+2212 MINUS SIGN instead. This was confusing the legacy decoder,
  since it is correctly depending on the serialisation being
  culture-independent.
  
  To fix, ensure that the special "end replay" frame, as well as the
  replay MD5 hash, are generated in a culture-invariant manner.
  
  Thankfully the replay MD5 hash is currently being discarded in
  `LegacyScoreDecoder`, so it changing in future scores should not have
  any negative effect on lazer operation.

  Bartłomiej Dach · 2021-12-04 17:13:43 +01:00
  f051720fa1
• Update all actual usages of RulesetInfo.ID to use OnlineID instead
  Dean Herbert · 2021-11-24 15:50:26 +09:00
  bbd3ea5b77
• Apply batch fixing of built-in types using var
  Dean Herbert · 2021-10-27 13:04:41 +09:00
  6944151486
• Rename last remaining BeatmapInfo Beatmap usage
  Dean Herbert · 2021-10-04 17:35:53 +09:00
  853cf6feaa
• Extract first version out to constant
  Dean Herbert · 2021-06-08 18:38:47 +09:00
  4ee7721c51
• Update score encoder version to be higher than any existing stable version
  Dean Herbert · 2021-06-08 17:59:43 +09:00
  4d9fffc01b