Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move judgement result revert logic to Playfield #22291

Merged
merged 15 commits into from
Feb 19, 2023

Conversation

ekrctb
Copy link
Collaborator

@ekrctb ekrctb commented Jan 19, 2023

Previously, some judgement results were not reverted when the source DHO is not alive (e.g. frames skipped in editor).
Now, all results are reverted in the exact reverse order.
HitObjectContainer.RevertResult event is removed and Playfield.RevertResult event is changed to remove DrawableHitObject argument.

Previously, some judgement results were not reverted
when the source DHO is not alive (e.g. frames skipped in editor).
Now, all results are reverted in the exact reverse order.
@peppy
Copy link
Member

peppy commented Jan 23, 2023

I think it would be good to add a test here which fails on master, so we can better understand the specific fail case (and guard against it potentially regressing in the future).

Calculating from TimeOffset is bad because it loses precision.
The result time won't change anymore
even If `HitObject.GetEndTime()` changes later.
@peppy
Copy link
Member

peppy commented Jan 25, 2023

@smoogipoo interested in your high level thoughts on this change as well.

@peppy peppy self-requested a review January 25, 2023 08:35
{
base.Update();

if (Result != null && Result.HasResult)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a huge win.

@@ -26,6 +27,8 @@ public class HitObjectLifetimeEntry : LifetimeEntry

private readonly IBindable<double> startTimeBindable = new BindableDouble();

internal event Action? RevertResult;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a touch awkward in terms of event flow, but I can't immediately see a way out of it.

peppy
peppy previously approved these changes Jan 25, 2023
Copy link
Member

@peppy peppy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I am on board with this change.

@peppy peppy requested a review from smoogipoo January 25, 2023 08:44
@bdach bdach self-requested a review January 25, 2023 10:06
@smoogipoo
Copy link
Contributor

At a high level, this looks fine to me. The concerns above are quite valid though.

@ekrctb
Copy link
Collaborator Author

ekrctb commented Jan 27, 2023

Separate question, should MaximumJudgementOffset be applied for the negative direction also? It makes more sense if this property is used for lifetime purpose #22292.
i.e. Clamp(TimeOffset, -MaximumJudgementOffset, MaximumJudgementOffset) instead of Min(TimeOffset, MaximumJudgementOffset)

It is not needed anymore as TimeAbsolute is stored raw.
@bdach
Copy link
Collaborator

bdach commented Jan 28, 2023

Separate question, should MaximumJudgementOffset be applied for the negative direction also?

I had that thought too when reading the code and I'd probably say that it should, but refrained from pointing it out because I didn't want to scope creep this PR.

@peppy peppy self-requested a review February 15, 2023 05:46
/// <remarks>
/// This is used instead of <see cref="TimeAbsolute"/> to check whether this <see cref="JudgementResult"/> should be reverted.
/// </remarks>
internal double? RawTime { get; set; }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In terms of naming, my only alternative proposal here would be

RawTime -> Time
TimeAbsolute -> ClampedTime

Both have roughly the same number of usages, so I'm not sure about which should get a non-suffixed/prefixed name. But in general I dislike naming with words that have unclear meanings (like Raw or Base or Real).

Copy link
Collaborator

@bdach bdach Feb 16, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ClampedTime is pretty ugly name for a public property to have. I'd argue the reverse and keep public TimeAbsolute but do internal UnclampedTime. Rationale is that the ugly name is contained to internal members I suppose?

Copy link
Collaborator Author

@ekrctb ekrctb Feb 19, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not clear having clamped time in JugementResult should be the way forward (why do we have judgements with out-of-bound time offsets in the first place?) so let's not name it ClampedTime for now (go with RawTime and TimeAbsolute).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, i'm okay with no change if that's deemed better. We can see how it plays out.

Copy link
Member

@peppy peppy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apart from naming, I'm pretty happy with this direction now.

@bdach bdach self-requested a review February 19, 2023 13:02
@bdach
Copy link
Collaborator

bdach commented Feb 19, 2023

I can agree with what this pull is doing, I don't see much wrong in what it's doing, and it will also fix other issues in the process (like #17482). Doesn't make the change any less scary, mind, but yeah. Way I see it it'll all either go perfectly or we'll have to revert this in a week. But probably worth a go regardless?

@bdach bdach removed the request for review from smoogipoo February 19, 2023 15:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Hit objects may disappear in the osu!mania editor
4 participants