Proposal: JUDGE+

[hadronyche]

A trainer setting to target a given judgerank. The target will be applied if it's harder than the loaded chart's judgerank.

E.g. if I want to practice normal judge and set the target to normal judgerank: all easy judge charts will load as normal judge.

(1) Beatoraja currently lets you proxy this via EXPAND JUDGE and does not class it as an assist if all values are <=100. However, while it's simple to toggle on and off in-game, it's tedious to calculate the numbers (take from iidx.org) and input the numbers, and have to go into the launcher when you want to change them. A simple drop-down box to select judgeranks will be much more convenient.

Careful consideration should be given to how and whether this should affect charthash. Changing the judgerank in a bms file does affect the charthash. However, since the behaviour described in (1) is allowed without any repercussions (i.e. ASSIST, charthash change), there is a case to be made for it to not (A). On the other hand, changing the chart hash will allow a separate tracking of scores on that judgerank (B). Scores on higher judgeranks are difficult to view outside of result, but can be shown with a message on chart load (e.g. EASY CLEAR, 4111 EX, 91.02% AAA)

I've not investigated how possible behaviours (A) or (B) are to implement, but I would appreciate thoughts on which you think would be better to build for. My guess is that it's simple to implement and changing charthash dynamically should naively store the score in the DB, though there may be a conflict wherein a chart path with multiple charthashes may have undesired behaviour.

[seraxis]

This is an interesting feature! I already have plans for implementing something similar, but before going into the details of that I'll address your proposal.

I'm really reticent to save scores with a different charthash. All of a sudden we start polluting the DB with charts that dont actually exist, and reimports/updates could corrupt the DB as DB entries expect to point to real files. That being said I think local score saving on charts with tighter judge values with NO PLAY lamp is acceptable (similar to how the Rate Modifier works currently), excluding any scores on judge values lower than that of the specified chart (e.g. NORMAL -> EASY, EASY but with larger good windows, etc.).

As for B it definitely works but it's kind of inelegant, I think using imgui with a separate DB might be a better solution, but personally I feel like what I suggested above is more practical. A possible other solution is adding a new hashmap field to ScoreData for possible extensions down the line, but as this may break drop-in compatibility with migrating users installs it has to be treated very carefully.

[hadronyche]

Agreed, saving the local score as NO PLAY seems like the most simple, elegant solution and leaves extensibility open down the line.

An additional consideration is that most IRs support manual submission (LR2oraja: Tachi, CinnamonIR), which would send scores previously limited to local DB saves. This currently affects the Rate Modifier (to my knowledge, untested), which raises a discussion in itself about how much to cater to IRs and how this would limit future features. The use of FREQ in LR2 and tighter judges by EXPAND JUDGE in raja are obvious and allowed to submit on their IRs, but novel features without any precedent or parallel will require discussion.

I haven't investigated this but applying something like LIGHT ASSIST may allow IRs to ignore these scores. Otherwise, your idea of a separate DB would avoid this issue or we could bring features in line with what IRs accept to send scores.