Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improved "afk kick" system. #54

Closed
dennisjenkins75 opened this issue May 20, 2021 · 11 comments
Closed

Improved "afk kick" system. #54

dennisjenkins75 opened this issue May 20, 2021 · 11 comments
Labels
Controversial Conflicting opinions Discussion In-depth discussion with many comments Enhancement Improvements or changes to an existing feature Possible close Issue should probably be closed.

Comments

@dennisjenkins75
Copy link
Collaborator

Sometimes there are AFK players who become AFK when the server is lightly loaded, but the server becomes really busy while they are AFK, and these players don't know that they server is now busy, so they can't voluntarily log off. However, if the server were to remain not-busy, then there is no harm in leaving them logged in.

So my suggestion, as briefly discussed in #main today:

I can imagine a mod that checks if he server is at/near max occupancy for greater than some # of minutes, and if so, kicks the most idle (longest idle time) player, and only if that player's idle time is > some minimum threshold, like an hour or two. Should be long enough that a player could "make a tea" (as FeXoR mentioned) and not get kicked, but short enough to kick a group of players who've been idle most of the day.

IDK if the server currently knows the "idle time" (eg, time since last player-initiated input from their client) or not.

I'm also suggesting that the mod not make any attempt to prevent players from defeating it (ex: using a automated machine or boost cart to keep them moving). The goal is not to enforce an iron will, but to just prune a busy server of idle players so that the compute resources can be used by active players.

@dennisjenkins75
Copy link
Collaborator Author

Maybe this is a solution in search of a problem that does not exist?

@dennisjenkins75 dennisjenkins75 added Controversial Conflicting opinions Enhancement Improvements or changes to an existing feature Idea labels May 20, 2021
@OgelGames
Copy link
Contributor

@Klaranth
Copy link
Collaborator

@OgelGames
As this seems not to be a new problem, can this issue be closed?
Provided of course people are working on the related issues.

@Klaranth Klaranth added the Possible close Issue should probably be closed. label May 28, 2021
@OgelGames
Copy link
Contributor

I was waiting for @BuckarooBanzay's thoughts on 1hit's idea ^

@BuckarooBanzay
Copy link

Maybe this is a solution in search of a problem that does not exist?

Do we even know how many players are afk? I think the sanest approach would be to hook into the afk mod (or even fork it) and let it log/warn when a player wasn't active for the last x minutes.

If it turns out that most of the players are just "afk'ing" while the server is full then we could implement some kind of busy-kick thing...

@Klaranth
Copy link
Collaborator

[...] to hook into the afk mod (or even fork it) and let it log/warn when a player wasn't active for the last x minutes.

Who can do this?

@BuckarooBanzay
Copy link

Who can do this?

Potentially everybody with a keyboard, computer and some time to spare 😉

@S-S-X
Copy link
Member

S-S-X commented May 29, 2021

If done I would again suggest changing stamina mod configuration first, set stamina.tick_min = 1.

After that could think about possibly kicking dead players after 30 minutes.

S-S-X added a commit to pandorabox-io/pandorabox.io that referenced this issue May 29, 2021
@S-S-X
Copy link
Member

S-S-X commented May 29, 2021

Player can survive some about 4 hours AFK without eating ^^
This is about 12 minetest days.

@dennisjenkins75
Copy link
Collaborator Author

My intent was not to kick all afk players, only the "most afk", and only when the server is "busy".

@S-S-X
Copy link
Member

S-S-X commented May 30, 2021

My intent is not to kick any afk players but kill them if they do not consume any food for almost 2 weeks.

Basically is is a little bit about reinforcing survival thing and possibly reducing long time afk players. Like me for example, I've been afk at least half year (in minetest time) few times. I really think player should not survive that long without consuming anything.

Also it does "afk kicking" in a way that adds something to actual game mechanisms instead of outright disconnecting players with some "sorry, we don't want you here" message. Personally for survival setting I could see surviving forever without eating as bug.

Sure many players who stay afk long times will find solutions to eat single can of tomatoes every 4 hours, this is also good in my opinion as it requires at least some special setup and makes multiple long time afk accounts on single computer bit harder.

However while my intent is not to directly kick afk players causing death if not eating can still be used as part of timer to detect afk players, and without adding complicated checks for actual player actions looping over all connected players updating active time.
Instead you can just hook minetest.after to minetest.register_on_dieplayer to kick player after being dead without using respawn button for x minutes, this completely avoids globalstep loops over connected players to update status and requires only 2 hooks and 1 timer per player. minetest.register_on_respawnplayer is also event based and would be used to cancel kick timer.

About zero performance impact.

BuckarooBanzay pushed a commit to pandorabox-io/pandorabox.io that referenced this issue May 30, 2021
@OgelGames OgelGames added Discussion In-depth discussion with many comments and removed Idea labels Sep 15, 2021
@S-S-X S-S-X closed this as completed May 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Controversial Conflicting opinions Discussion In-depth discussion with many comments Enhancement Improvements or changes to an existing feature Possible close Issue should probably be closed.
Projects
None yet
Development

No branches or pull requests

5 participants