mIRC Home    About    Download    Register    News    Help

Print Thread
Page 1 of 2 1 2
#230738 19/03/11 06:54 AM
Joined: Jul 2006
Posts: 4,144
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
I think it has been reported before, but I can't find the post.
When pausing a timer, the delay keep decreasing until 0, after that, resuming the timer executes the associated command directly.
Code:
//.timertest 1 5 echo -at timer | .timer -h 5 1000 echo -at > $!timer(test).secs | .timer 1 7 timertest -r | timertest -p

Last edited by Wims; 19/03/11 07:11 AM.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Wims #230747 19/03/11 03:26 PM
Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
Although I don't see this explained in the help file, -p doesn't actually pause a timer. It basically just silences the output until it's resumed. I believe Khaled has responded about that in the past.

If you truly pause a timer, then your times are messed up when you resume it. For example, if you have the timer going off every 30 minutes (let's say at :00 and :30) and you pause it at :45 for half an hour, then resume it, your timer will go off at :15 and :45 from then on. That is probably not what you want to have happen.

Probably the best thing that can be done is change the help file to say that it silences the output instead of saying it pauses the timer.

Of course, there are valid reasons for it to really pause and valid reasons for it to silence output while "paused." I don't think it needs changed and in the past, Khaled hasn't thought it needed changed either. No matter which way it is, it helps some and doesn't help others, so changing it doesn't really solve anything and instead just causes problems in backwards compatibility with anyone making use of it the way it works now.


Invision Support
#Invision on irc.irchighway.net
Riamus2 #230773 20/03/11 08:34 AM
Joined: Jul 2006
Posts: 4,144
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
Quote:
-p doesn't actually pause a timer
which is why I made this report.
Quote:
It basically just silences the output until it's resumed
Pausing isn't "silencing the output", not sure where you got that statement from but the point of "pausing" is that the state of whatever you are pausing remain unchanged until you resume it, when you pause a song, you don't expect $insong.pos to change so when you pause a timer you don't expect $timer().secs (or .reps) to change.
Quote:

If you truly pause a timer, then your times are messed up when you resume it. For example, if you have the timer going off every 30 minutes (let's say at :00 and :30) and you pause it at :45 for half an hour, then resume it, your timer will go off at :15 and :45 from then on. That is probably not what you want to have happen.
What you are saying doesn't make sense, of course that's what I want to happen, otherwise I wouldn't have paused the timer in your example, I also wouldn't have made that report..
Quote:
I believe Khaled has responded about that in the past.
Hum, it would be interesting to see what he said, btw, I found the post I was referring to in my first post https://forums.mirc.com/ubbthreads.php?ubb=showflat&Board=8&Number=154009&Searchpage=1&Main=28732&Words=timer+%2Bpause&topic=0&Search=true#Post154009.
Quote:
Of course, there are valid reasons for it to really pause and valid reasons for it to silence output while "paused."
Ah ah really ? Can you give one example where it makes sense and where one could use the actual behavior ?

Wims #230774 20/03/11 09:31 AM
Joined: Dec 2002
Posts: 344
D
Pan-dimensional mouse
Offline
Pan-dimensional mouse
D
Joined: Dec 2002
Posts: 344
Originally Posted By: Wims
Ah ah really ? Can you give one example where it makes sense and where one could use the actual behavior ?


The current behavior makes since in certain contexts. For example, suppose you use a timer to queue a large number of lines to a channel (like /play). The only purpose of the delay in between sending each line is to avoid flooding. You may want to pause the output if the channel is set to +m, then resume when channel is set to -m again. After the -m, it makes more sense to immediately send the next line instead of finishing the delay (assuming +m was set for reasonably long).

At first glance this looks like the same as just stopping and starting a new timer (when +m and -m are set, respectively) instead of pausing and unpausing, but it's not. If +m was set and unset very quickly such that it is still too soon to send the next line, restarting the timer would cause a line to be sent sooner than intended, whereas the current implementation of pause/unpause will handle this correctly.

Now, the behavior you are describing would also be useful, but in different contexts. I don't think the current method is wrong, but just different than you expected. For this reason I don't think the current behavior should change but perhaps a second pausing method could be added.

drum #230776 20/03/11 10:27 AM
Joined: Jul 2006
Posts: 4,144
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
If I get it right, your example doesn't work :
one timer would be one /msg, when you see +m, you pause them, when you see -m, you resume them and they would all execute their /msg command at the same time (assuming -m is set after all timer delay reached 0) because of that "bug".
Quote:

If +m was set and unset very quickly such that it is still too soon to send the next line, restarting the timer would cause a line to be sent sooner than intended, whereas the current implementation of pause/unpause will handle this correctly.
Not sure what you mean with this specific case but as I stated and if I get it ok, your example wouldn't handle that correctly

Edit : It doesn't matter anyway, you may have found one case where the actual behavior could be used, it doesn't mean that the behavior is correct.
Quote:
Now, the behavior you are describing would also be useful, but in different contexts. I don't think the current method is wrong, but just different than you expected. For this reason I don't think the current behavior should change but perhaps a second pausing method could be added.
It's not about me, the problem has been reported five years ago, the actual behavior is simply wrong, it doesn't make any sense to use it as it is. Even for your case, noone would have used "paused timer" since noone would have expected it to work this way.

Last edited by Wims; 20/03/11 10:32 AM.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel
drum #230778 20/03/11 10:47 AM
Joined: Feb 2006
Posts: 546
J
Fjord artisan
Offline
Fjord artisan
J
Joined: Feb 2006
Posts: 546
Originally Posted By: drum
After the -m, it makes more sense to immediately send the next line instead of finishing the delay (assuming +m was set for reasonably long).


the current behaviour is, in effect, the sum of what it ought to be plus a potential single execution of /timer -e. if it were changed to behave in the way that it ought to behave, a user could replicate previous behaviour with /timer -r followed by optional /timer -e depending on the result of a calculation involving $timer().secs before and after the pause. however, as it stands, it isn't nearly so simple to script /timer -p that functions as Wims believes it should, and as is suggested by the phrasing 'pause a timer'.


"The only excuse for making a useless script is that one admires it intensely" - Oscar Wilde
Wims #230808 20/03/11 10:58 PM
Joined: Dec 2002
Posts: 344
D
Pan-dimensional mouse
Offline
Pan-dimensional mouse
D
Joined: Dec 2002
Posts: 344
Originally Posted By: Wims
If I get it right, your example doesn't work :
one timer would be one /msg, when you see +m, you pause them, when you see -m, you resume them and they would all execute their /msg command at the same time (assuming -m is set after all timer delay reached 0) because of that "bug".


You are not correctly understanding the current behavior. With the current behavior, when you unpause a timer, the command will only be executed if the full delay has transpired since the previous time that the timer's command was executed. It will never execute more than once immediately after an unpause.

It might be more clear if I just give some examples. Suppose we have a timer with an interval of 10 seconds that is set to 5 repetitions. This is what would happen if you paused and unpaused at the indicated time:

00.0 sec : Start timer
10.0 sec : Timer triggers (1st time)
20.0 sec : Timer triggers (2nd time)
22.0 sec : Timer is paused
54.0 sec : Timer is unpaused
54.0 sec : Timer triggers (3rd time)
64.0 sec : Timer triggers (4th time)
74.0 sec : Timer triggers (5th time) and timer halted

Even though much time transpired while paused, the timer doesn't immediately execute multiple times after unpausing (i.e., it's not trying to "catch up"). It simply finishes the repetitions with the original interval.

Here's another example (same conditions):

00.0 sec : Start timer
10.0 sec : Timer triggers (1st time)
20.0 sec : Timer triggers (2nd time)
22.0 sec : Timer is paused
27.0 sec : Timer is unpaused
30.0 sec : Timer triggers (3rd time)
40.0 sec : Timer triggers (4th time)
50.0 sec : Timer triggers (5th time) and timer halted

I hope this clarifies what is currently happening and why my previous example of the message queuing script would work with this system.

Quote:
It's not about me, the problem has been reported five years ago, the actual behavior is simply wrong, it doesn't make any sense to use it as it is. Even for your case, noone would have used "paused timer" since noone would have expected it to work this way.


I disagree, I think this behavior makes a lot of sense. If your purpose is to ensure that the timer's command is never executed within 10 seconds of the previous time it was executed, this is good behavior.

Last edited by drum; 20/03/11 11:06 PM.
jaytea #230809 20/03/11 11:03 PM
Joined: Dec 2002
Posts: 344
D
Pan-dimensional mouse
Offline
Pan-dimensional mouse
D
Joined: Dec 2002
Posts: 344
Originally Posted By: jaytea
the current behaviour is, in effect, the sum of what it ought to be plus a potential single execution of /timer -e. if it were changed to behave in the way that it ought to behave, a user could replicate previous behaviour with /timer -r followed by optional /timer -e depending on the result of a calculation involving $timer().secs before and after the pause. however, as it stands, it isn't nearly so simple to script /timer -p that functions as Wims believes it should, and as is suggested by the phrasing 'pause a timer'.


That wouldn't work because /timer -e does not reset the time before the next execution. Therefore changing the behavior as you suggested would require you to use $timer().secs to reproduce the original behavior, so you're really just swapping the two behaviors in terms of how difficult they would be to implement.

That's why I thought both behaviors could be added natively. /timer -p could be the current behavior, and a new switch could implement the behavior Wims is asking for.

drum #230810 21/03/11 07:02 AM
Joined: Jul 2006
Posts: 4,144
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
Quote:
You are not correctly understanding the current behavior. With the current behavior, when you unpause a timer, the command will only be executed if the full delay has transpired since the previous time that the timer's command was executed. It will never execute more than once immediately after an unpause.
Yes I am, when I said "if I get it right", I was talking about how you would use timers in your /play example, I thought you would have one timer per line and that you would pause them all once +m is set.
What I just quoted from you is true but isn't the reason of my report, unpausing a timer works correctly, pausing a timer doesn't (imo) : the delay doesn't stop decreasing.
Now maybe it's not a bug and all I need is a new switch, but I would be surprised if Khaled implemented it this way on purpose.

Quote:
If your purpose is to ensure that the timer's command is never executed within 10 seconds of the previous time it was executed, this is good behavior.
This wouldn't be a problem if the delay wasn't decreasing


Last edited by Wims; 21/03/11 07:06 AM.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Wims #230813 21/03/11 08:05 AM
Joined: Dec 2002
Posts: 344
D
Pan-dimensional mouse
Offline
Pan-dimensional mouse
D
Joined: Dec 2002
Posts: 344
Originally Posted By: Wims
Yes I am, when I said "if I get it right", I was talking about how you would use timers in your /play example, I thought you would have one timer per line and that you would pause them all once +m is set.


Fair enough. My intention was a single timer running that would call an alias that sends the next line in the queue, not multiple timers.

Quote:
Now maybe it's not a bug and all I need is a new switch, but I would be surprised if Khaled implemented it this way on purpose.


Clearly I disagree. I'll leave this to Khaled to clarify if he chooses though because both of us can only speculate.

As an aside, I was wondering if you could give an example where the behavior you believe to be "correct" would be more useful than the current behavior.

drum #230814 21/03/11 08:41 AM
Joined: Jul 2006
Posts: 4,144
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
Quote:
As an aside, I was wondering if you could give an example where the behavior you believe to be "correct" would be more useful than the current behavior.
I have a game where sometimes, a state of the game need to be changed temporarly for X seconds (I use a timer to undo that change after X seconds).
If I want to pause the game (which is nothing more than pausing timers) during that temporarly state, I won't have my temporarly state for X seconds but for less than that, depending on when I resume the pause.

Consider X = 7, T is in second :
T=0 : temporarly state begins, $timer().secs = 7
T=2 : I pause the game, $timer().secs = 5
T=7 : $timer().secs = 0 instead of 5
T=9 : I resume the game, the timer executes its command

And the problem is that, in this case, the temporarly state lasted 2 seconds instead of 7.

Quote:
I'll leave this to Khaled to clarify if he chooses though because both of us can only speculate.
Indeed, I'm also waiting for an answer

Last edited by Wims; 21/03/11 08:43 AM.
Wims #230815 21/03/11 10:17 AM
Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
It might help to find and download some scripts that pause the timer and see how they use that switch. Because any script using that switch now is making use of the timer the way it's currently set up. That will give you some concrete examples of how it's being used now. Rather than trying to come up with various examples. It's usually difficult coming up with valid examples if you've never needed the functionality of something.

And as I mentioned before, I am almost positive I saw Khaled respond on this years ago saying that it was by design. Searching isn't the best on this forum, so finding that might not be possible and may have been over 5 years ago anyhow. And perhaps I'm even remembering that incorrectly after so long. In any case, I don't think the current -p should be changed, though the help file could be reworded. It would be better to add a new switch to handle some other method of pausing timers so that it doesn't affect all scripts out there that currently use -p.


Invision Support
#Invision on irc.irchighway.net
Wims #230824 21/03/11 07:37 PM
Joined: Dec 2002
Posts: 344
D
Pan-dimensional mouse
Offline
Pan-dimensional mouse
D
Joined: Dec 2002
Posts: 344
"Pausing" has a very specific interpretation when it comes to things like video games. Games can operate on a sort of self-contained concept of "time" that can be artificially stopped and started, essentially freezing time in place.

But mIRC's primary purpose isn't for gaming -- it's for communication. Real-world time continues even when your timers are paused, so that's why it doesn't make sense for the timer to ignore that time is still passing. Pausing a timer means you simply want to postpone the actions so that they don't occur during the pause, not that you want to pretend like time has frozen in place. I just don't see that being useful outside of situations where you have an artificial definition of time.

drum #230825 21/03/11 09:21 PM
Joined: Jul 2006
Posts: 4,144
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
Quote:
Pausing a timer means you simply want to postpone the actions so that they don't occur during the pause, not that you want to pretend like time has frozen in place
Come on, pausing means pausing : a short period of inaction, a short period is represented by X seconds, you can pause a socket with /sockpause for X seconds, you can pause a song with /splay pause for X seconds but you cannot pause a timer for X seconds.
How do you explain these differences while they all use the term "pause" ?

edit : I removed the sarcasm.

Last edited by Wims; 21/03/11 10:39 PM.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Wims #230826 21/03/11 11:01 PM
Joined: Dec 2002
Posts: 344
D
Pan-dimensional mouse
Offline
Pan-dimensional mouse
D
Joined: Dec 2002
Posts: 344
My point was that "pause" means different things (in terms of actual implementation details, not in terms of definition) depending on context. The kind of pause you want is only useful for things where the current state of some closed system can be temporarily frozen -- for example, a paused game or a paused song. The key distinction is "closed system".

Since mIRC is primarily a communication tool, timers are most commonly used for real-time interaction with an open system, i.e., IRC. The behavior of /timer -p makes sense in open systems like this.

I get that you could use mIRC to make a game, which would basically be a separate closed system, but just understand that mIRC isn't really designed around that. The current behavior of /timer -p is useful for mIRC's primary purpose, but not as helpful for pausing a game. That's OK, but let's just recognize that it's not a bug, it's just not the correct tool for what you want to do.

drum #230827 22/03/11 12:15 AM
Joined: Jul 2006
Posts: 4,144
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
Well, as you stated, we cleary disagree about the current behavior being correct or not.
Quote:

The behavior of /timer -p makes sense in open systems like this.
The current behavior of /timer -p is useful for mIRC's primary purpose
For me, there are many more cases where a real pause of the timer is expected, it's not just about being useful, it's about expectations.
In fact I still can't find an example (apart from your /play's one) were the current behavior could be used/useful or even, should be expected.
I also bet that if we were to make a list of cases for each behavior, we would have, as I said, many more cases where a real pause is expected.
Quote:
That's OK, but let's just recognize that it's not a bug, it's just not the correct tool for what you want to do.
A bug is something that isn't working as expected, If Khaled states it's not a bug, fine, I'll say it's not the correct tool for what I want to do smile


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Wims #230829 22/03/11 07:48 AM
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
I've got to agree with Wims here.

"Pause" by its very definition means to save the state of something as it is at that exact moment so that you can resume it later on. If you pause a timer with 3 seconds left until it triggers and resume it later, it is logical to expect that the timer will take 3 seconds from that point, otherwise the timer does not pause and is still ticking after running the pause command.

That said, this has the potential to break scripts so it would perhaps be better to implement true pausing using another method. Maybe -p/-p0 can still trigger the current method and -p1 for Wims' expectations.

drum #230902 24/03/11 08:19 PM
Joined: Apr 2003
Posts: 342
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Apr 2003
Posts: 342
When I press PAUSE on my iPod, it pauses the track at it's current location. it does not silence the output as it continues playing. That's known as MUTE.

mIRC's own /splay command follows this behavior.

* /SPLAY PAUSE
* /SPLAY RESUME

Pause means to suspend operation. If you can find any other definition of "PAUSE" that contradicts this, please show us this definition.

Last edited by MeStinkBAD; 24/03/11 08:25 PM.

Beware of MeStinkBAD! He knows more than he actually does!
Wims #230903 24/03/11 08:41 PM
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
You have to remember that the -p option was added in 2001 and was very likely requested by someone who wanted it to work in this particular way. While it may not work the way you want or expect, that does not necessarily mean that it is a bug :-) With a feature that is this old, changing it would probably cause all existing scripts to break in some way, so it is very unlikely that I would change how it works after ten years. If you would like a new /timer behaviour, it would be best to post a suggestion in the feature suggestions forum.

Khaled #230905 24/03/11 08:56 PM
Joined: Jul 2006
Posts: 4,144
W
Wims Offline OP
Hoopy frood
OP Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
Thanks for commenting smile like I said in my last post :
Quote:
A bug is something that isn't working as expected, If Khaled states it's not a bug, fine, I'll say it's not the correct tool for what I want to do smile
So I'll just make a suggestion.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Page 1 of 2 1 2

Link Copied to Clipboard