Ordering of certain beatmap elements must be enforced

[peppy]

In order to ensure beatmaps are in a sane state, lists should be checked for correct ordering. Cases where this should be checked

• HitObjects should be in chronological order.
• Nested HitObjects should be in chronological order.
• DrawableHitObjects should be in reverse-chronological order where required (every ruleset so far).
• Nested DrawableHitObjects should be in reverse-chronological order where required (every ruleset so far).
• Events should be in chronological order.
• TimingPoints should be in chronological order.
• Samples should always start with the leading sample (ie. a HitNormal should come before any/all additions)

Using SortedList should also be considered where possible as a secondary measure to ensure order at runtime (ie. if the editor is modifying said lists).

[thomastanck]

What about 2B maps where a slider tick could be ordered before a circle (in an earlier slider) but need to be clicked after the circle? Is that already being checked?

[smoogipoo]

That is already being checked. At least at a Playfield level, DrawableHitObjects are ordered by their start times. i.e. the earlier slider will handle input until it's received all judgements possible for it, before the next DrawableHitObject begins handling input

Within DrawableHitObjects (i.e. between NestedHitObjects), this isn't being done, which is checklist item #4.

[smoogipoo]

In many cases (most/all), SortedList will be required, not just a consideration. For example, adding and removing HitObjects to a Beatmap should require no knowledge about the ordering of hitobjects, the same with storyboard events and samples.

At the moment, ordering for HitObjects is enforced only at a beatmap parsing level, which will not cover the editor.

[ticotaco72]

what is the state of this one?