mIRC Homepage
Subj, features do not want to live together
You need to elaborate... or at least use full sentences.
So what you're saying is that if I use a custom theme that changes what I see on my side when I type something and then sends the message to the server, it shouldn't reset my idle time? That sort of script would use a HALT so that you only see your custom display instead of the normal display. mIRC *should* reset your idle time even if halted.
mIRC Doesn't reset your idle time fromt he on input event. It resets your idle if you send a PRIVMSG, NOTICE, or a few other things like JOIN, PART, etc. This is b/c your idle time with the server gets reset. Generally mIRC tries to keep you idle time as close to what the IRC server has
mIRC actually resets your idle when you press enter in an editbox (as well as other interactions), NOT when you send a message. For example, typing //timer 1 5 /msg $active hello will reset your idle instantly and NOT reset your idle when the message is actually sent 5 seconds later by the timer.

mIRC's idle measurement is not intended to match the server's idle time at all. The server idle time is reset by sending a PRIVMSG or certain actions like joining a channel. Notices don't even reset it, nor do most other server commands.

I don't think it's appropriate to prevent mIRC's local idle value from resetting, even if you halt ON INPUT.
Maybe mIRC should also reset the local idle time after you perform an action via a popup or double click in a channel or status window. Then again, maybe there's a reason mIRC only resets the idle time when you enter text, whether it does something with it or not.
Since the whole purpose of halting an event is to override it's built in operation, resetting your idle time is indeed a bug. I've always used /resetidle I could have sworn you needed to use it when halting an input event....
I'm confused.. What's the rationale behind *not* resetting idle time? If a user types text into the editbox, they're clearly not idle... I don't understand why ON INPUT should ever bypass /resetidle. Is there a specific use case here?
the ONLY case I can think of is to be able to perform client side commands and not interfere with SERVER side idle times. For example, if Im testing out an alias to be performed solely client side, why should my idle time SERVER side change? I didnt do anything SERVER related to change that idle time. it actually produces a FALSE idle time. server idle time should have NOTHING to do with what client specific actions are doing UNLESS they interact with the server.

This may be a nit picking or not good enough argument, but it's the only case I can see to change it. personally, I dont understand why //echo $me would cause the idle time to change - sure I'm not idle cause I'm still active, but not to the SERVER.
While I agree that using something like //echo -a $me should not reset your idle time, I can see an argument that using the ON INPUT event should reset your idle time, since I can't think of any situation where a script that uses the ON INPUT event would not send something to the server.

I'm not saying that there isn't one or more situations where the ON INPUT event is used and no information is sent to the server, I just can't think of any.
Your SERVER idle time doesn't change by typing //echo -a $me, your LOCAL idle time does. If $idle represented your SERVER idle time, you would have a point, but it does not.

I think the problem here is that people have the wrong expectation of what /resetidle and $idle represent. As drum pointed out, $idle is *not* meant to accurately match the SERVER, it's meant to be a representation of your LOCAL idle time. This distinction *does* matter, specifically because of the example you pointed out: performing commands locally should not affect how other clients see you (as idle or not), but mIRC *should* be aware of the fact that the user is currently active, at least with respect to local commands. The identifier is not meant to accurately report what the server sees. In a sense, mIRC's $idle is more accurate, because it considers actual user activity, not just "server command" activity.

Note that $idle is not used in any way to report your idle time to other clients, nor is /resetidle used to reset your idle time with the server. This is all *local* book-keeping. If you don't send a command in ON INPUT, your idle time with respect to the server will not change. Other clients will still be able to see that you are idle. Specifically, "//echo -a $me" will not change your idle on the server, and clients will still see you as idle. The only idle time mIRC is resetting is its local counter, which *is* meant to keep track of your local activity.

For those who don't believe that $idle is truly meant to represent local time, consider this: if mIRC *was* trying to keep track of server idle time, /resetidle would be inherently obsolete. Server idle time is reset when commands are issued (minus a few exceptions), mIRC would simply reset when these commands are issued. A manual /resetidle is only necessary if we are talking about local activity, when arbitrary more complex interactions (like ON ACTIVE, for instance) could potentially be used to reset your "idle" time. Also, $idle was added in v4.7 (1996), and therefore pretty much predates the concept of server idle time tracking. It was certainly not meant to match server idle time then (because there was no such thing), and it's likely the same story now.
you know, I wonder if *I* was thinking about a "cancel away on keypress" when I wrote that vs resetting idle time. That is VERY likely, because my argument doesnt make sence - meaning, I was arguing a realty of how it works CONFUSING it with something else lol It happens, I dont use mirc like I used to.
Something like this should solve your issue:
on *:input:*:{ if ($halted) { resetidle <time in seconds> } }
You might want to re-read what was being said. It already resets the idle time regardless of whether or not you halt the input event. The request is for it to NOT reset the idle time. Yours really doesn't do anything special because it will already be reset automatically.

I still don't see a legitimate reason for the local idle time to not be reset when you do something. Obviously, if you do something, you're not idle.
Originally Posted By: Riamus2
I still don't see a legitimate reason for the local idle time to not be reset when you do something. Obviously, if you do something, you're not idle.

Which is exactly why I think that resetting it after every editbox input (halted or not), and not doing so after a popup or double click command is inconsistent behavior. Perhaps there's some obscure reason behind this, though.
Well, if so:
on *:connect:timer 0 1 set % $+ lastidle $+ $!cid $!idle
on *:start:unset %lastidle* 
on *:input:*:if ($halted) { resetidle %lastidle [ $+ [ $cid ] ] }

This should reset the idle time to the last known idle time after an input event that was halted.
Ah, I see what you were doing now. Yeah, you can manufacture an "idle" time that way.
© mIRC Discussion Forums