mIRC Home    About    Download    Register    News    Help

Print Thread
#261682 12/11/17 07:01 PM
Joined: Jan 2004
Posts: 2,127
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
per /help $timer
Quote:
"$timer(3).secs returns number of seconds left before timer is triggered"


In this example, the portions after "timername:" are identical identifiers:

Code:
//timerbar 12 1 echo 6 -ag bar: secs $!timer(foo).secs reps $!timer(foo).reps | /timerfoo 2 5 echo 4 -ag foo: secs $!timer(foo).secs reps $!timer(foo).reps


Bug: on the last execution of the timer (or the only execution if you change "2 5" to "1 5", the .secs property jumps up to either .DELAY or .DELAY-1sec even though it immediately halts right after displaying the 4 or 5. It should show 0 because that timer will not be triggered again. This non-zero .secs also happens with -h or -m when using intervals of 1004ms or greater and shows 0 with lesser ms intervals, though I'm sure that number will vary depending on the OS and cpu speed.

This also happens if you use -e to accelerate the one-and-only time the timer executes, except in this situation .secs shows the final countdown at the time -e triggered the execution instead of .delay-1sec. Again, it's a non-zero value that should be showing 0 because that timer will not be executed again:

Code:
//timerfoo 1 999 echo 4 -ag foo: secs $!timer(foo).secs reps $!timer(foo).reps | timerbar 1 9 echo 6 -ag secs $!timer(foo).secs reps $!timer(foo).reps | timerfoobar 1 10 timerfoo -e


Regarding backwards compatibility with existing scripts, it's not needed to have the final execution show non-zero .secs in order to allow timers to revive themselves, because they should be using .delay instead of .secs. Since .secs is often (.delay -1sec), a timer that used its own .secs to revive itself will quickly find itself with a delay decrementing to 0.

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Thanks for your bug report. Zero is a valid .secs value, so it cannot be used as an indicator that the timer has ended. For example, you can use /timer N 0. The .secs property is not designed to indicate that the timer has ended. It is simply meant to represent the delay until it is next triggered based on the delay value. As far as I can see, .reps is what should be to used to check if the timer is going to be triggered again.

Joined: Jan 2004
Posts: 2,127
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
From your reply, it looks like I wasn't clear describing what I see as a bug. I was not objecting to .secs being zero, I was saying that .secs on the final execution of a timer should always be zero. Instead, timerbar sees $timer(foo).secs counting down to 1-or-0 on the next-to-last execution, but on the final execution it jumps up to 'delay' or 'delay-less-1' immediately before being eliminated. This should make it more clear:

Code:
//echo -a $right($ticks,4) start | timerbar 12 1 echo 6 -ag $!right($ticks,4) timerbar sees foo properties as: secs $!timer(foo).secs reps $!timer(foo).reps | /timerfoo 2 5 echo 4 -ag $!right($ticks,4) timerfoo sees foo properties as: secs $!timer(foo).secs reps $!timer(foo).reps


Reminder that the last 3 digits of the left column show passing of fractional portions of a second. The above displays similar to:

Quote:

8332 start
* Timer bar activated
* Timer foo activated
9346 timerbar sees foo properties as: secs 4 reps 2
0344 timerbar sees foo properties as: secs 3 reps 2
1343 timerbar sees foo properties as: secs 2 reps 2
2341 timerbar sees foo properties as: secs 1 reps 2
3339 timerbar sees foo properties as: secs 0 reps 2
3355 timerfoo sees foo properties as: secs 4 reps 1
4338 timerbar sees foo properties as: secs 4 reps 1
5336 timerbar sees foo properties as: secs 3 reps 1
6335 timerbar sees foo properties as: secs 2 reps 1
7333 timerbar sees foo properties as: secs 1 reps 1
8347 timerbar sees foo properties as: secs 0 reps 1
8347 timerfoo sees foo properties as: secs 5 reps 0
* Timer foo halted
9345 timerbar sees foo properties as: secs reps
0344 timerbar sees foo properties as: secs reps
* Timer bar halted


The timerbar's final observation of FOO is not always during the same $ticks interval. However even in this example where they were during the same $ticks, timerbar sees foo.secs as 0, but zero ticks later timerfoo sees that same .secs jumping from 0 up to 5 even though foo won't be existing 5 seconds in the future.

Quote:

It is simply meant to represent the delay until it is next triggered based on the delay value.


If you're saying that .secs returns a value based on the original delay setting regardless whether it's going to execute again (or even if the timer was created with repetitions=1), that isn't consistent when triggering a timer with -e:

Code:
//echo -ag $right($ticks,5) start | timerfoo -m 2 999000 echo 4 -ag $!right($ticks,5) foo sees foo: secs $!timer(foo).secs reps $!timer(foo).reps delay $!timer(foo).delay | timerbar -m 1 5000 echo 6 -ag $!right($ticks,5) bar sees foo: secs $!timer(foo).secs reps $!timer(foo).reps delay $!timer(foo).delay | timerfoobar -m 2 5050 timerfoo -e



Quote:

15043 start
* Timer foo activated
* Timer bar activated
* Timer foobar activated
20066 bar sees foo: secs 993 reps 2 delay 999000
* Timer bar halted
20113 foo sees foo: secs 993 reps 1 delay 999000
25168 foo sees foo: secs 988 reps 0 delay 999000
* Timer foo halted


In this example, both of foo's executions are triggered by -e, and for the final foo execution it doesn't show the original 999 seconds or the actual 0 seconds. Instead timerfoo shows the same externally viewable countdown value seen by timerbar, something it's not doing when -e is not used.

I'm not suggesting that the .secs reported by -e should be changed, just that it's not being consistent with the non -e behavior. It is useful for a script to check .secs to see that it was triggered early by -e, but it doesn't make sense for a normal non -e timer to report 'delay-1' during an execution where it won't exist in the future.

Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote:
I was not objecting to .secs being zero, I was saying that .secs on the final execution of a timer should always be zero.

If .secs is zero, this could mean that it is a /timer N 0 call and is going to execute at the next timer event, which will be in zero seconds - in other words, immediately. It does not mean that it will not trigger again. So a zero value cannot be used as indication of final execution. The .secs property is not meant to be used for that.

Quote:
In this example, both of foo's executions are triggered by -e, and for the final foo execution it doesn't show the original 999 seconds or the actual 0 seconds. Instead timerfoo shows the same externally viewable countdown value seen by timerbar, something it's not doing when -e is not used.

It does not show 999 because millisecond timers are not precise - the value depends on how much time has passed since the last trigger. There is also the issue of rounding which will have a different effect on second vs millisecond values.

Joined: Jul 2006
Posts: 4,144
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
Quote:
If .secs is zero, this could mean that it is a /timer N 0 call and is going to execute at the next timer event, which will be in zero seconds - in other words, immediately. It does not mean that it will not trigger again. So a zero value cannot be used as indication of final execution. The .secs property is not meant to be used for that.
That's irrelevant. The claim is not that getting 0 can't mean it's a /timer N 0 call, it's that .secs returns the number of seconds left before the timer triggers, this is written in the help file. In OP's first example, .secs DOES NOT return that value in the last execution.

Code:
//timera 5 2 echo -s $!timer(a).secs
This much better example displays:
Quote:
* Timer a activated
1
1
1
1
2
* Timer a halted


First (this is not the problem that was reported but I'd like to hear about this), let's note that '1' is incorrect here, when the scripting engine is running the /echo -s command, the timer has already triggered, or "it's currently triggering". If you consider it has already triggered (and there are repetition left) then it will trigger again in 2 seconds not 1 second, therefore .secs should be 2. If you consider it is still triggering and then it should be 0, the value 1 does not make sense.
However this is an old behavior which can't change: way too many scripts are already using $calc to do a +1 (which correspond to OP's -1).

Now what is being reported is this '2' in the output. This time, we are at the last repetition of the timer, so it does not matter what if you consider the timer to have triggered or to be triggering: the timer IS NOT going to be triggered again, therefore the timer is certainly not going to be triggered in 2 seconds, therefore .secs should always be 0 in this last repetition, which is the bug reported here.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote:
In OP's first example, .secs DOES NOT return that value in the last execution.

Yes, that is because returning 0 in this context could mean that it is about to trigger again, ie. it may be a /timer N 0 call. What you are requesting is for .secs to return 0 in this context even though it could mean either "about to trigger again immediately" or "is never going to trigger again". That makes no sense. The only change that could make sense is for .secs to return -1 if it is not going to trigger again. However, this could have backwards-compatibility side-effects, so it cannot be changed.

Joined: Jul 2006
Posts: 4,144
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
I don't understand why you are focused on what returning 0 could possibly mean in others situations, it is not relevant, we are talking about one specific situation (basically, using nonzero values for the delay and the repetition) and in this one specific situation:

-the value returned by $timer().secs does not match the definition of the help file
-it cannot be observed that $timer().secs returns the number of seconds left until the timer triggers
since indeed, the timer has reached its last repetition, it is not going to trigger again, therefore it's not going to trigger in 2 seconds, unlike what my example suggests. That is all that is being reported.

Quote:
What you are requesting is for .secs to return 0 in this context even though it could mean either "about to trigger again immediately" or "is never going to trigger again". That makes no sense. The only change that could make sense is for .secs to return -1 if it is not going to trigger again. However, this could have backwards-compatibility side-effects, so it cannot be changed.
No, what we are requesting is first, an aknowledgement that $timer().secs is indeed returning a wrong value because of X, or that, no, $timer().secs is not returning a wrong value because of Y. It's not much that we need $timer().secs to return that or this value, (given the context we can check that .reps is 0 and therefore we could workaround .secs not returning 0) it's just an observation that $timer().secs simply does not do what it's supposed to do (according to the help file) in this situation, we are not even looking at others situations, they are not relevant to the observation.

Of course, according to the help file, for me, $timer().secs should be returning 0 in this last repetition.
There's no relationship between this situation returning 0 for .secs and a different "/timer N 0" situation also returning 0, it looks like you are viewing the fact that both situation can return 0 for .secs as a problem but it is absolutely not a problem as far as I can see, I don't see the concern here but if there is one, please enlighten me!

Last edited by Wims; 22/11/17 05:38 PM.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Quote:
I don't understand why you are focused on what returning 0 could possibly mean in others situations

I mention it because it is important for consistency. It would make no sense for a value to have different meanings in the same context. So, I can confirm that this is not a bug and is simply the way .secs was implemented. It is not meant to indicate that a timer has finished and will always indicate the delay value regardless of whether the timer has ended or not. Thanks for your comments everyone.

Joined: Jul 2006
Posts: 4,144
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,144
Well some feebacks.

Originally Posted By: khaled
It would make no sense for a value to have different meanings in the same context.
it wouldn't, the idea here is that the context is completely different and it's ok to have 0 returned in both context, you just missed the point (and I tried very hard to clarify)

Yes $timer().secs having a value of 0 is fine, nobody objected that:

Originally Posted By: maroon
I was not objecting to .secs being zero, I was saying that .secs on the final execution of a timer should always be zero.
Originally Posted By: khaled
What you are requesting is for .secs to return 0 in this context even though it could mean either "about to trigger again immediately" or "is never going to trigger again". That makes no sense. The only change that could make sense is for .secs to return -1 if it is not going to trigger again. However, this could have backwards-compatibility side-effects, so it cannot be changed.
Again we weren't requesting anything we were reporting that the behavior does not match what the help file says, be it because the help file is incomplete or because the behavior is wrong.

This is the issue that was reported, that $timer().secs on the final execution of the timer is not 0. Why do we claim it should be 0? Because the help file says so, let me quote quote the help file:
Quote:
$timer(3).secs returns number of seconds left before timer is triggered
and versions.txt for the sake of completeness:
Quote:
Added $timer().secs property, returns number of seconds left till
timer is triggered.
Now I quote what you said in this thread:
Quote:
It is simply meant to represent the delay until it is next triggered based on the delay value
This is a huge difference, the help file is not mentioning at all the value being based on the delay. It absolutely needs to include this detail otherwise .secs should do what it claims to do: truely returning the number of second before the timer is executed again, be it 0 if the timer is not going to be executed again.

Please add the 'based on the delay' bit to the help file, maybe it should be 'return the theorical time before the timer is triggered again, based on the delay.' but maybe that's scary for no good reason.

Last edited by Wims; 16/06/18 06:14 PM.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel

Link Copied to Clipboard