Migrate playlist freestyle select screen to use SongSelectV2#36694
Migrate playlist freestyle select screen to use SongSelectV2#36694bdach merged 6 commits intoppy:masterfrom
SongSelectV2#36694Conversation
peppy
force-pushed
the
freestyle-select-update
branch
from
d349084 to
1cc2516
Compare
peppy
force-pushed
the
freestyle-select-update
branch
from
1cc2516 to
c7f5685
Compare
Of note, this test scene still doesn't use the new footer properly. Should these even be here? Maybe it's better to leave these real world flows to a `Navigation` style test so we're not dealing with weird test setups that kinda do something but don't... or maybe do it in three different ways (two footers present, three back buttons etc.) Dunno. But this kind of covers what I want (except it doesn't cover the new footer usage).
peppy
force-pushed
the
freestyle-select-update
branch
from
c7f5685 to
110f11f
Compare
| // Must be from the same set as the playlist item. | ||
| criteria.BeatmapSetId = beatmapSetId; | ||
| criteria.HasOnlineID = true; | ||
|
|
||
| // Must be within 30s of the playlist item. | ||
| criteria.Length.Min = itemLength - 30000; | ||
| criteria.Length.Max = itemLength + 30000; | ||
| criteria.Length.IsLowerInclusive = true; | ||
| criteria.Length.IsUpperInclusive = true; |
There was a problem hiding this comment.
You're probably gonna hate me for this but it's possible to bypass these using my last song select feature which is the scoping thing:
Screen.Recording.2026-02-18.at.14.53.03.mov
Unsure how much to care. The low effort resolution would be to make {ScopeTo,Unscope}BeatmapSet() virtual on SongSelect and override them to no-ops in this class. Maybe even add a SupportsScoping boolean and conditionally hide or disable the control.
There was a problem hiding this comment.
I think I prefer the SupportsScoping path. But also it's great that the failsafes still catch this, which makes it a lesser issue.
There was a problem hiding this comment.
As you say due to the safeties in place I'm fine leaving as is and fixing this later. Let me know what you wanna do here.
- The mods button should not be visible because it is not hooked up properly to actually work with selecting user mods. As written it would show (and feign the ability to modify) required mods on the playlist item. You could probably adjust the logic to make user mods controllable via this button but this is simpler for now. - The random and options buttons could perhaps remain, but they are of very limited use on this screen anyway. The previous iteration disabled all footer buttons altogether, so I'm just following precedent here mostly.
|
I've pushed one extra change (f9f927f). The primary reasoning for it was that the mods footer button was visible and appeared to be doing very incorrect things. Probably good to go otherwise. |
2 participants
One step forward.