-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Conversation
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.
I think it would be good to add a test here which fails on |
Calculating from TimeOffset is bad because it loses precision. The result time won't change anymore even If `HitObject.GetEndTime()` changes later.
@smoogipoo interested in your high level thoughts on this change as well. |
{ | ||
base.Update(); | ||
|
||
if (Result != null && Result.HasResult) |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
At a high level, this looks fine to me. The concerns above are quite valid though. |
Separate question, should |
It is not needed anymore as TimeAbsolute is stored raw.
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. |
/// <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; } |
There was a problem hiding this comment.
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
).
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
).
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
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? |
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 andPlayfield.RevertResult
event is changed to removeDrawableHitObject
argument.