Hi guys, what about something like:

I don't know, something that refers when someone idles, also, it should have something like, 120s, 2m, 1h, something that tells you right when someone hits idle time. or, is there something similar to this that I don't know about?

you have $idle but not event

lol, i know, but, in a LOT of channels, when I'm idle, I have to deop, and, when I idle, usually, I don't have time or I forget to deop.

This is easily scriptable, as I'm quite sure you realize.
Example:

Starts a timer when you join the channel, which is connection and channel specific. Timer is set for 310 seconds (5 minutes 10 seconds). At 310 second, your idle time is checked, and if your idle time is 600 seconds (or more) and you are opped in that channel, then you automatically deop.

On a sidenote, I can see where an ON IDLE event could be handy for channel control, where you don't want people idling for long periods of time (example a help channel for people that aren't helpers).

I can also see where the ON IDLE event, as you suggest, would make a script like the one I just wrote a lot shorter.

I dont see a lot of use for it concidering the ease of scriptability. But i cant see it being too hard to implement either, mirc already (internally) tracks idle times of all users in common channels (for use with the nick colors options). One problem i can see though is that idle times for other users could be incorrect unless mirc checks with the server for each person's idle time when you join a channel and adjusts accordingly? shrug.

I think mIRC must already get this information, since that's what is returned when using something like
/echo -a $nick(<channel>,<nick>).idle

mIRC has its own internal idle records it has nothing to do with the server for instance, when someone joins a channel there idle time is 0s on that channel, however it could be 1377448983s on a another common channel.

I doubt it, they would have had to be idle for 43/44 years! LOL

If that's the case, then why am I able to do something like the following:
I join a channel (let's call it #timbuktu)
Upon joining I see that Fred, George, and Mary are in the nicklist
Fred & George greet me, and I respond, also saying Hi to Mary
Mary doesn't respond, so I wait for 5 minutes then issue //echo -a $nick(#timbuktu,Mary).idle
This returns a value of 16000

That's an idle time of 16,000 seconds (4 hrs 26 mins 40 secs)

mIRC has to be getting that information from somewhere, and it can't be based on the time since I joined, since it's only been a little over 5 minutes since I joined, and yet Mary's idle time in the channel is returning nearly 4 1/2 hours.

Your doing something wrong, or somethings wrong on ya system, //!echo -a $nick(#timbuktu,Mary).idle maybe ?

Do a /HOP and then test what it says, it should have started counting from the moment you entered the channel. (actually when the nicklist for the channel finsihed, but you know)

My results always match the channel join time displacement at the max.

The $nick(#blah,mary).idle is channel specific right?
Ive never seen a server spit anything out regarding a channel specific idle time, Mary's idle time could be 2 mintes on #wwfwrestling and 20 minutes on #toolsnewcd, do a whois on Mary and her idle time could say 2 seconds. Its totally unrelated.

Anyway I think is a nice idea and I see no reason why it shouldn't be implemented.
Perhaps just on *:idle:time in seconds:#chan:blah
eg.

I don't really see a half decent way to implement this beyond what we already have to be honest. In theory it does not sound like a bad idea.

But the code involved means it's got to loop through each of your channels EVERY second (or maybe a longer period of time, but people would bitch about that wouldn't they?), this means that there'd be considerable lag depending on the amount of channels you're in, and how many users are in each channel.

The other option would be for mIRC to set internal timers that reset every time someone talks, but how is it to know when to trigger an "on idle" event? I'm sure the time is stored when the person last triggered an event (quit/join/action/text/chan-notice(s)/etc), and when you perform $nick().idle, it just compares the current time against the time that is stored for that nick, for the specific channel.

So if this was ever included, it'd probably have to be disabled by default.

In theory, a decent idea. But in reality, I think it's a bit too much.

Good point, im not sure how mirc implements this, weather it sets a timestamp eg. $ctime for every user when you or they join or say something in the channel which is the most like situation. I had the thought in the back of my mind that it would increase everyones idle time by running the loop you just explained, so I thought it be not such an issue for a event to be triggered, but since you raise this point im thinking thats not the case.

assumingsomething like ....
on *:idle:600:#ircaddicts:kick $chan $nick idle for 10mins, idle elsewhere

IMO This wouldnt chew anything particully great in time up to check, and i reason this for the following...

Lets assume also that mirc keeps for each nick in each channel a value of last acivity, this being used to draw the results of $nick(CHAN,NICK).idle, i think this would be much more likely than any counter being added to each second some how. lets assume that vaklue is the same as $ctime

OK so once per second the ON IDLE system is tripped, and any ON IDLE events are searched for etc and said one above is found, current $ctime is grabbed and reduced by 600, then the channel is swept for any one with <= idle time, a loop of this nature in compiled code, even allowing for 1000 channels and 1000 users per channel is still going to be but a flash in time. Of course to do this in a mirc script would take a bit of time, even then with the right aproach you could likely get it down to workable.

Hmm, im not apposed to some type of idle checking system. My thoughts now have moved more to consistancy. What i mean is, everything in mirc scripting has to be triggered in some way (either by incoming server event, timer, or input etc). An on idle event in that manner would not be triggered in the same way, not at all consistant with the rest of the scripting language.

Maybe an addition within the address book itself. Possibly a new list type in control, or an addition to the colors settings (ability to specify an alias or command to call along side the idletime setting), maybe instead of specifying that alias or command an option could be set to call a predefined one (idletime *:*, similar to raw *:* etc), even its own tab in the address book (although doesn't seem quite a fitting type of list for an 'address book').

I dont know, i guess it just doesn't seem appropriate to have it as an event when its not triggered by interaction as other events are.

Maybe an 'idletime' similar to how raw and ctcp are setup.

Hmm, i guess any way that you think about it doesn't seem particularly fitting or consistant if its part of the scripting language. Where as something in the address book seems a little more appropriate, in the sense that other things in there (like idletime color) are done without being triggered.

I understand where your coming from, but that would also limit it to one alias/call per nick etc, where an event(s) can deal with none/some/all nicks as based on each events code, and while i agree everything(i think everthing) that is an event is tripped of by some change be it server message or mouse/keyboard activity or dcc/socket I still think it would make more sence to keep it in this area as its the one most people can readerly understand how to attach code to. of course as always, just my opion, i would be happy either way, (not that i actually can think of many times i have ever cared if someones idle)

I dont think it would be limited in that way, since the design of other address book features allow you to specify a mask/chan/network sequence/wildcards, my thinking on the alias was that the relevent identifiers be configured to work when called from within the alias specified.

I do agree though, address book is often overlooked by people.

Maybe it could be done in such a way that isn't an automatically searched and called event. Some kind of trigger command used to call the script (whatever way it be coded.. event, raw style, etc).. maybe a special type of signal, requiring a timer to trigger it every second. This would avoid mirc parsing all scripts every second to search for the event when mirc would otherwise be idle and doing nothing (quite unnecersary searching would occur if no script existed for it).

Anyways, im sure if its concidered and put in khaled would find a good way to do it.

I do not actually know, but i was of the opion that mirc didnt continuely pharse the scripts apon any event anyway, rather it used a pharsing when a script is loaded/modififed that builds some type of event points check list, that can then quickly be checked againes t on any assocaiated event. I dont see the point of pharsing all scripts for events relation to the event in progress every signle time an event occurs, I would bet its done once, then uses jump lists to go to said code.

Never really thought about it i guess, i just figured mirc kept it in memory and scanned through it that way. Still, mirc would need an internal recuring timer of its own to do something to handle idle events, couldn't hurt to require the user to create this timer so that more control can be had over the event without needing to edit the script itself.

Does make more sense that mirc would create and release binds in that way rather than parsing the data all the time.

As i understand it mirc doesnt really have timers as such, rather it has a timer list, that it checks once per second, and see if if any have elapsed and need triggring.
now assuming im correct (which im not saying in anyway i am) about how mirc pre pharses the scripts for events, it wouldnt be hard for it also check a setting to see if any on Away events existed, I however have also looked at the way you suggested, and the more i look at it now the more i see how it could well be as usefull if not more, maybe just a little harder (newer/different lol) to code to.

PS: above meaning per second timers of course, i alsoe beleive the -m timers work the same way but on a faster cycle rate 64 or 100 times per second checked, dependent on OS, likely the os's program cycle rate or some such thing.