AFK detection

[zorro]

I'm pretty new to eve source and Python, so need my guess checked by someone more experienced in those topics.
Recently I found that eve client has ability to check if user is AFK and apparently sends this information to server via RemoteSvc('charMgr').SetActivityStatus(const.PLAYE R_STATUS_ACTIVE, self.numSecondsAway) - see gameui.__CheckForAFK
It seems that AFK means absence of keyboard/mouse events - see uilib._lastEventTime and when it's updated.

So, first question - am I right on this?

And if so, second question - what does it mean, when player is AFK, but server still receive "active" requests from him (like 'activate mining laser' or 'target a rat') ?

[civan]

I can't find it in the crucible 1.1 or 1.0 code. Can you give the file and line number?

[wrunning]

I just had a look myself, can't say I noticed this before...
Mainly in EVE-TRANQUILITY\eve\script\parklife\gameui.py.It seems to flag someone being AFK after more than 10 minutes of no input events.
Hmmm....

[civan]

*smack* I have been looking at crucible 1.0 sources. Ideed they check for messages to the eve window, and it has been added in crucible 1.1
Considering that most eve bots are pixel bots I don't think this is a dedicated bot fighting code, rather something to keep in mind if you dont send any WMs to eve.

[wrunning]

Considering they have the AppGetAwayStatusTextForCharacter method in their ESPHtmlWriter class, I'm hoping this will be used to actively check AFK status against a reported "mining bot" or something alike.Guess time will tell...
And yes, unfortunately I've been lazy enough after last patch to not check for all the diffs :(

[civan]

In that case it is pure fail, as all the pixel bots will be false negatives.

[zorro]

I don't think it's bot fighting code either, but it could be used to detect pure injection bots. And seems CCP is especially dislike this kind of programs, so additional caution there can save some accounts from perma-ban.

[christallire]

They failed to implement this silently because i've noticed this when those codes generated exception within its own codes, EPIC FAIL
especially for me because i didnt DIFF each version of compiled codes