[BUG] Hunger Rate Inconsistencies

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.

ZAdamMac / PETI

[BUG] Hunger Rate Inconsistencies #19