AntiAFK Look/Follow/Wander modes and general improvements

[0xTas]

Type of change

• Bug fix
• New feature

Description

EDIT - Context:
AntiAFK currently performs its actions on a random delay that is not configurable, which is unnecessarily restrictive and annoying.

For example, on 2b2t you must only send a single hand swing packet every ~15 minutes to avoid being kicked for AFK. This means that with the ability to configure your swing delay, you could leave AntiAFK on 24/7 without having to notice or think about it, and still never get kicked for being afk. With the current version of Meteor's AntiAFK, however, your only option is to watch your player throw hands every few seconds at all times, or otherwise explicitly enable/disable the module when you "plan" on going AFK for a bit.

I do understand that some people might like/want/need the random delay so I have left it as the default behavior for most actions that already used it. I have also added a fun Look mode with some simple but satisfying-to-use follow/wander modes.

Additions

• Look mode which rotates randomly or tracks an entity based on the sub-mode settings.
• Added random yaw speed setting to spin mode and strafe duration option to strafe mode.
• Follow & wander sub-settings which follow the targeted entity or wander in random directions.
• Added timer settings to jump/swing/sneak/strafe modes, while preserving random time capabilities.

Fixes

• Changed module package to reflect its category (movement -> player).
• Made jump and sneak work properly while the their module modes are active (you could not jump when jump was enabled).

Related issues

Probably #3944
Twerking for #2175

How Has This Been Tested?

In singleplayer and on 2b2t.

Checklist:

• My code follows the style guidelines of this project.
• I have added comments to my code in more complex areas.
• I have tested the code in both development and production environments.

[RacoonDog]

no point in having jumpRate, swingRate, sneakRate, strafeRate, and lookRate having a minimum of zero when they also have a boolean setting toggling them

setting the minimums to 1 would also remove several if (xRate.get() > 0) { conditions everywhere

[RacoonDog]

fyi, i'm unsure if this is intentional or not, but Random#nextInt's upper bound is exclusive, so random.nextInt(99) == 0 is a 1/99 chance, not a 1/100

[0xTas]

fyi, i'm unsure if this is intentional or not, but Random#nextInt's upper bound is exclusive, so random.nextInt(99) == 0 is a 1/99 chance, not a 1/100

Yes this was intentional, I mostly just kept the bounds used in the previous version of the Module for the random fallbacks.

no point in having jumpRate, swingRate, sneakRate, strafeRate, and lookRate having a minimum of zero when they also have a boolean setting toggling them

setting the minimums to 1 would also remove several if (xRate.get() > 0) { conditions everywhere

I should probably have clarified the main motivation behind this PR a bit better. AntiAFK currently performs its actions on a random delay that cannot be configured, and is quite fast (random.nextInt(99) == 0). However, on some servers such as 2b2t, in order to bypass the AntiAFK plugin you must only send a single hand swing packet every 15 minutes or so.

Using Meteor's AntiAFK is annoying because it has me constantly swinging which is an eyesore imo, so I need to consciously enable/disable AntiAFK when I want to go afk. On the other hand, with something like Rusherhack's AntiAFK I can set the swing delay manually, leave the module on 24/7, not even notice it, and also never get kicked.

So the xRate.get() > 0 conditions are my way of allowing the module's previous behavior to still exist (and exist by default) while still allowing people who wish to configure their action delays to do so.

The look mode(s) were just something I had fun throwing together on-the-spot while I was tinkering.

[0xTas]

Main post was edited to add some additional context.