Login <username> no longer resetting daily variables in some cases
A recent issue I've noticed is that if I use "login <username>" after nightly maintenance, it isn't resetting my daily variables. A second "login" does the trick as well as closing out mafia instead of using the login command.
This is pretty recent, that's all I know.
It decides whether to reset these based on whether the last day it has reset counters is the same as the current day, based on a guess of the phase of the moons based on the current local time.
Is your PC time correct? What time is it failing, currently it looks like we consider a day to have changed based on a timezone GMT-0330. Not sure when rollover is, as I'm asleep at that time!
Rollover generally starts around UTC 3:30 (whcih is exactly midnnight in UTC-0330), give or take a couple (dozen) seconds, so basing it off "GMT-0330" is as close as we will get. It also lasts a nontrivial time, so it always *ends* after UTC 3:30.
Originally Posted by Darzil
(UTC is almost the same as GMT, but IMAO more clearly implies absolutely no DST)
Maybe something rounds wrong in the first minute of the day?
I've been having this issue 10 hours after rollover and it is only a recent issue. And logging in right afterwards results in expected behavior. So, this morning I did "prefref smile; login cheesecookie; prefref smile; login cheesecookie; prefref smile". And it wasn't until the last prefref that it was reset.
Originally Posted by Darzil
I am probably going to rollback r18428 and see if that resolves it.
I suspect lastCounterDay and lastGlobalCounterDay aren't changed before they are checked with the change in r18428 (src/net/sourceforge/kolmafia/KoLmafia.java:refreshSession) Update: reverting that change fixed my issue.
Last edited by cheesecookie; 01-31-2018 at 01:16 PM.
I have been having this problem too. Sometimes it does not recognize that it is a "new" day and tells me that I have no Deck uses left right upon log in. Refreshing mafia fixes the problem (temporarily), I think.
I suspect I know the difference between the two, and I'm tempted to change the way it works (though testing it could be interesting).
r18442 I think will fix the issue.
However, it does strike me that you will get weird behaviour if you log in 16 days apart, as you'll be on the same moon phase so nothing will get reset.
And it looks like API holds a trump card. "rollover" contains the UNIX timestamp of the next rollover, so the safest thing is to notice when that changes, and use that as the key for resetting counters.
Although it is more complicated than that, as "rollover" is slightly different on different requests, maybe it's logging on to different servers?
Last edited by Darzil; 02-04-2018 at 10:28 AM.
r18443 works using next rollover to work out if the day has changed, rather than moon phase.
Have seen 1517801398, 1517801401 and 1517801402 for rollover, so I think time is slightly different on different servers. Don't use exact matching if you use new ash command rollover()!
Code is Y2038 safe
I guess I'll assume fix worked as no one came back to us ?