Two changes:

1. add a command to list worst lag sources in order of worst to best. This means a list needs to be maintain of laggy locations independent of player resolution by moving away. Could/should tie into LagScanner and keep track on a chunk by chunk basis.

2. Add a command to teleport to identified lag sources; "/afklag start" command should start a session of teleporting to lag sources. Current and new admins joining the game can simply type "/afknext" to go to the next one that hasn't been visited, making it easy for the team to cycle through the list.

In reviewing logs, looks like in some cases the bans on "nearby" players aren't lifted if the core culprit is cleared. This is very bad. We should review carefully and make sure everyone caught in a dragnet is released, always.

the pom has the version as 1.3.5-${build.version} which makes the version in the maven repo literally that. This means AFKPGC can't be added as a maven dependency because maven doesn't read 1.3.5-${build.version} as a literal string and can't find the version in the repo

With the expected high TPS, scans and subsequent warning bans won't be performed. Let's have the plugin warn players (max every 15min) about laggy areas so this profiling can continue to give players input about their setups. We don't want everyone to forgot to optimize their industry.

TPS tanks quickly and in very precise intervals. We might be able to focus the plugin's targeting apparatus by tracking and prioritizing player joins on intervals that record significant TPS drop. Similarly, we could track TPS upticks and see who departed the server in those periods.

We shouldn't exclusively deal with those players, but could be a strong indicator; e.g. skip the movement analyzer and directly scan their environments.

So multiple people confirmed that if you pop filled chests/double chests, you receive a ban right away. The amount of dropped entities seems to be the reason.

A LagBanWarningEvent and AFKKickWarnEvent would be really nice

From @suirad : If a single player is building a machine, and the server idenifies it as a lag source, and changes all of the laggy parts of the machine to an alternate block, the player can deduce that they must scale back their machine.

And to be nice to them, we could add exemptions of the swaps based on the level of reinforcements per machine block; So lower/none rein are first to go

While operators are moving through /afkpgc inv they need some way to mark visited chunks that deserve a later return.

All bans should be issued via CBanManagement; local storage should be removed of bans should be removed.

Per https://www.reddit.com/r/Civcraft/comments/3fv5sw/the_new_lag_detecting_auto_banning_afkpgc_is/ctsgvrt

getBanList states "Bans by name are no longer supported and this method will return null when trying to request them" yet that is the banlist type being retrieved. Someday it will break.

Does getBanList return the MC global ban manager? It looks like we should be able to differentiate this ban from others via the reason. It is also saving out a list of banned players though, so why not use a copy of PrisonPearl's ban manager? Alternatively, these bans shouldn't persist across reboots so just keep a list of UUIDs and block players at the async pre-login event.

We have had numerous reports of players being constantly kicked for being AFK while they are moving around and interactive with the world. This has been going on for a while.

One lead that we got today, one of these players has very recently changed their Mojang name and is thus having their name changed by NameLayer. They are now constantly being kicked for AFK when they shouldn't be.

Chunk computation caching index isn't working properly. I'm finding evidence that cache is returning values for different chunks. Investigating.

Count redstone events

Count water / lava flow events

involve in computation matrix

Based on some discussion with ttk, @Maxopoly let's modify BotDetector to have a second "below perfect" threshold at which point it starts keeping track of player locations. That way, if we then fall below the "aggressive" threshold, we'll start prioritizing likely lag drivers right away without additional delay.

Bonus: it'll allow better sample lengths for location, which will help the bounds detector be more accurate.