Move Ignored properties into IBeatmap

[Ryooshuu]

Closes #20883

[bdach]

Context which isn't in the OP but should be, from discord:

• https://discord.com/channels/188630481301012481/188630652340404224/1103261923480453180
• https://discord.com/channels/188630481301012481/188630652340404224/1104423316887961650

[bdach]

So while I don't disagree with doing this in the first place (since I'm the one who suggested it), I don't think this goes far enough. At the least the same thing should also be done to CountdownOffset:

osu/osu.Game/Beatmaps/BeatmapInfo.cs

Lines 179 to 182 in b4a6470

	/// <summary>
	/// The number of beats to move the countdown backwards (compared to its default location).
	/// </summary>
	public int CountdownOffset { get; set; }

because it's weird that now half of the countdown info is in IBeatmap and half of it is in BeatmapInfo. But really, the same logic can be extended to everything in this #region.

If there is a time to move that stuff out of there, now is probably one of the best times to do so. @ppy/team-client would appreciate opinions on this matter.

If we do decide to move everything then it may be better to wrap all of that in some object rather than move everything to IBeatmap, because ProgressiveCalculationBeatmap is going to grow by quite a large margin if moving properties 1:1. But maybe that's fine.

[Ryooshuu]

I was afraid to remove it since I didn't want to cause any unnecessary Realm changes. Rethinking it now, I don't think it would cause many issues. I'll wait for a response from others, however.

I'm a bit curious however about how I would name the new class if we decide to go in this direction, I'm currently thinking of BeatmapDetails but I'm unsure if that'll stick.

[peppy]

#23432 strangely relevant here.

I agree with moving all of these out as a first step.

If we do decide to move everything then it may be better to wrap all of that in some object rather than move everything to IBeatmap, because ProgressiveCalculationBeatmap is going to grow by quite a large margin if moving properties 1:1. But maybe that's fine.

I think if anything it should be a separate interface, rather than a separate class.

[furiner]

I think if anything it should be a separate interface, rather than a separate class.

I decided to make a proper interface and a class called IBeatmapSettings so that it can be easily added to IBeatmap, and it condenses all of the options into one proper area without inflating the size of classes such as ProgressiveCalculationBeatmap with properties.

[furiner]

it appears as if master got forcefully improperly merged

[peppy]

what makes this a setting? as per my comment, i don't think this should be in a separate class.

maybe editorsettings could exist, but this is not that.

[furiner]

I believe Settings is the best term for these properties because they are all values that can be assigned and set by a medium such as the editor to a beatmap. The other only good term would've been Metadata, but that's already taken.

Furthermore, I also believe that taking the other properties from BeatmapInfo would be a good move as they are all in the same field.

[peppy]

Disagree.

Now there's IBeatmap.Settings, BeatmapInfo.UserSettings and then everything in between (ControlPoints are also "settings" but they aren't in settings --- where do you draw the line? What about BaseVelocity? A setting or a variable or something else? WHo knows.).

Strongly against adding a new usage of the raw term "Settings" anywhere liek this.

The only usage of settings I would be okay with is to move editor level settings into its own storage, separate from variables and properties which are used at gameplay runtime.

[bdach]

Agree that "setting" isn't good, and agree in principle with splitting an interface for this additional stuff. The biggest issue I have though is how to name that new interface (classic...)

Like... best I can think of is probably IGameplayBeatmapProperties or something? And that still sucks.

[furiner]

IBeatmapProperties is far better if we're going to keep the word "Properties".

[bdach]

Also what is happening with the history here, out of curiosity? There are two github users committing to one branch? How does that work?

[furiner]

There's nothing really stopping two people from collaborating on the same branch, and the pull request will reflect every commit any party creates to it; which is the entire gist to how maintainers can even push commits to branches on forks that aren't theirs.

Here, we're doing it because we're collaboratively working on the same exact issue; and will do so for most of our branches as we aim to share the same goals with furthering the progress of lazer on our own whims.

[bdach]

Ok, I thought that was a git misconfiguration or something. Carry on I guess.