Players standing in the spawn area

[6r1d]

There are often people who stand at the /spawn area for half an hour or so. I asked about auto-kicking them, because it might leave more slots for joining players in the long run. We can monitor their activity, it might often look like "a player logged in, no other records". As @S-S-X said, it'll be nice to check their activity patterns:

• dig count
• chat
• registration date
• hours / days played
• dig / craft / build count
• dealt damage

[SwissalpS]

One reason for moving to click activated mosaics, is to reduce the load checking player positions. This inspection algorithm shouldn't re-introduce that load. Otherwise I'm OK with the idea of trying to find a reason for this behaviour.

[thomasrudin]

Are we talking about newcomers or regulars, if it is only for newcomers i'd like to implement a kick-and-cleanup-function (database-stuff) after a reasonable amount of afk-time...

[SwissalpS]

so far I have only seen cobble and maybe stone players parked at spawn. Players that have been playing seem to be parked at their own places or in mines.

Edit: tried logging on with my friends mobile. It took so long we finished multiple cups of tea/coffee before I could show him pandorabox. We even went for a short walk.

[S-S-X]

if it is only for newcomers i'd like to implement a kick-and-cleanup-function (database-stuff) after a reasonable amount of afk-time...

Database cleanup should probably be separate functionality, some periodic job that removes accounts not seen for some time and XP less than some predefined amount.

If more aggressive cleanup (bit higher XP accounts) is required then maybe add some cap like 1k XP and allow to be not seen for 2*XP+168 amount hours. Then 0 XP players would have 1 week not logged in before deleted and 1k XP would have 90 days. 1k XP equals digging 11 stacks of something.

Idea would be to count inactive days since last seen in server (hours since logged out) and stop watching account after certain XP level has been reached.

[thomasrudin]

Idea would be to count inactive days since last seen in server (hours since logged out) and stop watching account after certain XP level has been reached.

It is not that important, i have a cleanup-script which removes player that didn't have interaction with the world yet: https://github.com/pandorabox-io/pandorabox.io/blob/master/scripts/delete_player_without_metadata.sh

We are basically talking about an afk-kick, right: #294

[6r1d]

We are basically talking about an afk-kick

Yes. Actually, I haven't thought we have a way to check if we have enough slots.

I think it's possible to send a detached formspec and a sound notification to some players to try and grab their attention, then kick after a given interval.

It took so long we finished multiple cups of tea/coffee before I could show him pandorabox. We even went for a short walk.

Uh-oh. I think most of that issue stems from the amount of textures. I wonder if it's possible to make current textures more compact without losing colors.

[S-S-X]

Clearly something must be done about this, There's stacks of AFK players at spawn already !!!

[thomasrudin]

Inactivity timeout is at half an hour for now...

[SwissalpS]

may I propose to only kick if in certain areas? and/or certain XP/priv is not kicked? I'd like to do the coding if that should be interesting

[thomasrudin]

may I propose to only kick if in certain areas? and/or certain XP/priv is not kicked?

Sounds good :+1: what would be a good xp value for not-afk-kicking? around 100k xp?

I'd like to do the coding if that should be interesting

Sure thing: i cloned the repo because it is relatively small and did not look maintained: https://github.com/pandorabox-io/afkkick

[SwissalpS]

100k sounds reasonable to me, that's copper and those tend to stick around with good intentions.

I was thinking of transit_location as mod name if it should only affect certain locations. This would require far less checks than current afkkick is doing.

If it's supposed to kick players from anywhere, we can build on current afkkick mod. (the main architecture seems to be same no matter) of course this is much simpler to implement than locations which would require some kind of location registration API.

[thomasrudin]

If it's supposed to kick players from anywhere, we can build on current afkkick mod. (the main architecture seems to be same no matter) of course this is much simpler to implement than locations which would require some kind of location registration API.

The lazyeasy way would be to customize the afkkick mod with an xp-check

I was thinking of transit_location as mod name if it should only affect certain locations.

You are thinking of spawn, right? There is a setting to get that:

local spawn_pos = minetest.string_to_pos(minetest.settings:get("static_spawnpoint") or "(0, 0, 0)")

This would require far less checks than current afkkick is doing.

I don't think that matters, checking playerpositions every second is quite light-weight in cpu-terms...

[SwissalpS]

You are thinking of spawn, right?

yes for now on pandorabox only spawn is in question. I was thinking of making something with more general-use for other high traffic areas. But then maybe the new beacons can solve this in a much more elegant way. #430 There is at least one player who would like a feature that keeps visitors from dallying around his base, it's maybe better to solve that in a way that allows any player to configure and not only server-admins.

I'll solve the leazy way for now ;)

[BobFred7]

There is at least one player who would like a feature that keeps visitors from dallying around his base,

Who is that? You?

[SwissalpS]

No, not me. I feel honoured if others actually want to visit my mess. :)

[SwissalpS]

SX: warnTime would be really nice if it would warn early when afk time is high, like first warning 5min before but just once not looping like last warnings

SX: I would maybe add admin check there too, it could easily fit on line 70 if 0 < #playerName and not isadmin(playername)

SX: I dont think it is really required or noticed for long time but could check for privs privilege: minetest.check_player_privs(playername, {privs=true})

SX: there's no point in checking every 2 seconds if inactivity time is very high checkinterval could be 2 seconds or 1% of inactive time whichever is higher

[SwissalpS]

There are two propositions (untested)

• minimal branch: minimal interval, no warnings
• master branch: somewhat overkill for our needs. Could be used to easily change to XP check only etc.

(does not yet include any of SX's above suggestions)

[thomasrudin]

SX: I would maybe add admin check there too, it could easily fit on line 70 if 0 < #playerName and not isadmin(playername)

IMO: there should not be a distinction between admin/non-admin for afk-kick (but i'm not complaining if there is one...)

[S-S-X]

SX: there's no point in checking every 2 seconds if inactivity time is very high checkinterval could be 2 seconds or 1% of inactive time whichever is higher

Actually even better could be to remove for..looping over players and check 1 player every 1-2 seconds. This would even allow heavy checks like list of multiple defined areas and custom rules for each area without causing much overhead (I am assuming that mt executes all mods async single threaded?). Probably not needed but still would took away a lot of operations per iteration by dividing ops over longer time frame.

join / leave hooks should then implement state variable updates and globalstep hook should implement iteration state updates and everything else it already implements. But this would require care / verifying behavior with possible race conditions between disconnect / connect / globalstep.

edit. Maybe add few more privileges to exclusion list: ban and/or kick privs. Not sure if this currently affects anyone on pandorabox because of xp_redo but still. Take xp_redo away and it seems like a lot more important thing depending on configured areas.

Again, even better: add possibility for excluded privs in configuration.

[SwissalpS]

@S-S-X thanks for the great input

I've tested minimal branch and will PR that to pandorabox repo for now.

[SwissalpS]

I have summed up possible further development on this mod on my fork's issue #1