Classic scores set on some beatmap appear to have its total score heavily inflated.

[DarkbitNetwork]

Type

Game behaviour

Bug description

For some reason, this beatmap seems to have all classic mod plays set on it to be heavily inflated. The top 4 have total scores that are higher than what should have been possible in lazer. Every other classic mod score also are affected though a bit less extreme. This bug can also be seen on the website.

However, it seems like non-classic lazer plays are unaffected. I don't know if scores with classic mod set on lazer are also affected by this bug.

A downloaded replay of the inflated score seems to fix the total score though.

Screenshots or videos

Top 4 have a total score that's higher than the expected limit: 1

The downloaded replay of a top 1 score:

Version

2024.906.2-lazer

Logs

compressed-logs.zip

[bdach]

A downloaded replay of the inflated score seems to fix the total score though.

This is rather worrying because in theory the score conversion process client-side and server-side should be the exact same process executing the exact same code. https://github.com/ppy/osu/issues/29813 is another case of this.

@peppy can you please check on the specific version of the osu.Game package used by the osu-queue-score-statistics stable score import job? I worry that it might not contain some of the scoring conversion fixes that I've done at the start of this year.

[peppy]

@bdach pppy/osu-queue-score-statistics:2024.706.0, last restarted 49 days ago. Let me know if you need more information.

https://hub.docker.com/layers/pppy/osu-queue-score-statistics/2024.706.0/images/sha256-a621c7af15fa8b4b454599ce34fed2d3915d0225b70f08611aaee78e102de253?context=explore https://github.com/ppy/osu-queue-score-statistics/blob/dafc9b4b39c7e205c768d0fb7b7324f70aa1e54f/osu.Server.Queues.ScoreStatisticsProcessor/osu.Server.Queues.ScoreStatisticsProcessor.csproj (in theory)

This is specifically the high score importer, FWIW. The non-high score importer is older, sitting on 2024.312.0 (probably should be bumped).

[bdach]

Okay... then maybe it's the other end? Where's osu-difficulty-calculator at, specifically the job for computing scoring attributes? (I believe that might be a separate process from diffcalc, but not sure)

[peppy]

pppy/osu-queue-beatmap-processor:latest (https://hub.docker.com/r/pppy/osu-queue-beatmap-processor/tags)

..so https://github.com/ppy/osu-difficulty-calculator aka https://github.com/ppy/osu-difficulty-calculator/releases/tag/2022.928.0

[bdach]

That cannot be true, scoring attributes did not exist in 2022.

I am asking about scoring attributes specifically, e.g. whatever it is that is populating osu_beatmap_scoring_attribs for new ranked maps. The thing from https://github.com/ppy/osu-difficulty-calculator/pull/224.

[peppy]

This is what's running on kubernetes, if it's helpful:

[bdach]

Hmm. latest is https://hub.docker.com/layers/pppy/osu-queue-beatmap-processor/latest/images/sha256-b146bf6bfcd7ec6204aa9d7c8ff98f0175a5649c03e86738e5ef80987e87c005?context=explore which is dated Dec 18, so probably somewhere at https://github.com/ppy/osu-difficulty-calculator/commit/b8fa416cf6e0af94a51831eed6aca64394e6b3a1. Which is pretty old and possibly causing this. The theory would be that while we did deploys of scoring attribute changes after my fixes previously, the processor got forgotten and as such rolling scoring attribute updates are using a stale revision. I probably should have specifically reminded about that...

One last thing: what does

SELECT * FROM `osu_beatmap_scoring_attribs` WHERE `beatmap_id` IN (4713870, 1593298) AND `mode` = 0;

spit out? I'll use the output of that to crosscheck scoring attributes and see if that theory checks out.

The good slash bad news is that if it is that, we have all the means to correct this, it'll just take time...

1. Update the processor so that it's using newest game packages
2. Recalculate all beatmaps' scoring attributes again to cover the gap that was using old code
3. Reverify all scores

Maybe it'd take less time if we could perform steps (2) and (3) selectively but I'm not currently sure we have the means to do that. (3) maybe could be done selectively, if we can conclusively somehow get a known-good starting score ID.

[peppy]

Sorry, missed this.

root@db-master:osu> SELECT * FROM `osu_beatmap_scoring_attribs` WHERE `beatmap_id` IN (4713870, 1593298) AND `mode` = 0;;
+------------+------+-----------------------+--------------------+--------------------------+--------------------+-----------+
| beatmap_id | mode | legacy_accuracy_score | legacy_combo_score | legacy_bonus_score_ratio | legacy_bonus_score | max_combo |
+------------+------+-----------------------+--------------------+--------------------------+--------------------+-----------+
| 1593298    | 0    | 283440                | 25738656           | 0.0498507                | 33500              | 1198      |
| 4713870    | 0    | 383580                | 48484032           | 0.0473684                | 11400              | 1725      |
+------------+------+-----------------------+--------------------+--------------------------+--------------------+-----------+

2 rows in set

[bdach]

Yeah these look wrong, legacy_combo_score to be precise. It should be

beatmap_id	legacy_combo_score
1593298	32173320
4713870	60605040

And the values in the database match values from ppy/osu@2023.1218.0, which is what https://github.com/ppy/osu-difficulty-calculator/commit/b8fa416cf6e0af94a51831eed6aca64394e6b3a1 specifies, which is where pppy/osu-queue-beatmap-processor:latest seems to be at. So circumstantial evidence would appear to confirm the theory above.

Kinda thinking that maybe it's best to do the pp deploy first (https://github.com/ppy/osu-infrastructure/issues/30) and only then come back to this. Chances are osu-difficulty-calculator will have to be deployed as part of that anyway, so at the least doing so would have the effect of stopping the bleeding on this. Retroactive corrective action can be taken later.