High values of Improbable when derping with Bow

[Maxetto]

Short description of the issue.

While derping with Bow (moving high speed and throwing arrows at random), NoCheatPlus detects it as COMBINED_IMPROBABLE with quite high VLs.

Complete output of the ncp version command (please prefer text here).

---- Version information ----
#### Server ####
git-PaperSpigot-"4c7641d" ~MC: 1.8.8~
detected: 1.8.8
#### NoCheatPlus ####
Plugin: 3.15.1-RC-sMD5NET-b1084
MCAccess: 1.8.4-1.8.8 / Spigot-CB-1.8_R3
Features:
blocks: BlocksMC1_4 | BlocksMC1_5 | BlocksMC1_6_1 | BlocksMC1_7_2 | BlocksMC1_8
checks: FastConsume | Gutenberg | AttackFrequency | FlyingFrequency | KeepAliveFrequency
defaults: pvpKnockBackVelocity
packet-listeners: UseEntityAdapter | MovingFlying | OutgoingPosition | KeepAliveAdapter | SoundDistance | CatchAllAdapter
Hooks: AllViolations~NCP~ 1.0
#### Related Plugins ####
ProtocolLib v3.6.5

How to reproduce the issue (is it random / always happens / side conditions)?

• Take bow and arrows.
• Put Mouse Sensitivity to Hyperspeed in Minecraft Options
• Derp and fire bows.
• Profit (?)

Have you made any (noteworthy) changes to the default configuration of NCP?

Yes, I'm running with NCP Community Config. Tried also changing COMBINED_IMPROBABLE from 185 to 200.

Do you run any other special plugins that affect game mechanics next to NC+ (adding skills, machines, adding/changing blocks, other anti cheating)?

No.

Provide additional information, such as error/debug/violation logs. (For reproducible issues with moving consider: https://github.com/NoCheatPlus/Docs/wiki/Debugging#on-the-fly-debug-output-for-individual-players) Use GitHub gists or http://pastebin.com/ or similar for huge logs, or attach a (zip-) file here. For image uploads, please prefer a site that allows viewing without JavaScript, you can upload file attachments for issues right here.

• It doesn't require the arrow to hit, just fire (maybe not even that).
• Works both when charging or not the shots.
• BLOCKINTERACT_DIRECTION is fired too with this.
• Pretty easy to reproduce given enough sensitivity (I was unable to reproduce, 3 people done it instantly)
• Once doing this enough time even normal shots are counted as COMBINED_IMPROBABLE

NCP: [17:38:58] combined.improbable VL 421 (n13a32m42)

NCP: [17:40:17] combined.improbable VL 69202 (n215a322m733)

NCP: [12:31:44] combined.improbable VL 15900 (n51a312m507)

Here's a quick video that triggered the check: https://www.youtube.com/watch?v=_5BR1FTXKzg

[MarkElf]

If I had to take a shot in the dark, I would assume that it's the modified yaw rate, being at 95 rather than 380 makes it much more sensitive to snapping motions which is simulated through the high sensitivity.

[asofold]

• If there isn't a setting to skip improbable checking for shooting bows, then it'll be difficult perhaps. -> Not configurable (inventory.instantbow).
• A low yawrate trigger threshold can cause this too.
• Some other spots also have settings to feed/check improbable.

Overall, i should probably do this slightly differently - e.g. we could estimate some kind of hitting difficulty (post shot), with remembering some things that concerned the shooter at the time of shooting, instead of checking improbable directly at the time of shooting. The fastest fix would be to allow disabling it for shooting projectiles.

Checking improbable with hitting other players makes more sense, because usually it's the hard part to hit at all.

There'll be some overhaul upcoming soonish, introducing a new kind of a check (targeting/difficulty), but i'm not sure if i'll prototype half of it first or if i'd better start with the infrastructure necessary for the more advanced version - dealing with latency and past positions would rather need to be done first.

---

For now i could extend the configuration for inventory.instantbow, e.g:

• improbablecheck: true
• improbableweight: 0.6

The above would resemble the situation now (check not just feed, weight is 0.6 - 0.0 would be off). I'm not sure what values to use as default, usually i'd adapt it not to trigger too much with the default settings.

---

Altering the default settings would need some cooperation to reach some kind of overall balanced state. Perhaps such would also be better if one had some more easy ways to switch related settings to something else alltogether.

• A concept for such could be to have "model configs", which would be the configurations others have made - e.g. referenced by the default configuration.
• The model config can contain "models" _:p, e.g. sets of path names grouped under some id - so you could specify in the default config or in world configs, to apply the model id X from the model config Y.
• Additionally one could also allow specifiying sets of paths to use from another config file.
• This way the configurations (models and present ones) are not altered in significant ways, but you can try sets of different settings, the paths altered by the models are not saved back to the original for one conceptual thing. Could even have an extra file, where you specify in which world which models shall override settings.
• This would be comparably simple to do, without splitting files into a thousand pieces (also planned somehow :p). Could still be confusing when settings don't seem to be there and NCP is complaining after an update.
• Edit: Another interesting implication would be, that we can rollout specialized sets of configuration settings by default as well, e.g. strict-fighting for non-fighting server :), avoid-false-positives and others.

A little brianstorming though.

[asofold]

Build 1087 contains the configuration changes to test and adjust how improbable is used:

• feedonly -> If set to true, improbable is just updated but not checked - this could still lead to high violations, if they attack something (melee) shortly afterwards.
• weight -> The amount to feed improbable with (also on checking with feedonly set to false). You can fully disable doing anything with improbable on shooting projectiles with setting the weight to 0.0. The default settings mean no change towards before, so you'll want to either turn that part off or experiment with altering settings.

[Maxetto]

Issue seems to persist with Default Config.

[asofold]

Of course it does :), i made the default config the same as before - perhaps i've not mentioned that in an appropriate way: the only thing that changes is that you are now able to alter how "projectile shooting" relates to the imrpobable check.

The idea to check/feed improbable is to also allow cancelling projectile shooting when the player is doing too many things at once - so there are some options now, which i currenty can't test out myself:

• Set weight to 0.0 - this disables relating it to improbable in any way.
• Set weight to something lower - slows down how fast the improbable check will trigger. Can't really tell how this will work out with the 'derping sequence', perhaps there is a value for 'weight' that reaches a balance with the cooldown.
• Set the weight to something ridiculously low (e.g. 0.0000001) - this means shooting the bow won't change anything, but it can be prevented if the player is in violation of improbable anyway.
• In addition/independently, you can set feedonly to true, in order to allow shooting the bow, but other actions like hitting mobs or players might then trigger the improbable check (!).

---

All in all i'm not 100% sure what actually happens here, so i'm (somewhat blindly) considering these as possible causes:

• The yawrate check gets fed a lot due to 'derping', thus improbable will keep triggering. As a consequency any type of thing for which improbable is checked or fed might trigger, just due to yaw rate.
• Another twist could be some kind of packet inversion (shoot the bow, though a moving packet that would have changed the looking direction should have been processed before this packet). This seems to happen with interacting with blocks, and it could mean that a multiple (2, ..-.) of the actual difference of change of horizontal looking direction is assumed to have happened.

If packet order inversion is the issue, i could attempt something for leniency options, but it stays an itchy topic.

---

So the easiest thing is to turn the part off for shooting the bow, by setting the weight to 0.0

[Maxetto]

I would assume it's the second option given that it also triggers BLOCKINTERACT_DIRECTION violations, but I'll see what I/We can do with the new options.

[asofold]

BLOCKINTERACT_SOMETHING seems bugged/changed at present (way too much).

[Maxetto]

I've tried setting the weight to 0.0 but it still counts as COMBINED_IMPROBABLE: NCP: [21:39:26] combined.improbable VL 1986 (n13a153m383)

[asofold]

Just for shooting the bow? In that case likely interaction is already the problem - need to check stuff (e.g. interaction checks improbable etc. best make all spots fully configurable).

There also is a problem with packet processing order (inversion), like the interacaction is processed before a move, though shouldn't - regardless if client side or sevrer side.