Hmm, I added the grace period that rounds it to 100 if you get over 99.75, hoping to remove that rng aspect so it would at least always be possible to get 100, but I never actually calculated if it actually was enough to do that. I guess it wasn't, oops! I was actually already planning to completely remove the fps cap in the next update, good to know I was right in doing that lmao. Ideally input would be separate from fps, but I'm not sure there's a good way to do that in godot.
If they're playing at 60fps (vsync, which I'm turning off in the update), and playing on a map where the tempo is 60 or 120 (there's probably a few, off the top of my head I know megalovania definitely is 120 for example), it's possible that could line up and always give you the chance to hit 100 (no idea if this works in practice, just theoretically). Then it's just hitting 60fps frame perfects, which is difficult, but definitely possible, especially in a rhythm game where you've got great timing queues from the music.
But also like, I don't think this is that serious lmao, this isn't a competition where it matters, there's no consequences here lol.
Viewing post in Deltarune: Lightners Live Plus comments
Scoring logic is indeed very inconsistent and fps based (I’m pretty sure hitting above 98 100% of the time isn’t even possible at 60 fps: 200/60 = 3.33 pixels per frame, 75 + (100 - 1.6 * 5) / 4 = 98, meaning there’s a 1.6 * 2 = 3.2 pixel window. (though this might be wrong if int() rounds the value, but I’m pretty sure it truncates)
Also, about the “bpm matches fps” theory, the desync variable should be making that impossible anyway, on my decently powerful laptop desync still jitters by around 3-5 ms every time it’s recalculated, which is more than enough to make a +100 improbable. I don’t have a pc to test this with right now but I doubt it’d jitter much less.
Though, for funsies I will assume that:
1. there are 9 notes in a row that could hit +100
2. the player is playing 60 fps
3. The player’s reaction time standard deviation is 16
4. The player’s spatial awareness is so great that they can attempt a hit in the exact middle of the +100 frame (yes, this is an advantage)
the player’s playing at 60 fps, meaning 16.66 ms per frame, they hit in the middle, meaning the range is ±8.33 ms
with SD = 16 ms, we calculate:
Z = 8.33/16 = 0.5208
putting this into the wonderful invention “calculator” we get P(-Z<x<Z) = 0.39752
9 times in a row, 0.39752^9 = 1 in 4000
Meaning if you ignore about half the game, 9 100’s in a row becomes somewhat believable
Though, honestly, I’m just ‘debunking’ this to prove to myself reading obfuscated code and rereading my math homework from last year for 3 hours was a worthwhile investment 😭 (and I am very bored), I highly doubt opgrhythm is actually lying
tl;dr: fix scoring pls
Ah yeah it does make sense that the desync mitigation system would stop the tempo sync from happening. Next update will remove the that, so it might work there. Although since it's also removing the framerate cap, it won't matter. Although unfortunately vsync cannot be turned off on browsers (not in chrome at least, there is technically a way to force it off using arguments on its shortcut, but that seems to break other stuff, the maps just don't play correctly at all for some reason despite them playing fine at unlocked framerates in the windows version?), so it'll be only for the downloadable build.
I get around 1800-2000fps when playing the downloadable version (with a 5600x and 4070), which equates to a frametime of about half a ms, so enough to fix it for me at least lol.