Until now, API requests sent to dummy API were just lost in the void. In most cases this somehow worked as expected, but any logic which is waiting on a request to finish will potentially never get a response.
Going forward, I'm not 100% sure that every `Wait` on a web response will have local timeout logic (I think there is a certain amount of assumption that this is being managed for us by `APIAccess`), so I've made this change to better handle such cases going forward. Now, rather than nothing happening, requests will trigger a failure via the existing exception logic rather than silently pretending the request never arrived.
This was an insidious regression from a3dc1d5. Prior to that commit,
`DrawableHoldNoteHead` had `UpdateStateTransforms()` overridden, to set
the hold note head's lifetime. When that method was split into
`UpdateInitialStateTransforms()` and `UpdateHitStateTransforms()`, the
lifetime set was moved to the former.
Unfortunately, that override served two purposes: both to set the
lifetime, and to suppress hit animations which would normally be added
by the base `DrawableManiaHitObject`. That fact being missed led to
`UpdateHitStateTransforms()` hiding the hold note head immediately on
hit and with a slight delay on miss.
To resolve, explicitly override `UpdateHitStateTransforms()` and
suppress the base call, with an explanatory comment.
This reverts commit f3faad74d5, reversing
changes made to 712e7bc7bf.
Several issues arose after migrating to 5.0, including, but possibly not
limited to, performance regressions in song select, as well as failures
when attempting to save beatmaps after metadata changes in the editor.
Fixes `InvalidThreadForMutationException`s that pop up when
disconnecting/reconnecting tablets during the game's operation. In those
cases the value change callback executes from an OpenTabletDriver
thread.
`SliderSelectionBlueprint.OnDeselected()` would expire the
`ControlPointVisualiser` on deselection, leading to its removal from the
blueprint and eventual disposal, but still kept a separate reference to
said visualiser in another field.
This could lead to that stale reference to a disposed child getting read
in `ReceivePositionalInputAt()`, crashing quite a ways down over at the
framework side on futilely trying to compute the bounding box of a
drawable with no parent.
