In order for the new star difficulty to be shown to users on the next
release.
catch's difficulty calculator version is not bumped because the only
catch change pending deploy is https://github.com/ppy/osu/pull/28353 and
that affects performance points only.
Closes https://github.com/ppy/osu/issues/29793.
I believe that the sequence of events that makes this happens is as
follows:
- User selects a range of objects. Some of those objects are off-screen,
and thus would be presumed to be not alive - except the blueprint
container forces them to remain alive, because they're part of the
selection.
- User moves the selection to another column, which is implemented by
temporarily removing the objects from the playfield, changing their
column, and re-adding them.
This sort of pattern is supposed to kick off the
`HitObjectUsageTransferred` flow in `HitObjectUsageEventBuffer` - and
it does... for objects that are *currently visible on screen* and thus
would be alive regardless of `SetKeepAlive()`. However, this does not
hold for objects that are off-screen - nothing ensures they are kept
alive again after re-adding, and thus they inadvertently become dead.
- Thus, this doesn't kick off the `BlueprintContainer` flows associated
with transferring objects to another column, and instead fires the
removal flows, which ensure that the off-screen objects that were
being moved are instead deselected.
I tried a few other options but found no better resolution than this -
calling `SetKeepAlive()` directly would require making it public, which
seems like a bad idea. There's really no good way to generically handle
this either, because it is the ruleset that decides that its way of
implementing this operation will be a removal and re-add of objects,
so...
We need a general method to do this amicably, such as an HUD target that flips the position of its children when the direction is flipped. Something to consider later.
Before I go with a hammer to redesign these, I want to remove stuff that
does nothing first.
Hard-breaks API to allow rulesets to specify an enumerable of custom
sections rather than two specific weird ones.
For specific rulesets:
- osu!:
- Stack leniency slider merged into difficulty section.
- osu!taiko:
- Approach rate and circle size sliders removed.
- Colours section removed.
- osu!catch:
- No functional changes.
- osu!mania:
- Special style toggle merged into difficulty section.
- Colours section removed.
Per the request of spaceman_atlas, the No Release mod is rewritten to
avoid modifications to DrawableHoldNoteTail. The approach is based
on that of the Strict Tracking mod for the osu!(standard) ruleset,
injecting the mod behavior by replacing the normal hold note with
the mod's variant. The variant inherits most bevaior from the normal
hold note, but when creating nested hitobjects, it creates its own
hold note tail variant instead, which in turn is used to instantiate
the mod's variant of DrawableHoldNoteTail with a new behavior.
The time a judgement is awarded is changed from the end of its
Perfect window to the time of the tail itself.
This commit adds a new osu!mania mod No Release that relaxes tail
judgements. The current implementation automatically awards Perfect
(or Meh if the hold note is broken midway) for a hold note tail at
the end of its Perfect window, as long as it is held by then.
Tests are pending for the next commit.
Hopefully closes https://github.com/ppy/osu/issues/28284.
As far as I can tell this is a somewhat difficult one to reproduce
because it relies on a specific set of circumstances (at least the
reproduction case that I found does). The reset to frame 0 would
previously be called explicitly when `isHitting` changed:
182ca145c7/osu.Game.Rulesets.Mania/Skinning/Legacy/LegacyBodyPiece.cs (L144)
However, it can be the case that `bodyAnimation` is not loaded at the
point of this call. This is significant because
`SkinnableTextureAnimation` contains this logic:
182ca145c7/osu.Game/Skinning/LegacySkinExtensions.cs (L192-L211)
which cannot be moved any earlier (because any earlier the `Clock` may
no longer be correct), and also causes the animation to be seeked
forward while it is stopped.
I can't figure out a decent way to layer this otherwise (by scheduling
or whatever), so this commit is just applying the nuclear option of just
seeking back to frame 0 on every update frame in which the body piece is
not being hit.
