Well, it looks like I thought the change with the millisecond usage was causing the issue but indeed it behaves the same on 6.35.

But that doesn't really change the original intention of my report: wasn't it intended for /timer to use a 32bits signed int for the delay value? Why is the value 2147483647 overflowing in the first place?
I made the report because I believe a value of 2147483647 should be used as it is without overflowing. Why allow 2147483647 if it's not going to be used as it is? Was it an oversight when implemented?
It all really depends on what was intended in the first place but the behavior makes little sense to me.
Quote:
I could change this so that /timer checks for values larger than 2147483 and halts the script with an error immediately
Naturally, since the current behavior makes little sense to me, this change also doesn't really make sense, why is the value 2147483 unacceptable here?
Any change at this point would break scripts, but allowing the value to contain number up to 32bits signed int (which is what I propose) would only cause scripts who were not expecting a 32bit signed int to be used, to break. I believe my proposal would break far more less script.


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