-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
base: develop
Are you sure you want to change the base?
Conversation
|
If done right, this could finally standardize scores across all attempts! |
Modders may want to modify sustain/input behavior, like in custom input engines or opponent mode scripts. Or other things.
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. |
I just realized the after video shows me taking a score of 288 (goal: 275). |
did you work on this again? |
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.