Feature - Implemented Print calendar date

Theraze

Theraze

Active member
Fluxxdog asked for a function to return the game date as a string. I looked and didn't find one that can be called, so I made this patch which has a new single function, gameday_to_string(). It just does a return of
Code: 
return new Value( HolidayDatabase.getCalendarDayAsString( HolidayDatabase.getCalendarDay( new Date() ) ) );
so... basically, in the HolidayDatabase (the only file with Petember in it), get the calendar day as a string, using the calendar day, using the current date. It's the same system used by KoLmafia to return date everywhere else, just usable by people in scripts and the like. :)

It also fixes one of the weird spots where someone put 8 spaces into a blank line between commands for no particular reason. Pet peeve. :)
 

Attachments

Oh I love this. I went ahead and compiled this with r8593 just to see if it would work:
Code: 
> ash gameday_to_string()

Returned: Dougtember 2
Finally, something solid for ash scripts to check for rollover.
 
Last edited:
Oh. I like that. I wonder why this ever implemented?



Edit: Yes, I mean "never". :o
 
Last edited:
I hope you mean "why it was never implemented". Probably because it just never struck anyone, even though this is exactly what's been needed for so long. My whole reason for bringing it up to begin with was a script that I have monitor my stinky cheese until a certain stinkiness and a part of my after battle script that should fire only once a day, but never at breakfast or dessert. Since rollover doesn't correspond to RL dates, I thought there'd be a way to use the game dates. As I looked fruitlessly, that's when I remembered the complaints others have had about setting up things to trigger at rollover. I vocalized, Theraze stepped up to the challenge and boy, it works beautifully.
 
Well, if you REALLY want to make it simple for the ash scripts to check for rollover, you could try this next one... gameday_to_int() just returns the int value of the KoL day, not turned into a string. That should make it significantly easier to check, and you can even easily use it to look if a certain number of days has gone by since your last run. Just remember that a full calendar cycle is 96 days (line 823 of persistence/HolidayDatabse) and so, if you're actually caring about how many days, you may want to do a check if your new number is less than the old number, and if so, add 96 before comparison (but not before saving). But this does allow for scripts to be run every other day VERY easily... in that case, for example, you could just make it have something like
Code: 
if (gameday_to_int() % 2 == 0) return;
or something like that... No saved preferences, but only runs every other day.

If we REALLY want to make things easy for scripts, we could make a version of the getCalendarDay that doesn't do the final % 96 at the end there, so it just returns how many rollovers since August 17th, 2005. But I don't think that most people need that level of accuracy... being able to do comparisons against the % 96 rollover should be fine.

Edit: Ha, I was going to give an example and left the window open and all... lost the window. Here goes:
ash gameday_to_int()

Returned: 89
Click to expand...
 

Attachments

Last edited:
While a can easily see this being useful, getting something to happen only once per day was as simple as using a preference with _ in front of the name to track whether it had already been done.
 
True... I was more including that if something is only useful once a week, or something similar to that, as opposed to once a day... doing that with _ would be rather difficult, though using _ to see whether you'd checked if today is your day of the week would be good.
 
I agree, lost. Although my need to reset some preferences monthly meant I had to hardcode a calendar to keep track of stuff. I like it as a solution. However, I can see this being useful in *very* niche circumstances. Just not one that will really benefit myself.
 
Yeah... I was mostly just thinking that if someone has preferences they want to reset after 30 days, for example, they could do the following:
Code: 
if (_checkedSamplePreference == false){
set _checkedSamplePreference = true;
if ((gameday_to_int() < someSamplePreference ? (gameday_to_int() + 96) : gameday_to_int()) - someSamplePreference > 30){
<do some stuff>
someSamplePreference = gameday_to_int();
}
}

Just simplifies being able to run on any kind of schedule you want...
 
lostcalpolydude said:
While a can easily see this being useful, getting something to happen only once per day was as simple as using a preference with _ in front of the name to track whether it had already been done.
Click to expand...
Considering I have had freeze ups that will corrupt and wipe my prefs, overiding them with defaults, I need something a bit outside the box. I'd report bugs but the freeze ups alone are so random with no debug log printing out I'm honestly at a loss.
 
Fluxxdog said:
Considering I have had freeze ups that will corrupt and wipe my prefs, overiding them with defaults, I need something a bit outside the box. I'd report bugs but the freeze ups alone are so random with no debug log printing out I'm honestly at a loss.
Click to expand...

If it is any consolation I have also had my preferences wiped and I have no clue as to why. I have it set up so I use the same settings for running from Netbeans or running normally. The last time I hosed things, I ran character A in Netbeans, shut that down, ran character B "normally" then ran character A and discovered preferences had been reset for A, but of course I don't know whether that was before or after running character B. Not enough there for a bug report or to try and solve the problem myself.

Since I proxied the original, I'm not getting any sense about whether the update is really wanted or not. Help me out here if there is a groundswell of opinion in favor of the update.
 
I suppose it really depends on how complicated people want their ash scripts to be? If someone has a mushroom script and want to be sure that everything happens the way it's supposed to, this new command is a major boost, because _tomorrow isn't going to know if there's been one rollover or 15 since the last time it was set, just that rollover happened... gameday_to_string() can be used, but requires generating a new map to understand the difference between days/months. With gameda_to_int(), all you need to do is check if (savedPreference + 1) % 96 == gameday_to_int(), and you know for certain that you haven't missed a day, but there's been a rollover.

That being said, I'm not sure how many other current applications it has, besides mushrooms and the sample version-checking script I posted earlier... are there any other current actions that depend on doing things properly daily?
 
So I suppose the question is, would anybody besides me potentially use this if it were rolled into main source? As I said, I happen to think it's useful, but if I'm the only one, any script I might tweak and release with that would screw other people up... if nobody else likes it, I may as well remove it from my source so I don't screw people up in 6 months when I forget that it's a local only change. :)
 
Oh... I knew that gameday_to_string() was in main source. I didn't think that gameday_to_int() was. :D String is nice for relay strings and making things look pretty, but Int is what you need if you're actually making the values matter for comparisons and usefulness...
 
Never mind. I misunderstood. I was talking about gameday_to_string(). gameday_to_int() was not added to main source.
 
Yeah... that's what I'd thought. gameday_to_string() is good for pretty strings, but gameday_to_int() is good for preferences, mushroom scripts, etc. That's the one I was wondering though if anyone besides me (probably on a mushroom script) would use... I'm unlikely to ever remove it from my source, but if it's not part of base, I'm less likely to care about fixing scripts that use it for other's enjoyment. :D
 
Y'know, I could probably add that function to DateLib.ash so anyone could use it (remember that Mafia functions have precedence over user-defined functions, so no name collisions there). Just a thought.
 
You must log in or register to reply here.
Back
Top