afk模块行为 about fuji-fabric HOT 4 CLOSED

我的想法：如if (System.nanoTime()/1000000 - player.getLastActionTime() > 600000) afk_player.fuji$setAfk(true);这样 awa

实际上, AfkChecker是一个全局的定时器. 它的检查周期是全局的, 但是根据每个玩家有一个lastActionTime. 换句话说, 如果AfkChecker的检查间隔为3分钟, 那么当1个玩家被标记为已挂机时, 该玩家的实际离开时间可能为3~6分钟.

之所以使用单个全局的AfkChecker, 并且使用一个较大的时间间隔. 是为了性能考虑.
AfkChecker实际上并不判断玩家是否处于挂机状态, 而只是简单地比较该玩家距离上次活动的时间差.
而当玩家发送活动封包时, 也只是简单地更新该时间戳.

这个设计和很多现成的方案相异. 当然, 使用你所提到的方案是更符合直觉的.

from fuji-fabric.

我的想法：如if (System.nanoTime()/1000000 - player.getLastActionTime() > 600000) afk_player.fuji$setAfk(true);这样
awa

from fuji-fabric.

我的想法：如if (System.nanoTime()/1000000 - player.getLastActionTime() > 600000) afk_player.fuji$setAfk(true);这样 awa

实际上, AfkChecker是一个全局的定时器. 它的检查周期是全局的, 但是根据每个玩家有一个lastActionTime. 换句话说, 如果AfkChecker的检查间隔为3分钟, 那么当1个玩家被标记为已挂机时, 该玩家的实际离开时间可能为3~6分钟.

之所以使用单个全局的AfkChecker, 并且使用一个较大的时间间隔. 是为了性能考虑. AfkChecker实际上并不判断玩家是否处于挂机状态, 而只是简单地比较该玩家距离上次活动的时间差. 而当玩家发送活动封包时, 也只是简单地更新该时间戳.

这个设计和很多现成的方案相异. 当然, 使用你所提到的方案是更符合直觉的.

哦这样啊，但是还有一个问题是getLastActionTime是不会记录持续的移动的，所以当服里有几个人在划船/跑图的时候会突然几个人一起afk这样（ ）有点怪hh

from fuji-fabric.

我的想法：如if (System.nanoTime()/1000000 - player.getLastActionTime() > 600000) afk_player.fuji$setAfk(true);这样 awa

实际上, AfkChecker是一个全局的定时器. 它的检查周期是全局的, 但是根据每个玩家有一个lastActionTime. 换句话说, 如果AfkChecker的检查间隔为3分钟, 那么当1个玩家被标记为已挂机时, 该玩家的实际离开时间可能为3~6分钟.
之所以使用单个全局的AfkChecker, 并且使用一个较大的时间间隔. 是为了性能考虑. AfkChecker实际上并不判断玩家是否处于挂机状态, 而只是简单地比较该玩家距离上次活动的时间差. 而当玩家发送活动封包时, 也只是简单地更新该时间戳.
这个设计和很多现成的方案相异. 当然, 使用你所提到的方案是更符合直觉的.

哦这样啊，但是还有一个问题是getLastActionTime是不会记录持续的移动的，所以当服里有几个人在划船/跑图的时候会突然几个人一起afk这样（ ）有点怪hh

实际上, CMI的Afk检测模块也有类似的行为, 同时将多个已挂机的玩家进行标记. 而不是逐个进行标记.
如果需要的话, 你可以改成更精准的方式. 目前这个方法的实现比较简单, 但不是非常准确.

from fuji-fabric.