So, what i'm trying to do, is make a timer that will fire at a specific time of day.
Is there any functionality that will do this? Basically what i'm doing is there is a 'vote' command in the mud. When I type vote I'm going to create a tempt timer that will look at the current time, then add 12 hours to it so that if I come back and its been 12 hours it will fire and I will know that I can once again vote on top mud sites. I know how to do the logic, but looking through the helpfiles I couldnt see any mention of having a tempfire fire at say, 12:00, is there a 'current time' function or anything like that?
Temp Timers and actual Time
Re: Temp Timers and actual Time
This should be pretty simple, following the logic...
Last edited by Belgarath on Sun Mar 22, 2015 2:39 am, edited 1 time in total.
Re: Temp Timers and actual Time
I'm not sure, but you should make sure that next_vote (in Belgarath example) is saved across multiple sessions. If you are not gonna just let the profile loaded for the whole 12 hours
- SlySven
- Posts: 1023
- Joined: Mon Mar 04, 2013 3:40 pm
- Location: Deepest Wiltshire, UK
- Discord: SlySven#2703
Re: Temp Timers and actual Time
Actually I've been in the same situation on a different client and probably a different MUD but you probably want to read and write the last voted data to and from a file that is in a central location that all your profiles can see if you play more than one character in the same MUD - but not at the same time obviously if the MUD prohibits multi-playing! In that case I actually saved the Epoch time (seconds since Midnight at the beginning of 1st January 1970 UTC) and then looked to see if the current time was greater than 43200 (12x60x60) seconds since the last recorded voting time.
The lua command getTime() if not given any arguments returns a table with the various components of the date and time specifically all number values against these keys: "hour"(0-23), "min"(0-59), "sec"(0-59), "msec"(0-999), "year"(currently a four digit number), "month"(1-12, being January to December), "day"(1-28,29,30 or 31 as appropriate) in the time given by the local (Wall) clock. Note that at precisely midnight the time components could all be zero and in that case some parts of the time C++ code could say that it is an invalid time and cause all the time values to become -1 in stead of 0! Also any stored values are not going to be precisely correct if the clock gets altered by D.S.T. changes or by the user changing the system time especially on 'Doze platforms where the System clock is the same as the Wall clock.
You can modify the output from the getTime() call if you supply it with a boolean true and a string argument of what you want as per Qt's where the string you supply is used as the format in that C++ method.see: Qt Reference Documentation -> Qt Core -> C++ Classes -> QDateTime
We don't currently provide the user with epoch time functions but I will add it to my to do list as it can be useful in timing things with other Mud players in other time zones as well as when you want to time things more than a few tens of seconds in the past or future and you don't want to start multiplying and added different time periods together!
For instance the next on-line get together of the Mudlet Developer Team on Gitter should be at 1427140800 - now that is not so human readable as Mon 23 March 20:00 UTC but it is much easier for machines to process and I'd plan to be there within +1800 seconds ...!
The lua command getTime() if not given any arguments returns a table with the various components of the date and time specifically all number values against these keys: "hour"(0-23), "min"(0-59), "sec"(0-59), "msec"(0-999), "year"(currently a four digit number), "month"(1-12, being January to December), "day"(1-28,29,30 or 31 as appropriate) in the time given by the local (Wall) clock. Note that at precisely midnight the time components could all be zero and in that case some parts of the time C++ code could say that it is an invalid time and cause all the time values to become -1 in stead of 0! Also any stored values are not going to be precisely correct if the clock gets altered by D.S.T. changes or by the user changing the system time especially on 'Doze platforms where the System clock is the same as the Wall clock.
You can modify the output from the getTime() call if you supply it with a boolean true and a string argument of what you want as per Qt's
Code: Select all
QDateTime::toString(const QString & format)
We don't currently provide the user with epoch time functions but I will add it to my to do list as it can be useful in timing things with other Mud players in other time zones as well as when you want to time things more than a few tens of seconds in the past or future and you don't want to start multiplying and added different time periods together!
For instance the next on-line get together of the Mudlet Developer Team on Gitter should be at 1427140800 - now that is not so human readable as Mon 23 March 20:00 UTC but it is much easier for machines to process and I'd plan to be there within +1800 seconds ...!