Reaching 50000 score points doesn't always give a 1up when the score tally is skipped

[QuartzTS]

So, I edited the hud script so that I can skip the score tally sequence by the action or pause buttons are pressed, but for whatever reason, it won't always give a 1up when the score reaches 50000.. Sometimes it does, and sometimes it doesn't

8mb.video-Rsq-c9x659wC.mp4

8mb.video-mC4-5eVDS0ro.-.Trim.mp4

I used the Global.check_score_life({the total remaining points}) function for this, and the everything works fine except this part, so I feel like it might be cuz I'm using it in a wrong way or smth, especially since it works fine without skipping the tally sequence..

[DimensionWarped]

There's probably just some condition where we're forgetting to reset the 'score until free life' variable. This is minor and should be easy to solve.

[QuartzTS]

Didn't understand.. Can you elaborate? The only variable in the function is the scoreAdd parameter. Also, I didn't understand how the check even works.. maybe it's better to make a 1up counter like the one for the rings if the current method doesn't work well with the tally sequence being skipped?

[DimensionWarped]

Ok, so I haven't dug into this, so I can't explain it with authority, but imagine for a minute that we start out the engine doing something like setting a variable...

free_life_milestone = 50,000

And then the player gets their first 50,000 points and they get their life and we reset free_life_milestone to 100,000.

Now the player returns to the menu, they start a new game, they are back at 0 points right?

Now let's pretend that we forgot to reset the free_life_milestone value to 50,000. It's still 100,000. So the player hits 50,000 points and doesn't get anything for it.

That's the kind of thing I imagine has probably happened here. Not 100% sure, I'm just spitballing.

[DimensionWarped]

Alright, spent a little time looking into it... there are a couple different situations where we check if an extra life should be earned.

First is when a score object is created, Global.check_score_life is immediately called with the value of the score object.

Second is during the end of level score tally if you have either a time bonus or a ring bonus and those count up 100 at a time.

As for how this function works, it's...

func check_score_life(scoreAdd = 0):
	if fmod(score,50000) > fmod(score+scoreAdd,50000):
		life.play()
		lives += 1
		effectTheme.volume_db = -100
		music.volume_db = -100
		bossMusic.volume_db = -100

I'm finding the use of fmod instead of % here a little strange since there is no reason to treat this as a floating point value. Still, unless I'm mistaken this should probably be fine because what should happen is if the player is going to get a life then the fmod function will wrap around on the right side of the operand to a value much closer to 0 while the value on the left side of the operand is still whatever score was close to 50,000 prior to entering here.

So long story short is I don't really see where this bug might be coming from. The code seems fine. I guess if you got a whole bunch of points at once it could be an issue? Like if for instance you changed the code to add your whole end of level bonus to the score in one move and you had exactly 50,000 points worth of bonus then you wouldn't get a life because the two values would be equal. Keeping that in mind, I'd change this function to something more like...

func check_score_life(scoreAdd = 0):
    var score_before = score % 50000     # use fmod instead if for some reason you are ever going to have fractional points
    if score_before + scoreAdd > 50000:
        life.play()
        lives += 1
        effectTheme.volume_db = -100
        music.volume_db = -100
        bossMusic.volume_db = -100

So yeah, not sure what you are running into or why. I haven't seen it.

EDIT: On reviewing your video footage, it appears you added a way to skip the score count down and apply the score change all at once, so I bet I'm right on the money with that assessment. Just change your check_score_life function like I outlined above and I'm pretty sure it'll work 100% of the time.

[QuartzTS]

Hey, it works, except that it threw an error for using the % operand because the score is apparently treated as a float, probably due to the calculations in the hud script in the _add_score function or smth, so I used the fmod instead lol.. anyway, I also checked if the score addition is bigger than or equal to 50000 instead of bigger than only so that it works well with the other situations, aka the score tally sequence and the score object, which means that I have the code like this:

func check_score_life(score_add: int = 0):
	if fmod(score, 50000) + score_add >= 50000:
		add_life() # Yeah, I put the code for increasing the life counter along with playing the life sound in its own function for whatever reason..

Btw, I wanted to try replacing the old check with the one in the Player-Refactor, but this one already works well, so thanks..

Ok, so I haven't dug into this, so I can't explain it with authority, but imagine for a minute that we start out the engine doing something like setting a variable...

free_life_milestone = 50,000

And then the player gets their first 50,000 points and they get their life and we reset free_life_milestone to 100,000.

Now the player returns to the menu, they start a new game, they are back at 0 points right?

Now let's pretend that we forgot to reset the free_life_milestone value to 50,000. It's still 100,000. So the player hits 50,000 points and doesn't get anything for it.

Btw, that's what I meant with making a 1up counter.. also, the score actually doesn't reset when returning to the menu, so I made it reset when nextZone is set to the start scene

[DimensionWarped]

I guess I should have known fmod wasn't being used purposelessly, but I'm still annoyed that it wasn't just being treated as an int. We have no use for fractional scores...

[QuartzTS]

Well, like I said, it's treated as a float because of the score countdown in the hud script, mainly in the _add_score function.. btw, the rings are also treated as float when they count down when the player is super.. not to mention that the both score and rings variables are not even declared as anything, so Godot automatically decides that they're floats