No issue thread for this again. Reported internally on discord:
https://discord.com/channels/90072389919997952/1259818301517725707/1320420768814727229
Placing this logic in the beatmap processor, as a post-processing step,
means that the new combo force won't be visible until a placement has
been committed. That can be seen as subpar, but I tried putting this
logic in the placement and it sucked anyway:
- While the combo number was correct, the colour looked off, because it
would use the same combo colour as the already-placed objects after
said break, which would only cycle to the next, correct one on
placement
- Not all scenarios can be handled in the placement. Refer to one of the
test cases added in the preceding commit, wherein two objects are
placed far apart from each other, and an automated break is inserted
between them - the placement has no practical way of knowing whether
it's going to have a break inserted automatically before it or not.
This is the secondary cause of https://github.com/ppy/osu/issues/28577,
because you could do the following:
- Have a break autogenerate itself
- Adjust either end of it to make it mark itself as manually-adjusted
- Remove all objects before or after said break
to end up in a state wherein there are no objects before or after a
break.
The direct fix is still correct because it is still technically possible
to end up in a state wherein a break is before or after all objects
(obvious one is manual `.osu` editing), but this behaviour is also
undesirable for the autogeneration logic.
