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

logical operators for random select filters #1

Merged
merged 4 commits into from
Dec 18, 2023
Merged

Conversation

MatVeiQaaa
Copy link
Contributor

@MatVeiQaaa MatVeiQaaa commented Dec 8, 2023

A feature to add logical operators to random select filters, particularly for keys with integer values. Implements "<", ">", "<=", ">=" and "&&" operations.

Normally, beatoraja as of 0.8.6 allows for fixed value keys in random select filters, such as "clear": 6, which would select a song with Hard-Clear lamp. It isn't possible to have it select from a range of values, such as 4-5, which would describe all songs with lamp ranging from Easy-Clear to Groove-Clear. This PR allows doing it as such:

{
        "name":"RANDOM EASY-GROOVE",
        "filter": {
            "clear": ">=4 && <6"
        }
 }

This has no effect on normal beatoraja behavior, otherwise. Everything that would work in upstream still holds, it only expands on it.

Copy link
Owner

@seraxis seraxis left a comment

Choose a reason for hiding this comment

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

Left some comments on the code, otherwise looks good to merge

core/src/bms/player/beatoraja/select/BarRenderer.java Outdated Show resolved Hide resolved
core/src/bms/player/beatoraja/select/BarRenderer.java Outdated Show resolved Hide resolved
core/src/bms/player/beatoraja/select/BarRenderer.java Outdated Show resolved Hide resolved
if (this.getFilter().get(key) instanceof Integer) {
Integer value = (Integer)this.getFilter().get(key);
if (scoreData == null) {
if (0 != value) {
Copy link
Owner

Choose a reason for hiding this comment

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

instead of doing this if you can return 0 != value directoly

Copy link
Contributor Author

@MatVeiQaaa MatVeiQaaa Dec 18, 2023

Choose a reason for hiding this comment

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

instead of doing this if you can return 0 != value directoly

I don't agree it would be the correct approach, as it would only make sense if entire style of this function would change from switch-like to independent branches, where each branch returns true or false by itself, without return true; in the end acting as default case. I could refactor it that way if you insist.

@seraxis seraxis merged commit bdfa191 into seraxis:main Dec 18, 2023
@MatVeiQaaa MatVeiQaaa deleted the main branch December 19, 2023 01:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants