Skip to content

Replace objectList by calculating reduced note count during processing#38200

Open
tsunyoku wants to merge 2 commits into
ppy:pp-devfrom
tsunyoku:kill-reading-object-list
Open

Replace objectList by calculating reduced note count during processing#38200
tsunyoku wants to merge 2 commits into
ppy:pp-devfrom
tsunyoku:kill-reading-object-list

Conversation

@tsunyoku

Copy link
Copy Markdown
Member

Seems like the most maintainable way to do this.

Using IBeatmap's HitObjects and keeping the old method doesn't really work as we want to improve support for mods where clock rate may vary per object, and using StartTime on the DHO itself is really the only way we can guarantee this.

currentStrain *= decay;
currentStrain += calculateAdjustedDifficulty(current) * (1 - decay) * skill_multiplier;

reducedDuration ??= current.StartTime + reduced_difficulty_duration;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

This is fine.... if we assert that this method is called in order on all hitobjects.

I don't like this assertion in the first place. Like why are we even doing a method call per object at that point? Why not just leave it up to each skill to iterate the whole beatmap?

Incremental processing? Is there still a guarantee that it always starts from object 0?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

These are all valid points but require a far grander restructure to do anything about (i.e. https://discord.com/channels/188630481301012481/380598781432823815/1521767266348302366).

My main goal here was to remove the shoddy objectList since storing an extra list for this felt especially silly. If you don't care enough about it that you'd rather leave it until further restructuring occurs then I can just close this.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I'm okay, if there's adequate inline commenting. See what I wrote about this previously. Any further changes need inline.

All of the assertions need to be listed. They can't only be uncovered in review follow-up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

2 participants