962 Commits

• Fix subscription leak from composer reloads (#36828)

  The reproduction scenario for the subscription leak is as follows:
  
  1. Switch to a scrolling ruleset (anything but osu! from the standard
  ones).
  2. Select a beatmap to edit.
  3. Load the composer.
  4. Go to timing tab.
  5. Change a timing point.
  6. Go back to the composer.
  
  At this point, `EditorChangeHandler.OnStateChange` will have multiple of
  the same delegate in the invocation list.
  
  <img width="691" height="311" alt="Screenshot 2026-03-05 at 11 15 55"
  src="https://github.com/user-attachments/assets/57788341-9573-48f1-b360-f21036891081"
  />
  
  That in turn is caused by the fact that changing a timing point *does*
  incur a full reload of the composer via the following flow:
  
  
  https://github.com/ppy/osu/blob/15b6e28ebe888b1a87574891be1a0db3b04093b7/osu.Game/Rulesets/Edit/ScrollingHitObjectComposer.cs#L145
  https://github.com/ppy/osu/blob/64a29313a852d50095ae4b7ea8f22fde23aa634f/osu.Game/Screens/Edit/Editor.cs#L1137-L1145
  
  This flow is my "fault"; see https://github.com/ppy/osu/pull/28444. The
  reason why a full composer reload is used is not clear to my
  recollection at this time, but it is likely because it's just the least
  likely to fail. A smarter solution that wouldn't require a full reload
  would also entail checking that there exists a safe insertion point that
  allows replacing timing points in a way that will reflect everywhere it
  must. Including all of the `IScrollingAlgorithm` machinery and such.
  
  In general it is not uncommon in the codebase to not bother to clean up
  some event callbacks if it is implicitly or explicitly guaranteed that
  both objects bound by the callback will always get disposed in tandem at
  the same time. This *was* true with this particular flow to a point,
  which was until that full composer reload was implemented.
  
  <details>
  <summary>To address the elephant in the room</summary>
  
  Someone will inevitably notice https://github.com/ppy/osu/pull/36824
  which was a clanked pull request pointing out this leak. And then
  someone will inevitably call this "AI discrimination"! *Gasp!*
  
  So first of all, let me stop you right there. Yes, as far as I am
  _personally_ concerned, it is "AI discrimination". I invoke the full
  force of the Butlerian Jihad.
  
  The clank army's goal is to eradicate my job and make me work in an
  Amazon warehouse instead. Or, if not that, at least my job is to be rid
  of all remnants of fun I still get from it and for me to be reduced to
  that one guy from the meme "i guess we're doin circles now". You know
  the one.
  
  I resent this. You attack me directly. I do not perceive the need to
  meet you halfway or be civil.
  
  That said, I have too much respect for the users of this software to
  leave reports of potentially real issues unchecked. So I did check, and
  it was real. And you know what? Good job to the clanker. It did what it
  was designed to do: it parsed a code file, recognised a hole in a
  pattern it was designed to recognise, and invoked forms of language
  given to it to communicate this to the meatbag that opened that PR.
  
  And here's the thing: my primary issue is with that meatbag that opened
  that PR. That meatbag served no functional purpose in any of this. The
  meatbag took a hose that spews 90% water and 10% raw sewage at random
  intervals and pointed it at my house directly, claiming that they just
  want to clean it. At no point did the meatbag appear to have the common
  decency to pull out a container, pour some magic liquid out, check if
  there's sewage in it, and filter it out if there is any. But no, that
  would take *effort* and *thought*, would it not? The *effort* and
  *thought* that is required of *me* to *review* the clanker's work?
  
  The PR had no reproduction scenario, and had testing checkboxes that
  were presumably meant for *me* to check off. Why is it *my* job to
  figure all of this out rather than the submitter meatbag's?
  
  I do *not* have obligations towards spew-hose-pointing meatbags. Point
  that hose at your own backyard at your peril.
  
  If you *actually manage* to get the clanker to filter out *all* of the
  spew without fail itself, my only win condition is gone. But it is not
  yet that time. So at least have the decency to check for the spew
  yourself, rather than telling the clanker to put checkboxes in the PR
  descriptions telling *me* to check for it.
  </details>

  Bartłomiej Dach · 2026-03-05 22:37:50 +09:00
  43897457fb
• Improve usability of sample bank toggles (#36753)

  - [x] Depends on https://github.com/ppy/osu/pull/36741 for merge
  conflict avoidance
  
  RFC, cc @OliBomby
  
  ## [Adjust behaviour of automatic bank assignment during
  placement](https://github.com/ppy/osu/commit/547f55e9b3ded668fe6e1c8865a2d625e64a2f45)
  
  Diatribe time!
  
  This is fallout of the discussion about auto bank in
  https://github.com/ppy/osu/issues/36705.
  
  Auto bank in lazer as written before this commit is confused. On stable,
  auto bank is closer to "no bank", as in "go look up the current sample
  timing point, get the bank of that, and use that". lazer has no timing
  points anymore, but people still want auto bank. So what do?
  
  Auto bank for normal samples is somewhat sane still. It only works
  during placement, and will just copy the normal bank of the previous
  object - if one exists. That said, one *might not* exist, but the
  resulting object will still have its normal sample created with
  `editorAutoBank: true`. That is largely cosmetic and without
  consequences, but this commit fixes that.
  
  Auto bank for *addition* samples, however... Hoo boy.
  
  - For placed objects, auto bank means "take the normal sample, read its
  bank, and use that". Simple enough, right?
  - Hoooooowever. During placement, auto bank before this commit used to
  mean "look at the *previous object*, check if it has an addition sound
  and then use its bank, if not use *the previous object's* normal sample
  and then use its bank" which is a completely different thing with its
  own implications. Like, say, what happens if the previous object uses
  the auto addition bank too? What should be copied over? Should it be the
  notion of "auto bank" in that the addition bank should match the normal
  bank, or should it be the literal bank that the previous object is
  using?
  
  This change attempts to define this unambiguously. "Auto additions bank"
  means "the same bank as the normal bank of this object", full stop.
  
  ## [Do not touch sample toggle state if there are no selected
  objects](https://github.com/ppy/osu/commit/052cde5987e48800ec68ab2528c7e0ce3140e6e0)
  
  Fixes issue described in
  https://github.com/ppy/osu/issues/36705#issuecomment-3953917163 wherein
  opening a sample popover will disable addition bank toggles and toggle
  off all addition samples.
  
  ---------
  
  Co-authored-by: Dean Herbert <pe@ppy.sh>

  Bartłomiej Dach · 2026-02-26 15:18:29 +09:00
  7e2771c3f0
• Fix toasts showing "no key bound" for operations which can't have keys bound

  Supersedes and closes https://github.com/ppy/osu/pull/35781.
  Closes https://github.com/ppy/osu/issues/36294.

  Dean Herbert · 2026-01-15 17:52:30 +09:00
  b4ba327c1c
• Fix editor crashing on undoing after hit object placement

  Happens when initial timing is undone.
  
  Regressed in
  https://github.com/ppy/osu/commit/12170df80add87e8f292545f67566f8d25465efc.
  Closes https://github.com/ppy/osu/issues/36228.

  Dean Herbert · 2026-01-05 15:26:14 +09:00
  9916e5bb1c
• Merge branch 'master' into custom-sample-set-selection
  Dean Herbert · 2025-12-17 19:30:24 +09:00
  61bf68f336
• Add basic colour indication as to when placements are valid

  Unsure about this one, but I find the preceding commit to be very
  lacking in explaining to the user why the editor don't work. Shining
  some things red may help aid understanding.

  Bartłomiej Dach · 2025-12-04 14:37:56 +01:00
  c6cc92315c
• Disallow placing hit objects before first timing point

  Because they can break stable. See
  https://github.com/ppy/osu/issues/31591#issuecomment-3575270120 for
  detailed rationale.

  Bartłomiej Dach · 2025-12-04 14:15:52 +01:00
  12170df80a
• Merge pull request #35757 from peppy/settings-wank

  Adjust settings buttons and general section to feel better

  Bartłomiej Dach · 2025-11-25 08:46:00 +01:00
  9e3486d4e6
• Reduce abstractions of rounded button
  Dean Herbert · 2025-11-25 00:55:42 +09:00
  b0762fc8ec
• Adjust element spacing in editor toolboxes
  Bartłomiej Dach · 2025-11-19 13:38:34 +01:00
  397041099e
• Use new sliders-with-text-input in editor toolboxes

  Addresses https://github.com/ppy/osu/discussions/35732.
  
  And yes, I renamed "perfect curve threshold" to "bias" so that the text
  can fit. Sue me.

  Bartłomiej Dach · 2025-11-19 13:22:20 +01:00
  4b59a4657f
• Inherit sample set info from previous object on placement
  Bartłomiej Dach · 2025-10-24 12:09:30 +02:00
  511921c1f7
• Handle disabled text in composition tool button
  Derrick Timmermans · 2025-09-26 09:28:04 +02:00
  c66cc5ebb1
• Fix composition tool tooltip not changing text when enabled
  Derrick Timmermans · 2025-09-25 10:44:05 +02:00
  df795da070
• Merge pull request #34667 from Hiviexd/verify/exclude-audio-from-hs-check

  Exclude all beatmap audios from the hitsounds format check

  Bartłomiej Dach · 2025-08-19 14:33:35 +02:00
  3b49673e83
• Merge pull request #34666 from Hiviexd/verify/check-inconsistent-audio

  Add verify check for inconsistent audio usage

  Bartłomiej Dach · 2025-08-19 14:33:13 +02:00
  b1296b0c83
• more correct hashset usage
  Hivie · 2025-08-15 14:41:59 +01:00
  0bcf29304b
• Rename variables
  Bartłomiej Dach · 2025-08-15 10:21:50 +02:00
  5722e85791
• exclude all beatmap audios from the check

  - prevents false positives on maps with multiple audios

  Hivie · 2025-08-15 00:11:16 +01:00
  7b455efe34
• add check for inconsistent audio usage
  Hivie · 2025-08-15 00:08:55 +01:00
  148bc4ac34
• handle pairwise comparison for video start times
  Hivie · 2025-08-14 13:14:58 +01:00
  f928f9953b
• add verify check for video usage
  Hivie · 2025-08-13 20:26:46 +01:00
  e52a4638fe
• add util for getting storyboard video of a difficulty
  Hivie · 2025-08-13 20:26:26 +01:00
  79fcd045b3
• Clean up ctors

  There were too many of them, and they were a bit twisty for my liking.

  Bartłomiej Dach · 2025-08-13 12:32:17 +02:00
  19f28813a0
• Expand xmldoc
  Bartłomiej Dach · 2025-08-13 12:24:40 +02:00
  076d6df78e
• use Prepend to resolve dotnet code style test
  Hivie · 2025-08-11 17:07:03 +01:00
  db1465ffdd
• fix missing param
  Hivie · 2025-08-11 16:48:52 +01:00
  c1a7285b8c
• one more constructor for tests that don't need a specified InterpretedDifficulty
  Hivie · 2025-08-11 16:48:25 +01:00
  c8cb167dbc
• more check refactors to cover the context changes
  Hivie · 2025-08-11 16:05:52 +01:00
  fb61f00466
• add backwards-compatible ctor that allows creating context from a given working and playable single beatmap

  more productive than adjusting every single test

  Hivie · 2025-08-11 15:40:25 +01:00
  f0ca3304b8
• initial pass on updated verifier context usage across most checks
  Hivie · 2025-08-11 14:57:14 +01:00
  fd6cf680b9
• rework and improve BeatmapVerifierContext strtucture

  - uses ` VerifiedBeatmap` record for combining working and playable beatmaps
  - much better data access with all beatmapset diffs

  Hivie · 2025-08-11 14:56:35 +01:00
  cfb9649993
• handle single difficulty case more efficiently
  Hivie · 2025-08-09 14:14:51 +01:00
  eba31ab203
• Merge branch 'ppy:master' into verify/refactor-verifier-context
  Hivie · 2025-08-09 13:48:29 +01:00
  1c9e30429f
• add working beatmapset difficulties to verifier context
  Hivie · 2025-08-09 13:13:47 +01:00
  2559c7ac8b
• pass on BeatmapManager directly
  Hivie · 2025-08-09 11:59:20 +01:00
  172a48f1ac
• Merge branch 'master' into verify/check-inconsistent-settings
  Bartłomiej Dach · 2025-08-07 06:57:32 +02:00
  39ad5ecd79
• refactor verifier context to use a static factory method for creating instances with beatmap resolution
  Hivie · 2025-08-07 01:52:50 +01:00
  c5f4feb725
• Use strongly-typed equality comparer rather than using object equality comparer

  `EqualityComparer<object>.Default()` will be slow, will fall back to
  `object.Equals()` which may do the right thing, the wrong thing, or be
  useless due to using reference equality semantics.
  
  In practice in this call site it likely doesn't matter anyway but I'd
  rather be future-proof than not.

  Bartłomiej Dach · 2025-08-06 18:26:41 +02:00
  c2a85032a6
• only check widescreen bool when storyboard is present

  matches MV

  Hivie · 2025-08-06 14:57:42 +01:00
  92fda5c2b9
• move storyboard presence check to shared utils
  Hivie · 2025-08-06 14:55:20 +01:00
  9b53d340af
• refactor comparison and use actual object type for field selectors
  Hivie · 2025-08-06 14:04:18 +01:00
  7f886f7534
• fix tests
  Hivie · 2025-08-06 13:06:59 +01:00
  899719e874
• mark timing checks as set-level
  Hivie · 2025-08-06 11:42:57 +01:00
  af8b133019
• use current beatmap as reference

  to be consistent with other checks that follow similar logic

  Hivie · 2025-08-06 11:42:40 +01:00
  f2953652a1
• add check for inconsistent settings
  Hivie · 2025-08-06 11:29:22 +01:00
  3cd6734c10
• use already-existing framework extension method
  Hivie · 2025-08-06 08:42:19 +01:00
  2127b6ca4e
• cleaner definition

  Co-authored-by: Bartłomiej Dach <dach.bartlomiej@gmail.com>

  Hivie · 2025-08-06 08:40:34 +01:00
  82f619a58a
• refactor and reduce duplication
  Hivie · 2025-08-06 07:42:40 +01:00
  03b6f35946
• add check for missing genre/language tags
  Hivie · 2025-08-05 23:02:48 +01:00
  f5c6c086ad