Bug - Fixed Tuesday's ruby vs timezones

Tussosedan

Tussosedan

New member
While trying out EatDrink's new support for field gar, I came across this:

Tested today, using the latest mafia build (10849).

At 11:27pm Monday (MST) - Time in Phoenix, AZ, USA:
> ash numeric_modifier($item[tuesday ruby], "muscle percent")

Returned: 0.0
Click to expand...

But KoL shows:
Enchantment:
+5% Muscle
Click to expand...

At 12:08am Tuesday (MST) - Time in Phoenix, AZ, USA -- same result (only this time it's correct), and KoL shows:

Regenerate 3-7 MP per adventure
Click to expand...

Before Monday's rollover it correctly returned "5".

Edit: the same problem might exist with the field gar, if they use the same check?
According to this, the check is for GMT-0330, while Arizona time is MST = GMT-0700?
 
Last edited:
Veracity

Veracity

Developer
Staff member
So, unlike many other things in KoL, they are treating the new "day" as starting at midnight in Arizona, rather than on rollover?

How odd. It means that things will change in the middle of the day, elsewhere in the world, just because midnight passed in Arizona.

That sounds like a KoL bug.
 
xKiv

xKiv

Active member
But there's no monday or tuesday in the kingdom ... the closest the servers have is where they live ...
(if it depended on your timezone, you would be able to switch the effect(s) by changing your timezone)
 
Tussosedan

Tussosedan

New member
Veracity, yeah, and looks like it isn't new -- see wiki.

Edit: The Festive Dismemberment trophy also goes by Arizona time.
 
Last edited:
lostcalpolydude

lostcalpolydude

Developer
Staff member
I just assumed tuesday's ruby was already based on Arizona's day when copy-pasting the code for field gar. A little more thought and I would have caught it.

I believe it has been brought up in radio show questions more than once, so I wouldn't expect it to change any time soon.
 
T

Terion

Member
The ruby never had more than a minor effect to me, but I do need to make myself a note to have my multi, who eats lasagnas in aftercore, get on right after rollover on Sunday night, so he can eat his Monday lasagna with the Gar-ish benefit before Monday starts. Thanks to this thread for pointing that out!

Edit: I do recall forum discussions about the July 4th trophy, when people would complain that they'd spent all their turns and couldn't go farm a firecracker, telling them that they'd have some time after rollover to still celebrate.
 
F

Fred Nefler

Member
I think a script should be able to check for successful use of the item before continuing.

Yeah, it should be fixed, just thinking that a more robust script would not have had this problem.
 
Theraze

Theraze

Active member
Should... yes, if there's any reason for it to fail. If mafia tells it though that it should work, and the script gets the item and the usage rules for the item say now is the time... you don't check over and over and over again if the item failed. Down that road leads madness. And really messy code.
 
A

Alhifar

Member
It should be as simple as a check for gar-ish right after you use the potion to ensure you actually got it before you drink, and abort if not.
 
Theraze

Theraze

Active member
Well, in the script in question, we've made our food choices and initialized the database based on mafia reporting that the potion is available, by checking Tuesday's Ruby... specifically:
Code: 
if (numeric_modifier($item[tuesday ruby], "muscle percent") != 5.0)
means that it isn't Monday, and the potion is of benefit. If that returns true, and we're able to get the potion, the 3 lasagna items affected get += 5 to their min and max adventures. As they might still be the best option if the potion fails, but we really don't know, they shouldn't be eliminated, but the static database has already been done, since, as Veracity pointed out a while ago, there isn't really a great reason to reinitialize a database 15 times if you're just pulling the same data... Take 8 seconds to do it instead of 30 and your users will enjoy the lack of delay.

Now, we can write the scripts to punt and not run at all if mafia reports incorrect information and forces the users to go to the relay browser because it's incorrectly blocking their usage... but that seems somewhat vindictive as it's just a great way to get people to post duplicate mafia bug reports, as they each think it's a new issue. Or we could fix the initial issue and allow the scripts to run properly again.

Y'know, options. :)
 
Tussosedan

Tussosedan

New member
Guys, let's keep it simple :rolleyes:
There's a bug in mafia's checks for field gar and Tuesday's ruby.
That's all there is to it.
 
Theraze

Theraze

Active member
Anyone know if December's hobo beard uses the same RL Arizona v. KoL rollover logic? Basically, do you get the first rollover on the night of Nov 30, or Dec 1?

Anyways, here is a patch that changes all 3 of those to use RL Arizona day/month instead of using rollover day/month.
 

Attachments

  • ArizonaRolling.patch
    1.6 KB · Views: 20
S

slyz

Developer
r10876, thanks.

I forgot to thank you in the commit message... I seem to do that a lot. Sorry.
 
Theraze

Theraze

Active member
Yes... during DST, PST moves from GMT-8 to GMT-7, the same as Arizona. For DST, MST moves from GMT-7, the same as Arizona, to GMT-6.

DST is not a global thing, and as such, GMT doesn't vary based on the whims of American politicians...
 
D

Darzil

Developer
GMT doesn't change with daylight savings. Things change relative to GMT.

Oddly, the time in Greenwich is GMT+1 in the summer as a result, as we also have daylight savings.
 
You must log in or register to reply here.
Top