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

[BUGFIX] Sustains now give consistent scores [+ songScore as Float] #3832

Open
wants to merge 3 commits into
base: develop
Choose a base branch
from

Conversation

xenkap
Copy link

@xenkap xenkap commented Nov 5, 2024

Does this PR close any issues? If so, link them below.

N/A

Briefly describe the issue(s) fixed.

Sustain notes previously did not consistently give score-- it was all dependent on how long you held it for, regardless of when you started holding, disconnected from the actual length of the note. This caused sustains hit earlier to reward more points than sustains hit later, as well as other undesirable effects. This behavior is now fixed.

These demonstrations are done with a script that disables regular note scoring, leaving only sustain scores to count.

Before:

2024-11-05.22-25-03.mp4

After (VIDEO SLIGHTLY OUTDATED, 100% FIXED NOW):

2024-11-05.23-52-00.mp4

This PR places scoring behavior in Strumline, which may be undesirable.
An alternative approach would be to add a variable in SustainTrail.hx that tracks PlayState's last read on it, and then performing logic where it used to be done anyway. I tried this, but it didn't exactly work out...

This PR also changes songScore to be a Float, and all score-related scripting variables to Float as well.
All saving and displaying of the score still uses the integer using songScoreInt.
Written with the assumption that #3708 will be pulled. If it isn't, removals of offset corrections will be required.

completely forgot a player check here
@github-actions github-actions bot added medium A medium pull request with 100 or fewer changes haxe Issue/PR modifies game code labels Nov 5, 2024
@xenkap
Copy link
Author

xenkap commented Nov 5, 2024

An alternative approach would be to add a variable in SustainTrail.hx that tracks PlayState's last read on it, and then performing logic where it used to be done anyway. I'll might make a separate branch for that later-- if I don't, well.

On second thought, this seems like the simpler approach. Working on it now
EDIT: Issues arise in the instance that sustainLength is positive one frame and negative the next. Nevermind then
(this wasn't even the issue i ran into-- for some reason, it just refused to give points outright... bwekh)

@Hundrec
Copy link
Contributor

Hundrec commented Nov 5, 2024

If done right, this could finally standardize scores across all attempts!
Please polish this up the best you can :)

Modders may want to modify sustain/input behavior, like in custom input engines or opponent mode scripts. Or other things.
@xenkap
Copy link
Author

xenkap commented Nov 6, 2024

If done right, this could finally standardize scores across all attempts! Please polish this up the best you can :)

Thank you!! I'm not sure what much else I can do on the topic of sustains, since it seems to be 100% accurate now.
But talking about standardized scores, I'm not very sure about the 5ms input window for a perfect score, haha
Although that might be reasonable in other rhythm games. Haven't ever seen one with that strict of a window, though

@xenkap
Copy link
Author

xenkap commented Nov 6, 2024

I just realized the after video shows me taking a score of 288 (goal: 275).
I've already fixed this, but since I recorded it before that, it doesn't appear so. Bwekh

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
haxe Issue/PR modifies game code medium A medium pull request with 100 or fewer changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants