mirror of
https://github.com/ppy/osu.git
synced 2026-05-13 19:54:15 +08:00
Bartłomiej Dach
6231e06ebe
Closes https://github.com/ppy/osu/issues/37232. The actual fix is https://github.com/ppy/osu/commit/e959b20517497a093d3c00a17457c5d36bf57651; everything else is window dressing / test harness to ensure I don't try and do a wrong change like https://github.com/ppy/osu/pull/37251 did. I recommend reviewing commit-by-commit. See [this desmos](https://www.desmos.com/calculator/a5yjpacvxa) for visual explanation of change, I think it does a better job at explaining this than any words I could type here. Of note: - In the end this did only affect 14K but that should never be assumed when floating point is involved. - Test cases generated here were generated in stable manually. - Except for 11 / 13 / 15 / 17K which are not officially supported and which don't work in lazer due to orthogonal reasons (see comment added in this PR in `ManiaBeatmapConverter`), decoding in lazer was always fine. - My worry was that the old encoding method before this PR could potentially cause stable to move a note from one column to another but thankfully that is not the case. The old method of encoding columns as X positions does not cause issues wherein lazer reads them back differently than stable after encode. I checked this by checking out `master`, re-encoding all of the test stair-pattern nK beatmaps added in this PR on `master`, exporting that as compatibility, re-importing to stable, and cross-checking that the decoded beatmap is visually the same on lazer and on stable. This is important to check because if this wasn't the case, we'd potentially have cases of actual online beatmaps (remember that we have BSS now) wherein a beatmap plays differently on stable than on lazer due to notes moving between columns, and would need to screen for this being the case and potentially apply corrective / reconciliatory action.
6231e06ebe
·
2026-04-11 00:38:22 +09:00
History