mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Jun 2004
Posts: 139
N
Ninko Offline OP
Vogon poet
OP Offline
Vogon poet
N
Joined: Jun 2004
Posts: 139
Hi there,
It would be useful if you could add a time AND date to a /timer rather then just a time to trigger.

Thanks


Ninko

Joined: Apr 2004
Posts: 759
M
Hoopy frood
Offline
Hoopy frood
M
Joined: Apr 2004
Posts: 759
It would be also cool if you could make timers persistant without having an on *:START: reinforcing them.

Last edited by Mpdreamz; 19/11/08 05:02 PM.

$maybe
Joined: Sep 2008
Posts: 62
_
Babel fish
Offline
Babel fish
_
Joined: Sep 2008
Posts: 62
It's easy to calculate the amount of seconds between two points of time with scripting, so in my opinion this would be added bloat. If anything, I'd propose the addition of a new switch '-u' to /timer, which allows you specify a CTIME value. But once again, this is easily achievable in scripting.

Also in my opinion, having persistent timers would be a waste. Timers are for scripting, and ON START *is* scripting. It's not a trivial chore or challenge to start a timer with ON START, nor does it come at any realistic cost whatsoever. If ON START didn't exist, I'd endorse this. But unfortunately it's more than completely feasible to achieve the same outcome using the current method of persistent timers.

Joined: Nov 2004
Posts: 842
Hoopy frood
Offline
Hoopy frood
Joined: Nov 2004
Posts: 842
Seconding the -u flag for /timer. :3


What do you do at the end of the world? Are you busy? Will you save us?
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
Code:
//timer 1 $calc($ctime(01/01/2009 00:00) - $ctime) amsg HAPPY NEW YEAR!!

Joined: Jun 2004
Posts: 139
N
Ninko Offline OP
Vogon poet
OP Offline
Vogon poet
N
Joined: Jun 2004
Posts: 139
The problem with that hixxy is I find it tends to lose sync with time after a long period finally triggering at the wrong time, hence the trigger on set time and date.


Ninko

Joined: Sep 2008
Posts: 62
_
Babel fish
Offline
Babel fish
_
Joined: Sep 2008
Posts: 62
So instead of filing a feature suggestion, you should of filed a bug report about the desync so we could of examined your code...

But as far as /timers are concerned, if you need pin point accuracy then don't use mIRC and mSL for projects. As plain and simple as it gets, mIRC is an IRC client and IRC isn't a time critical environment (spare me the TS debate), nor developed on that model. So why should the clients move towards that direction?

To solve the desync issue however, I'd write my own time scheduler using an Object Oriented model and choose whatever format I wanted for representing the date/time/millisecond reference, and perhaps use a pre-fetch mechanism that schedules an exclusive check a minute before it's suppose to trigger just to verify its on time, then make any corrections and schedule yet another exclusive timer.

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
A feature suggestion for a datetime trigger on a timer would not mean it would necessarily be any more accurate than hixxy's suggestion. In fact, I bet the implementation would be the C equivalent of that code. Either bug report it as mentioned or follow the scriptable suggestion below:

If synchronization is an issue, run a shorter timer that verifies the current date has been reached at which point you can set the timed timer, or do something similar once you're within N minutes of the intended trigger time.

Code:
alias cron.delay { return 30 }
alias cron {
  if ($calc($1 - $ctime - $3) < 300) { 
    .timer 1 $v1 $4-
  }
  else {
    var %delta = $calc($ctime - ($2 + $cron.delay))
    .timerCRON 1 $cron.delay cron $1 $ctime $calc($3 + %delta) $4-
  }
}
alias cronstart { cron $1 $ctime $cron.delay $2- }

/cronstart $ctime(1/1/2009 0:00) msg #somechan happy new year


The code above uses a delta accumulator to keep track of how far off the timer has wandered and adds this adjustment value to the final timer. This may not even be needed.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jun 2004
Posts: 139
N
Ninko Offline OP
Vogon poet
OP Offline
Vogon poet
N
Joined: Jun 2004
Posts: 139
It was just a feature suggestion to make it abit more flexible people, its either taken on board or it aint.

Ninko

Joined: Sep 2008
Posts: 62
_
Babel fish
Offline
Babel fish
_
Joined: Sep 2008
Posts: 62
The situation isn't about being a bad suggestion, it's about the principal of the problem you presented in the original post. You claim the timer mechanism is unreliable, however your solution is to use the same unreliable function of the program, but which accepts an additional date input. You're contradicting yourself in this suggestion, which has nothing to do about being flexible or not. My suggestion of the addition of accepting CTIME values is about flexibility, however like others have pointed out it's pointless because you're not solving the problem itself -- which is easily avoided by currently provided scriptable solutions.


Last edited by _Memo; 21/11/08 01:12 AM.

Link Copied to Clipboard