[BUG] Hunger Rate Inconsistencies #19

New issue

Closed

opened 2021-12-28 09:39:44 -04:00 by ZAdamMac · 1 comment

ZAdamMac commented

2021-12-28 09:39:44 -04:00

(Migrated from github.com)

From main.c, we have the main program loop which triggers roughly 2 Hz:

    while (1){
        PMM_unlockLPM5();
        GAME_evaluateTimedEvents(); // < - this is relevant
        Update_Button_States();
        SCENE_updateDisplay();
        ToggleVCOM();
        __bis_SR_register(LPM0_bits | GIE);
    }

Then from the game_manager.c source code:

    if (current_seconds == 0){ // At the round minute, we need to check for these several functions, none of which actually exist yet.
        GAME_NEEDS_evaluateHungerFun(current_minutes);

So, every minute, if the RTC says we're at zero seconds past the minute (the first second of the minute), we call the hunger-fun func.

That func is a funky func which takes the "rateHF" property, figures out the hunger and fun degredation rates as values from 0 to 15, and does whacky math to work that out into a rate of "number of points by which to degrade hunger or fun in a 15 minute period"

TECHNICALLY, therefore, there is no bug. In a 15 minute period, with a hunger-decay rate of 15, you'll lose 15 points of hunger in any situation. Like god intended.

BUT, there is a very narrow condition where the per-minute decay rate doubles, because the main program loop is being triggered by a register of Timer A0 and the check to run the evaluator is being governed by the RTC's seconds register. Technically both are being fed by the system clock, but since one can interrupt and the other can't, they drift into and out of alignment.

If they're fully aligned and the heartbeat rate in A0 is actually 2hz (it's only ROUGHLY) 2hz for reasons, you could briefly experience per-minute hunger rates of 2 points per minute in the above scenario. If you somehow maintained that state for a full 15 minutes you could even double the rate-that-matters, but that should be VIRTUALLY IMPOSSIBLE given the state of the clock.

From main.c, we have the main program loop which triggers roughly 2 Hz: ```c while (1){ PMM_unlockLPM5(); GAME_evaluateTimedEvents(); // < - this is relevant Update_Button_States(); SCENE_updateDisplay(); ToggleVCOM(); __bis_SR_register(LPM0_bits | GIE); } ``` Then from the game_manager.c source code: ```c if (current_seconds == 0){ // At the round minute, we need to check for these several functions, none of which actually exist yet. GAME_NEEDS_evaluateHungerFun(current_minutes); ``` So, every minute, if the RTC says we're at zero seconds past the minute (the first second of the minute), we call the hunger-fun func. That func is a funky func which takes the "rateHF" property, figures out the hunger and fun degredation rates as values from 0 to 15, and does whacky math to work that out into a rate of "number of points by which to degrade hunger or fun in a 15 minute period" TECHNICALLY, therefore, there is no bug. In a 15 minute period, with a hunger-decay rate of 15, you'll lose 15 points of hunger in any situation. Like god intended. BUT, there is a very narrow condition where the per-minute decay rate doubles, because the main program loop is being triggered by a register of Timer A0 and the check to run the evaluator is being governed by the RTC's seconds register. Technically both are being fed by the system clock, but since one can interrupt and the other can't, they drift into and out of alignment. If they're fully aligned and the heartbeat rate in A0 is actually 2hz (it's only ROUGHLY) 2hz for reasons, you could briefly experience per-minute hunger rates of 2 points per minute in the above scenario. If you somehow maintained that state for a full 15 minutes you could even double the rate-that-matters, but that should be VIRTUALLY IMPOSSIBLE given the state of the clock.

ZAdamMac commented

2022-01-03 11:00:30 -04:00

(Migrated from github.com)

The simple fix to this is that the GAME_evaluateTimedEvents function should set a flag immediately after calling GAME_NEEDS_evaluateHungerFun(current_minutes); which is then only cleared if:

the flag is still set, and
current_seconds > 0.

This would make it so that the hungerfun call and all other top-of-minute calls are only made once, irrespective of the heartbeat frequency.

The simple fix to this is that the `GAME_evaluateTimedEvents` function should set a flag immediately after calling `GAME_NEEDS_evaluateHungerFun(current_minutes);` which is then only cleared if: - the flag is still set, and - current_seconds > 0. This would make it so that the hungerfun call and all other top-of-minute calls are only made once, irrespective of the heartbeat frequency.