Bug - Fixed "-1 free rests remaining"

L

Lxndr

Member
I've noticed this happening for a few months and I've finally managed to reproduce it:

(1) Log in after rollover. DON'T REST. adventure maybe sometimes.
(2) Log out.
(3) Log in. Look at daily deeds (or the timesRested preference, it will be negative 1).

Maybe I have some script that's arbitrarily setting my times rested to negative one? but this doesn't happen on the first login.
 
-1 out of how many?

When you say log in after rollover, did you close and reopen mafia after rollover and before logging in again?
 
I've seen this recently too, but haven't got to the bottom of it. It's always -1 out of the right number for me. I think I see it this way after ascending too.
 
This is still happening. How do I debug logging in? I know how to start a debug log while logged in, but not vice versa.

Since it seems to happen in the window between logging off and logging on... (and only after rollover)

How can I collect more information to help with this?

So steps to recreate this:

1. Wait until rollover
2. Open Mafia from a closed state (no other Mafia instances are running)
3. Log in.
4. Check timesRested, should be 0.
5. Log out (doesn't matter if you run any adventures or not)
6. Log in, again.
7. Check timesRested, should be -1.

Note: this happens whether or not you have a previous instance of Mafia open from before Rollover, or from a fresh start.
 
Lxndr said:
This is still happening. How do I debug logging in? I know how to start a debug log while logged in, but not vice versa.
Click to expand...

On the mafia window, before you click the login button, look at the menu bar at the top.

help -> start debug log

Then click login
 
So, just looking very briefly at this, there are a few ways timesRested is set.

- reset to 0 each day
- incremented when you rest
- set to either restsAvailable - 1 or restsAvailable, if Mafia somehow got out of sync with the browser.

Obviously the third one must be in play, so freeRestsAvailable() must have returned 0 in this call. updateFreeRests is in turn invoked either during a ChateauRequest or a CampgroundRequest (much more likely to be the cause).

If I had to guess, HOUSING_PATTERN matches, but the match doesn't contain "_free".
 
16854 adds some logging that should help with tracking this down, by at least logging a message when it happens. I don't think a debug log will actually help much.
 
Sending login request...
Initializing session for heeheehee...
Refreshing session data...
Synchronizing moon data...
Loading character status...
Retrieving character data...
Updating inventory...
Seeing what's still unrestricted today...
Done checking allowed items.
Examining Meat in closet...
Updating closet...
Retrieving quest data...
Retrieving familiar data...
Familiar data retrieved.
Retrieving campground data...
You have free rests available but KoLmafia thought you had none.
Click to expand...
Erm, I don't know why I guessed what I did earlier. The problem is that freeRestsAvailable is returning 0 when it shouldn't.
 
Hmm. I have a feeling I've only seen it in recent, standard, runs when the only source of Free Rests I have is from the Chateau decoration, and when I have not used free rests. I've seen it both after ascension and after logging in during an ascension. I cannot recall seeing it in aftercore, but haven't spent much time there.

Edit - Heh, ninja'd!
 
well, when I logged in this morning after downloading r16587 my rests were still -1/5.
Should there also be checking any variable like that? I mean, there's got to be a lot of variables that are functionally and logically not supposed to be negative. Does java even have unsigned variables?

(Obviously, I can manually fix it and today after rollover it very likely won't be set as -1.)
 
If I had to guess, you logged in last night after rollover, so your timesRested preference was improperly set to -1 then. You can manually fix it by typing "set timesRested = 0", and it should work from here on out.
 
You must log in or register to reply here.
Back
Top