Round object coordinates to nearest integers on legacy export rather than truncating #31305
+105
−17
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
RFC. Closes #31256.
This is an RFC because of 0d16ed0. The lowdown is that the truncating was actually silently being done by
LegacyBeatmapDecoder
:osu/osu.Game/Rulesets/Objects/Legacy/ConvertHitObjectParser.cs
Lines 56 to 59 in fa0d2f4
I very explicitly do not want to be touching decoder logic for this, I want this change to be limited to the legacy export, which leaves very few options. We do not have a cloning / "reconstruct this hitobject with this property changed" facility available (#25467 says hi again), so exposing setters is about the only escape hatch available at this stage.
There are a few other code paths in the decoder preconditioned on
FIRST_LAZER_VERSION
:osu/osu.Game/Rulesets/Objects/Legacy/ConvertHitObjectParser.cs
Lines 367 to 376 in fa0d2f4
osu/osu.Game/Rulesets/Objects/Legacy/ConvertHitObjectParser.cs
Lines 403 to 404 in fa0d2f4
but I'm ignoring these at least until I find out whether everyone else is going to scoff at me for trying to do this in this way or not. Most likely I'll be ignoring these until someone complains.