|
|
|
Joined: Dec 2008
Posts: 1,515
Hoopy frood
|
OP
Hoopy frood
Joined: Dec 2008
Posts: 1,515 |
Hello,
I am not sure that this can be added but i want to suggest it, when using the /timerMYTIMER off and have this example event is it possible to be worked?
e.g: ON *:TIMEROFF:MYTIMER: { echo -s The $v1 timer has been ended, do now "/rr_mytimer" to start again }
alias rr_mytimer { timerMYTIMER 0 90 echo -s This is MYTIMER timer for example }
Also add the ON *:TIMERSTART:MYTIMER: { echo -s The $v1 timer has been started, do now "/timerMYTIMER off" to end it! }
thanks!
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
In general, there's no reason to have an event for a command that you directly issue ("directly" as opposed to "indirectly" from an IRC server or outside source, for instance). For example, if you're already issuing /timerN off, you can just put the event code right after (and move it all to an alias for organization purposes). Same goes for ON TIMERON.. just call the command when you /timer
However, there's one scenario where TIMEROFF might be helpful, and that's for timers with N > 1 repetitions-- though you can still handle it in your timer command, so it's not really necessary.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Dec 2002
Posts: 2,031
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 2,031 |
It looks to me as if someone wants to prevent users from stopping timers that their script has started.
on *:TIMEROFF:MYTIMER: {
timerMYTIMER 0 90 echo -s This is MY TIMER and you may not stop it!!
}
|
|
|
|
Joined: Dec 2008
Posts: 1,515
Hoopy frood
|
OP
Hoopy frood
Joined: Dec 2008
Posts: 1,515 |
Yes RoCk you're right that i want to say! this could be possible to be added?
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
@westor: That's an argument *against* adding it.
Users should be able to stop any timer they wish. In fact, I'd consider any script that forces a timer back on as somewhat malicious in intent.
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Jan 2003
Posts: 2,523
Hoopy frood
|
Hoopy frood
Joined: Jan 2003
Posts: 2,523 |
I agree that forcing a /timer down the user's throat is bad, but I often find myself doing a /timers off when I want to turn off a particular timer gone astray, just because I can't remember its name (or even worse its number). In such cases, I would actually appreciate an automatic restart of a /timer that I know I need.
A possible solution to the problem would be a new /timer switch (eg -x) that would prevent the on TIMEROFF event from firing.
/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
|
|
|
|
Joined: Oct 2003
Posts: 3,918
Hoopy frood
|
Hoopy frood
Joined: Oct 2003
Posts: 3,918 |
An even better solution to that scenario would be /timers pause so you could inspect the situation (/timers -l), stop the rogue timers and /timers resume when you're done
- argv[0] on EFnet #mIRC - "Life is a pointer to an integer without a cast"
|
|
|
|
Joined: Dec 2008
Posts: 1,515
Hoopy frood
|
OP
Hoopy frood
Joined: Dec 2008
Posts: 1,515 |
anyway guys i think one of those events will be very helpfull!
|
|
|
|
Joined: Jul 2008
Posts: 236
Fjord artisan
|
Fjord artisan
Joined: Jul 2008
Posts: 236 |
Yes, because I'd love to be able to do something like:
on ^1:TIMEROFF:*: {
.timer* off
halt
}
|
|
|
|
Joined: Jan 2003
Posts: 2,523
Hoopy frood
|
Hoopy frood
Joined: Jan 2003
Posts: 2,523 |
Apart from the fact that /timers -p/r doesn't work (these switches don't support multiple timers/wildcards), I find having to issue 3 commands a bit cumbersome.
/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
|
|
|
|
|
|
|
|