This is quite the footgun, and the resolution of this might end up being a sweeping change with large implications (from making EndTime/ Duration a bindable, to maybe even framework amendments), so I'm unassigning pending discussion how to handle this. But the container didn't know anything about that and didn't re-sort its children, so now BinarySearch() fails because the list is not properly sorted anymore.' IOW, at that point CompareTo(HitCircle, Slider) 0, so going by its implementation, it should now follow the hit circle (IOW, CompareTo(HitCircle, Slider) > 0). The slider has StartTime = EndTime = 0, and so the comparer resorts to reverse child ID, but with the arguments reversed once again, ends up placing the slider at index 0 and moves the circle to index 1. Assume the hit circle is already placed at index 0, and a slider placement is begun at the same time.One part of the bug is that the params to CompareReverseChildID are (I think) inverted, as that function already inverts them once, but the primary mistake here is that the comparer's result depends on fields that are mutated during the placement. IndexOf()/ SortedList.BinarySearch() to find the item, which falls back to the comparer. Remove() fail in this case, because that uses. The custom comparer makes framework-side.

Return i = 0 ? CompareReverseChildID( y, x) : i Fall back to end time if the start time is equal. Put earlier blueprints towards the end of the list, so they handle input first Protected override int Compare( Drawable x, Drawable y)

Osu lazer remove follow points