INDEV conceptual: make use of hacc to catch noslowdown?

[asofold]

The hacc sub-check of survivalfly is monitoring average combined-medium (e.g. air+ground or air+water) speed, with a rather simple bucket(s)-overflow mechanism.

The idea is to make use of this and similar tracking technique to catch more of the "noslowdown" type of cheats. Another already implemented information would be the "past move tracking", which contains detailed information about moving events and can be set to monitor arbitrarily many past moves in theory. Other technique and how to make use if it are thinkable.

---

Conceptually we'll have the question of how to trigger an actual detection and how to punish, if all we know is that something already happened and it's been bad, without opening new ways of abusing that for cheating (think of how survivalfly uses to set players back to their last ground positions). Depending on how good the detection is in terms of false positives, there are still things one can do.

• Prevent an action directly, where possibe. (It's possible to prevent shooting the bow, projectile damage yould be cancelld, or consuming an item prevent, such.)
• Set penalties, like reduce nodamageticks, reduce damage, increase damage dealt by attackers (slightly problematic), make checks more sensitive, timed penalties...
• Let users decide about penalties and just provide the actions to configure.
• Feed the simplistic improbable check (combines odd events and frequency of certain events).
• Feed (to be added) state machines, in terms of a more complex decision, where multiple inputs are combined with logics and arithmetics to form some kine of judgement.
• (Mid term judgement, three-strikes or similar, when sure kick / disqualify...)
• (Still could consider to also set the player back to a position so and so seconds away, if avaialable: either track multiple past positions or use alternative penalties 'if applicable A else B' - drawback always is that parkour setups including skywars typically have a problem with this kind of set back strategy.)

---

Before deciding about how/what exactly to feed/trigger, one could roughly estimate what/how relevant information can be gathered for which type of area of cheat:

• Events covering a sequence like interact-pause-action_done, and which should mean a maximum on-ground speed to be applied, like shooting the bow, eating - without slowing down: technically we would need to monitor something like the speed above the maximum for pulling/eating. Concerning performance, it could be triggered/reset with any interact event and evaluated with shooting/eating.
• Events that slow down the player to 'friction only', like opening the inventory and switching positions of items. This concerns auto-armor, but it also concerns other types of inventory management, where we could relate how players move with how much they did while moving. Past move tracking can help, but they could also distribute inventory management to happen with a resonable delay, while moving (cheat). So here a larger amount of past moves can be used to examine one or two seconds of past moves (temporarily or always remains to be seen), and in addition one can still check for the average speed to judge how difficult this would be for a vanilla player.
• (In most cases friction is allowed, e.g. during jumping, so there is not always a huge difference.)
• (Accounting for server side lag and possibly client side or networking side issues may be of importance, if we use time measurement.).
• (Tracking more precise latency estimates could also be of use, e.g. because items are not in the hotbar, if the server hasn't yet seen them, though this example depends on how/where client side predicition is used.)
• (Of course it could be interesting to share as much infrastructure as possible between checks, for performance reasons. Some only need a trigger and temporary awareness.)

---

Advanced methods could involve judgement about what kind of preparation is necessary to do something like shooting a bow (not really the topic here, but one of the next things to consider):

• Is noticing a player necessary/relevant, e.g. with bow vs a sneaking player? This could be too complex to track without AI-like methods, however a detection might run on top of abstractions that could follow from looking at it from here on.
  • Is aiming necessary? You can pull the bow and keep aiming then (that's not hacc anymore, too easy to detect running there), but there may be cases where we can use information about how/where players had been moving to get an estimate about if this is possible with/without aiming. However this makes more sense to check, once they actually hit something, so one might want to store some information to use upon hitting.
• Was inventory management necessary to do/eat something. This means an even longer slow down, or might/could/should be related - potentially light-weight could be state machines for tracking sequences of not having slowed down, accounting for differing speed/acceleration limits selectively.
• Of course the frequency of difficult actions should also be an interesting, similar to improbable, but likely better with state machines that are tied to 'much related contexts', rather than triggering with false positives in the moving checks (past bug hopefully, but a good example).
• In cases where action is fast and difficult to do, but no violation can be triggered, because professionals can do it too, you could still feed state machines for estimating the skill of the player, and make use of this kind of judgement in other checks or as part of other state machine evaluations.
• Judging (context-dependent ~ mining, archery, melee, parkour, picking flowers) skill can be quite interesting. (Possibly further...)
• Why state machines... basically we'll have a lot of functionality in need for generic counters, which then are supposed to trigger other counters (actively or upon request), thus some concept like this will certainly be added. Another example could be unsneak-move-sneak to avoide detection while moving at full speed. Quite generic detection can evolve around relating taken distances to the frequency of toggling sneaking (unsneak rather), shorter term averages on the one hand, but also detecting the sequence of unsneak-then-move.

[L4BORG]

Just a quick thought: This could be used to block AutoArmor too? At least partially? If a player is moving he shouldn't be able to click in own inventory or any inventory for that matter (only his own hotbar can be used).

[asofold]

Good point, updated description.