[Nitpick] LastSecondHint fix has been handled wrongly (?)

Game Mode

No response

Give an example of what is wrong

I downgraded this issue to a nitpick as I STILL haven't fully grasped the full scope of the fix... There are multiple things wrong... It might even be a [Nitpick|Bug|Feature Request] by the looks of it.

If I remember correctly, I've read in your discord that you guys wanted to fix PIU's incorrect song length (going for minutes/hours longer than intended) with the length of the music file itself. This seemed right but really isn't the way to go (example listed way down below). But somehow, while trying to fix it your way, some other things somehow seemed to have gotten handled the wrong way.

I was actually about to pitch a fix for this about two weeks ago but I stopped because I remembered there being an update incoming. I wanted to wait for it to make sure if it's still the case, I maybe should have done this WAY sooner. My planned fix is mentioned down below (one for 0.4.14 and one adjusted for 0.4.15). But before that, I'm going to display my findings on what broke and why it even broke.

What I found wrong so far:

Wrong Song.LastSecond:

I somehow noticed that during caching, it seems like that the last Step:LASTSECONDHINT gets used as the Song:LastSecond

E:\Project OutFox\Cache\Songs\Songs_00-PIU XX_(00) 1613 - Mr. Weq - Sugar Plum.ofcache
#LASTSECOND:0.000000;
#LASTSECONDHINT:113.787064;
#LASTSECONDHINT:114.138832;
[...]
#LASTSECONDHINT:113.434303;
#LASTSECONDHINT:113.448540;
#LASTSECONDHINT:0.140000; <- DP99 that uses X/Y instead of 1/2/4

E:\Project OutFox\Cache\Songs\Songs_00-PIU XX_(00) 1640 - t+pazolite+Ginkiha+Hommarju - Crossing Delta.ofcache
#LASTSECOND:42.393337;
#LASTSECONDHINT:106.726685;
[...]
#LASTSECONDHINT:106.731880;
#LASTSECONDHINT:112.726761;
#LASTSECONDHINT:0.060000; <- another DP99 with XY
[...]
#LASTSECONDHINT:42.393337; <- another DP99 but it broke halfway because of {y|h|0|0}

E:\Project OutFox\Cache\Songs\Songs_00-PIU XX_(02) 1660 - GFRIEND - Time for the moon night.ofcache
#LASTSECOND:236.873993;
#LASTSECONDHINT:118.639709;
[...]
#LASTSECONDHINT:118.639709;
#LASTSECONDHINT:236.873993; <- DP99 but ends with 1 BPM going towards some fake notes

But this is not only the case for pump stuff

E:\Project OutFox\Cache\Songs\Songs_In The Groove_Euphoria.ofcache
#LASTSECOND:0.000000;
#LASTSECONDHINT:119.209572;
[...]
#LASTSECONDHINT:119.209572;
#LASTSECONDHINT:inf; <- lights-cabinet. And since it's NAN, it's basically zero

Wrong Step.LastSecondHint:

I've also found moments, where the "set actual songlength as the maximum" approach didn't seem to work out.

E:\Project OutFox\Cache\Songs\Songs_00-PIU XX_(00) 1630 - Garlic Squad - Kimchi Fingers.ofcache
#MUSICLENGTH:111.972000;
#LASTSECOND:111.969482;
#LASTSECONDHINT:111.969482;
[...]
#LASTSECONDHINT:111.969482;
#LASTSECONDHINT:230.073730; <- pump-routine which somehow has P1's steps at the start but P2's steps were put at the end
#LASTSECONDHINT:111.969482;

This actually play out normally like before the fix. But it should have ended realy because of the set MUSICLENGTH.

Wrong Song.MusicLength:

Yes, I'm finally going into this. Remember what I remember you said you were going to do to fix the broken song length? Well... This is one example of it making it obvious that it's not the way to go.

E:\Project OutFox\Cache\Songs\Songs_Mungyodance 1 (Non-VULPvibe Edition)_Obelisk.ofcache
#MUSICLENGTH:313.027008;
#LASTSECOND:106.666664;
#LASTSECONDHINT:106.666664;
#LASTSECONDHINT:105.777779;
#LASTSECONDHINT:106.666664;
#LASTSECONDHINT:106.666664;

As you can see, all Steps end at around the same time as well as way early than the song length. But here, one has to wait for 200 seconds for the song to conclude.

I would also like to mention what I've seen in one of those cached songs with the broken song length DURING 0.4.14.x:

E:\Project OutFox\Cache\Songs\Songs_00-PIU XX_(02) 1641 - LUCY - Jogging.ofcache
#FIRSTSECOND:1.033628;
#LASTSECOND:99000128.000000;
#MUSICLENGTH:99000128.000000;

The MUSICLENGTH is unlike the actual length of the music file (might either have been set incorrectly or had been accidentally overwritten). And the LASTSECOND seemed to have fully ignored the LASTSECONDHINT assigned to it (since it's a PIU file with it being set on song level)

Give an example of what it should look like

What I had in mind for 0.4.14.x:

if LASTSECOND > LASTSECONDHINT then LASTSECOND = LASTSECONDHINT end

I actually noticed that LASTSECONDHINT hadn't been cached before at all if it had been set. Either that or it had been fully ignored internally. (This would have made this issue a Bug report)

Now for 0.4.15:

local TRUELASTSECOND = hasLASTSECONDHINT() and LASTSECONDHINT or MUSICLENGTH
if LASTSECOND > TRUELASTSECOND then LASTSECOND = TRUELASTSECOND end

Add Steps:getLastSecondHint() to lua because of the broken LASTSECOND (since the breaking cases above breaks functionality I had in mind with LASTSECOND itself) And let the game end on LASTSECONDHINT this time since this value would have been internal only in 0.4.14.x, which would actually be fine. (This would have made this issue a Bug report AND a Feature Request)

TeamRizu / OutFox