Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for ruleset-specific blueprints in editor timeline #29973

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

OliBomby
Copy link
Contributor

RFC. This PR allows rulesets to customize how hit objects are represented in the timeline without having to modify the hit object classes or create additional interfaces.
The need for this has been expressed multiple times already in #29441 and #21566

The API is a bit limited because it expects objects of type TimelineHitObjectBlueprint which already defines all the layout and interactions. If more freedom is required, I think TimelineHitObjectBlueprint should not define layout and instead the parts of it should be split into separate classes which could be composited instead.

As an example I've implemented two ruleset-specific changes that make use of this API:

  • Sample points at the tail end of spinners
  • Disabled timeline in mania (as in stable)

The IHasDisplayColour interface can also be eliminated in favour of taiko specific timeline blueprints.

@OliBomby OliBomby changed the title Allow ruleset-specific blueprints in editor timeline Add support for ruleset-specific blueprints in editor timeline Sep 23, 2024
Comment on lines +172 to +173
[CanBeNull]
public virtual TimelineHitObjectBlueprint CreateTimelineBlueprintFor(HitObject hitObject) => new TimelineHitObjectBlueprint(hitObject);
Copy link
Collaborator

@bdach bdach Sep 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're going to go and say that it's fine for the timeline to look differently on different rulesets, then I can already tell you that this API is too constrained and we'll need a higher-level primitive anyway to replace the entirety of the timeline.

Why, you ask? One of the most frequent pieces of feedback on scrolling rulesets (taiko and mania) are that scroll speed changes should be visible on the timeline. And osu!'s displays above hitobjects do not make sense there because that's not how speed changes work on those rulesets - they affect the entire playfield. So they should probably look closer to the red timing change markers.

So I think this sort of thing is too short-sighted and we'll have to tear it out sooner than later anyway. Not opposed to the idea, yet wholly opposed to this execution.

@bdach
Copy link
Collaborator

bdach commented Sep 24, 2024

The above comment notwithstanding I'm gonna need @peppy cross-check on this, since I vividly remember him being vehemently opposed to the notion of per-ruleset deviations of any sort on the timeline, although I cannot find the paper trail for this. I think it must have been somewhere around when we started to implement this editor design. I think it could have been in stream twitch chat or something...?

@bdach bdach requested a review from peppy September 24, 2024 10:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants