[BUGFIX] Sustains now give consistent scores [+ songScore as Float] #3832
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.