5572 Commits

• Merge pull request #33615 from bdach/slider-encode-decode-instability

  Fix lack of slider encode-decode stability due to truncating control point coordinates on decode

  Dan Balasescu · 2025-06-26 23:25:36 +09:00
  ae3100af11
• Remove no longer used method
  Dan Balasescu · 2025-06-25 18:31:35 +09:00
  d42fcabcf4
• Make assertion completely dead in release mode
  Bartłomiej Dach · 2025-06-25 10:06:04 +02:00
  55ff5a744c
• Refactor hit windows class structure to reduce rigidity

  This change pulls back a significant degree of overspecialisation and
  rigidity in the class structure of `HitWindows` to make subsequent
  changes to hit windows, whose purpose is to improve replay playback
  accuracy, possible to do cleanly.
  
  Notably:
  
  - `HitWindows` is full abstract now. In a few use cases, and as a
    reference for ruleset implementors, `DefaultHitWindows` is provided as
    a separate class instead.
  
    This fixes the weirdness wherein `HitWindows` always declared 6 fields
    for result types but some of them would never be set to a non-zero
    value or read.
  
  - `HitWindow.GetRanges()` is deleted because it is overspecialised and
    prevents being able to adjust hitwindows by ±0.5ms cleanly which will
    be required later.
  
    The fallout of this is that the assertion that used `GetRanges()` in
    the `HitWindows` ctor must use something else now, and the closest
    thing to it was `GetAllAvailableWindows()`, which didn't return
    the miss window - so I made it return the miss window and fixed the
    one consumer that didn't want it (bar hit error meter) to skip it.
  
  - Diff also contains some clean-up around `DifficultyRange` to unify
    handling of it.

  Bartłomiej Dach · 2025-06-25 08:40:12 +02:00
  8b542e5442
• Merge branch 'master' into somewhat-less-weird-toolbar
  Bartłomiej Dach · 2025-06-24 14:16:00 +02:00
  7bea51556c
• Fix mod adjustment marker not masking correctly
  Joseph Madamba · 2025-06-16 22:46:13 -07:00
  f9bae1fe2f
• Remove per-frame check for transform
  marvin · 2025-06-11 09:48:51 +02:00
  e495843267
• Add comment explaining mouse position handling
  marvin · 2025-06-11 09:47:39 +02:00
  18979d0ed4
• Maintain scroll position relative to hovered drawable in ExpandingToolboxContainer
  marvin · 2025-06-10 21:31:32 +02:00
  cad389722e
• Fix lack of slider encode-decode stability due to truncating control point coordinates

  Mostly closes https://github.com/ppy/osu/issues/33505.
  
  Compare
  
  	https://github.com/ppy/osu/blob/97e6187f0d7c3dbee896596a623e34627135bf0e/osu.Game/Rulesets/Objects/Legacy/ConvertHitObjectParser.cs#L56-L59
  
  I say "mostly" here because I'm rather skeptical that this is 100% rock
  solid still, for one reason - namely that the game stores path control
  point coordinates relative to the head, then turns them into absolute
  coordinates when encoding, and then on decoding turns them back into
  coordinates relative to the head, which in floating-point world is a Bad
  Idea because of round-off error. But I'm not fixing that without
  introducing a completely new beatmap format or rewriting half the
  editor to address that, so I'll just pretend that I don't know any
  of this until someone notices.

  Bartłomiej Dach · 2025-06-10 14:09:13 +02:00
  eab02a2aa5
• Fix replays being misrecorded if an action is pressed and released in one update frame

  Closes https://github.com/ppy/osu/issues/33465 probably.
  
  This reverts the replay frame de-duplication logic to what it was before
  https://github.com/ppy/osu/pull/33148#discussion_r2091549388.
  
  I don't have good reproduction steps. I tried to write a test case for
  this that isn't just "press and release a key in the same frame",
  thinking that maybe there was some loophole in the osu! touch input
  mapper that may produce this situation artificially, but I could not in
  many configurations. So I have to assume that this just *can happen*
  organically.

  Bartłomiej Dach · 2025-06-06 09:10:51 +02:00
  12cc8e38da
• Disallow selected mods from being valid for freestyle as required mods due to them not being consistently compatible with other mods across rulesets

  Closes https://github.com/ppy/osu/issues/33444.
  
  The issue here is that for a set of required mods to make sense in the
  context of a freestyle playlist item, it must be consistently either
  valid or invalid *as a combination* across all four default rulesets,
  because freestyle also permits changing ruleset. There are two
  pertinent cases here:
  
  - Flashlight and Hidden are compatible in osu!, taiko, and catch, but
    not compatible in mania. In this case I've disallowed both mods
    because of symmetry, basically - I don't see one "better mod" to
    disallow here.
  
  - Accuracy Challenge and Easy are incompatible in osu!, catch, and mania
    (because the mod gives extra lives) there, but *compatible* in taiko,
    where it does not. In this case I've disallowed Accuracy Challenge
    only, because I find its value in being forced on a freestyle room
    to be much smaller than Easy's.
  
  In the large scale of things I don't see this being very important
  because my view is that 99% of the use case of required mods in
  freestyle is going to be changing the track speed. So I don't think
  anyone is going to care about this going away - but we can reassess if
  I'm proven wrong.

  Bartłomiej Dach · 2025-06-05 15:00:54 +02:00
  05496111d6
• Merge pull request #33259 from LumpBloom7/ruleset-agnostic-concurrent-check

  Make concurrent object check ruleset specific

  Bartłomiej Dach · 2025-05-26 14:33:41 +02:00
  f043a95dbd
• Make CheckConcurrentObjects.Run virtual

  And let implementers copy-paste common code.

  Derrick Timmermans · 2025-05-26 10:59:57 +02:00
  0495a03607
• Rename ConcurrentCondition to ConcurrencyPrecondition

  Better describes the intent of the method.

  Derrick Timmermans · 2025-05-26 10:59:17 +02:00
  257767b311
• Use null coalesce wherever possible

  Rider EAP being noisy about this one now.

  Dean Herbert · 2025-05-26 17:15:35 +09:00
  5450298468
• Remove redundant public specfications in interfaces

  Rider EAP being noisy about this now (smoogi will be happy :D).

  Dean Herbert · 2025-05-26 17:14:41 +09:00
  cb0592d711
• Make CheckConcurrentObject ruleset specific
  Derrick Timmermans · 2025-05-25 14:19:23 +02:00
  0065696248
• Merge pull request #33209 from bdach/mania-combo-accounting-rewind

  Fix combo accounting when rewinding mania replays

  Dean Herbert · 2025-05-23 16:47:36 +09:00
  fa92fbb9d1
• Fix editor player sometimes crashing because of instantiating wrong judgement result type for object

  Closes https://github.com/ppy/osu/issues/33231.
  
  I'm not sure how to reproduce the instances of this reported to sentry
  with `Drawable{Slider,Spinner}`, but this bug is about to be made worse
  by `DrawableHoldNote` in mania getting its own `JudgementResult` subtype
  in https://github.com/ppy/osu/pull/33194 - for that one to reproduce
  just start gameplay test while editor is seeked to a time instant where
  a hold note is mid-hold.
  
  There's possibly an argument here that `CreateResult()` should live on
  `HitObject` and not `DrawableHitObject`, and I'd even be partial to such
  an argument, but doing that would be a rather hard ruleset API break
  (albeit trivial one to resolve), and also may dredge up past
  conversations about `Judgement` and `JudgementResult` (cf.
  https://github.com/ppy/osu/pull/26563) that I would rather not get into
  again.
  
  Notably this is not source-breaking for rulesets. It may be
  binary-breaking, I haven't tested.

  Bartłomiej Dach · 2025-05-22 10:20:39 +02:00
  70c6ddbe30
• Adjust combo accounting in score processor to be order-agnostic

  Closes https://github.com/ppy/osu/issues/21732.
  
  While the problem of multiple judgements in one frame and ordering of
  `RevertResult()` calls as described in the issue is a real one, this
  commit is a bit of a sidestep of the entire issue.
  
  The idea here that while *snapshots* of instantaneous combo values are
  susceptible to such ordering foibles on revert, *deltas* are not - and
  such, when deltas are using to update the combo counts on revert,
  ordering stops mattering so much.

  Bartłomiej Dach · 2025-05-20 12:28:28 +02:00
  237de1ef72
• Also perform time-based frame de-duplication at frame bundle level

  See https://github.com/ppy/osu/pull/33148#discussion_r2092467082

  Bartłomiej Dach · 2025-05-16 09:39:29 +02:00
  baf069ccf7
• Do not emit multiple consequent replay frames with the exact same data

  With judgements occurring forcing emission of important frames, there's
  the question of emitting redundant frames. In a majority of cases
  still, a judgement *will* be tied to a specific user input, which means
  that there's a high likelihood of duplicate frames, as one will be
  emitted by the input change, and another by the judgement.
  
  To a degree this is a pre-existing issue. The replay recording code
  responds to both mouse movement and key presses by recording frames, so
  depending on the intrinsic (basically undefined) ordering between
  handling mouse move and key presses, it was possible for multiple frames
  to be emitted with the same timestamp to the replay, each containing
  partial input state changes (e.g. first frame with mouse position
  changed, and the second with a key pressed).
  
  The extent to which this increases the frame count will obviously depend
  on the beatmap, but in my ballpark testing across all rulesets on a
  single "relatively standard" beatmap (think no aspire chicanery), around
  4-10% of frames can end up being duplicates / not meaningful. This has
  implications both on replay size and on playback performance.
  
  This commit therefore performs de-duplication of the frames based on
  timestamp - only the last frame with a given timestamp ends up in the
  final replay.
  
  The CPU cost of this is negligible to the point of not being useful to
  profile - it's a single condition gated behind a single float comparison

  Bartłomiej Dach · 2025-05-16 08:40:07 +02:00
  cd4ab9307c
• Emit important replay frames on every judgement

  - Closes https://github.com/ppy/osu/issues/4287
  - Probably closes https://github.com/ppy/osu/issues/25405 (but not
    retroactively)
  
  Up until now, whether or not a replay frame is emitted depended solely
  on the user's input, i.e. mouse movement or key presses/releases. This,
  intersected with the replay playback system which is given allowance to
  perform interpolation between replay frames, leads to potential
  situations wherein a replay can play inaccurately when a judgement takes
  place without user input meaningfully changing. One such case is slider
  ends with their 36ms of judgement leniency; see
  https://github.com/ppy/osu/issues/25405#issuecomment-2879031106 for
  details on that.
  
  To that end, this commit aims to counteract that issue by *forcing* an
  important replay frame to be emitted on every new judgement recorded
  during gameplay. This will only benefit rulesets wherein judgements can
  occur that are not inherently tied to user input changing, which are
  going to be osu! as mentioned above, and maybe possibly catch. I don't
  foresee this doing anything relevant for taiko or mania.

  Bartłomiej Dach · 2025-05-15 11:43:09 +02:00
  9f91c2e25c
• Remove unnecessary replay recorder depth hack

  Addresses https://github.com/ppy/osu/pull/33102#discussion_r2087963889.

  Bartłomiej Dach · 2025-05-14 11:25:31 +02:00
  acebf3e95e
• Merge pull request #33104 from frenzibyte/adjust-pitch-tooltip

  Fix rate adjust / time ramp mods not showing "Adjust pitch" in tooltip

  Dean Herbert · 2025-05-13 15:11:26 +09:00
  cb59e5acbf
• Change implementation to match other implementations

  The previous version was confusing to read.

  Dean Herbert · 2025-05-13 15:10:59 +09:00
  7918685c4e
• Fix rate adjust / time ramp mods not showing "Adjust pitch" in tooltip
  Salman Alshamrani · 2025-05-12 15:14:26 +03:00
  9c77a3e74f
• Fix mod tooltip not handling settings changes to same mod instance
  Salman Alshamrani · 2025-05-12 15:04:51 +03:00
  d5be4bf8d4
• Allow any hit result for empty hit windows

  It's really going to return zero anyway even if given a "supported"
  one, so probably fine?

  Bartłomiej Dach · 2025-05-09 10:31:00 +02:00
  bf86878597
• Fix HitWindows.WindowFor() returning values for invalid results

  This fell out of my work on hit window-related replay issues. In my WIP
  branch (that is probably going to get PR'd as draft soon) I refactored
  `HitWindows` and found a few straggling test failures due to some places
  reading hit windows for results that were not actually supported by the
  underlying `HitWindows` implementations, leading to returning garbage
  (mostly zeroes).
  
  Importantly, there is one actual usage in game code with impact here -
  `TaikoModSingleTap` was attempting to read the hit window for MEH, when
  MEH was never actually a valid hit result in taiko (OK is). This was a
  result of a copy-paste oversight from osu!, specifically from
  
  	https://github.com/ppy/osu/blob/51cf835fb6300aca53b5b98143d606f64d7a4d49/osu.Game.Rulesets.Osu/Mods/InputBlockingMod.cs#L58

  Bartłomiej Dach · 2025-05-09 09:40:20 +02:00
  ceb58a1141
• Merge pull request #32970 from peppy/mod-icon-improvements

  Improve visibility of setting adjustments on mod icons

  Dean Herbert · 2025-04-30 17:21:12 +09:00
  373a74da4b
• Move UserAdjustedSettingsCount local to ModDifficultyAdjust in absence of other usages
  Dean Herbert · 2025-04-30 16:04:26 +09:00
  a397737476
• Fix adjustment marker not updating when settings' states change
  Dean Herbert · 2025-04-30 13:04:50 +09:00
  0c5193ba59
• Don't bother with localised implementation of AdjustedSettingsCount

  I was avoiding using reflection to save on overheads, but it's probably
  not worth it.

  Dean Herbert · 2025-04-30 12:58:40 +09:00
  babccca2bb
• Add xmldoc note explaining new flag is instantaneous state
  Dean Herbert · 2025-04-30 12:49:39 +09:00
  14d0565194
• Adjust colours to match icon better
  Dean Herbert · 2025-04-30 12:48:07 +09:00
  713fbfb2c8
• Show marker when settings are adjusted
  Dean Herbert · 2025-04-28 18:14:14 +09:00
  1e8d9b3482
• Show singular difficulty adjust modifications inline in mod icons
  Dean Herbert · 2025-04-28 16:58:16 +09:00
  c16514274d
• Simplify taglib interactions further
  Dean Herbert · 2025-04-28 15:52:31 +09:00
  40faa3fc99
• Add manual MIME type resolution for TagLib file creation
  Stedoss · 2025-04-28 13:38:38 +09:00
  c2efda20d7
• Merge branch 'master' into freestyle-mods
  Bartłomiej Dach · 2025-04-23 13:49:32 +02:00
  6da4e09717
• Fix rate adjust no longer showing the rate if custom

  "Accidentally" removed in 6e635f124a
  apparently.

  Bartłomiej Dach · 2025-04-18 14:03:32 +02:00
  5791375b38
• Improve IMod documentation
  Dan Balasescu · 2025-04-17 18:32:35 +09:00
  92267c8bb3
• Use IMod documentation where present
  Dan Balasescu · 2025-04-17 18:32:26 +09:00
  95cf4887e1
• Apply changes from reviews
  Dan Balasescu · 2025-04-17 02:19:31 +09:00
  64aafa4e4c
• Adjust property name
  Dan Balasescu · 2025-04-14 19:34:33 +09:00
  35ee4b6f24
• Only apply freestyle validation to required mods
  Dan Balasescu · 2025-04-14 19:34:21 +09:00
  b4c7d7f498
• Revert "Use median for statistic display"

  This reverts commit fa06643bb6.
  
  Revert "Remove mean hit error calculation"
  
  This reverts commit b3c578e545.

  Dean Herbert · 2025-04-11 02:12:40 +09:00
  ba5932c1dd
• Allow classic mod in freestyle
  Dan Balasescu · 2025-04-10 13:05:17 +09:00
  c6e368d3ea