search

Updated-NoCheatPlus / NoCheatPlus

Anti-cheating plugin for Minecraft (1.5-1.20, Bukkit/Spigot)
https://ci.codemc.io/job/Updated-NoCheatPlus/job/Updated-NoCheatPlus/
GNU General Public License v3.0
482 stars 100 forks source link

NCP_PassableBug #21

Closed MrEDok closed 2 years ago

MrEDok commented 4 years ago

Full output of /ncp version

20:38:48 INFO: ---- Version information ---- 20:38:48 INFO: #### Server #### 20:38:48 INFO: git-Purpur-580 ~MC: 1.15.2~ 20:38:48 INFO: detected: 1.15.2 20:38:48 INFO: #### NoCheatPlus #### 20:38:48 INFO: Plugin: 3.17-SNAPSHOT-b1153-CustomFork 20:38:48 INFO: MCAccess: 1.13.2-1.15|? / Bukkit-API

20:38:48 INFO: blocks: BlocksMC1_4 | BlocksMC1_5 | BlocksMC1_6_1 | BlocksMC1_7_2 | BlocksMC1_8 | BlocksMC1_9 | BlocksMC1_10 | BlocksMC1_11 | BlocksMC1_12 | BlocksMC1_13 | BlocksMC1_14 | BlocksMC1_15 | MCAccessBukkitModern 20:38:48 INFO: checks: FastConsume | Gutenberg | HotFixFallingBlockPortalEnter | AttackFrequency | FlyingFrequency | KeepAliveFrequency 20:38:48 INFO: defaults: pvpKnockBackVelocity 20:38:48 INFO: packet-listeners: UseEntityAdapter | MovingFlying | OutgoingPosition | KeepAliveAdapter | SoundDistance | WrongTurnAdapter | NoSlow | Fight 20:38:48 INFO: Hooks: AllViolations~NCP~ 1.0 | ServerStatistics 1.0 | ViolationFrequency~NCP~1.0 20:38:48 INFO: #### Related Plugins #### 20:38:48 INFO: ProtocolLib v4.5.1-SNAPSHOT-b451

Describe the issue

Mining or walking against a block cause passable trigger

How to reproduce the issue

mine or walk against a block

Extra links/Videos (Including debug logs)

ncp debug log: https://pastebin.com/FzUmf1J1 video: https://streamable.com/8dto2z

Any possible config options changed or plugins that may cause interference?

default config

MarkElf commented 4 years ago

Fixed already. Edit: Fixed in my fork, I posted updated values in #development.

ElementW commented 4 years ago

Can confirm this happens on 432b4b0a0a175992ed3402f0cc4e33a957d89c1b.

Further testing shows that on both the X and Z axes at high-ish coordinates, walking against a wall triggers a passable false positive under the following circumstances:

Walking direction Wall @ -32767 -32768 32768 32769
Positive OK Bug OK Bug
Negative OK OK OK OK

Considering the behavioral pattern it seems the path tracing/checking (possibly in (Passable)AxisTracing) handles positives and negatives in an inconsistent fashion.

Looking at commit diffs reveals the Passable threshold precision was increased in a0cb3869a9932daba349ae89fc97631e9fbf161a, making the check fail due to floating point numbers having decreasing precision with increasing values. Reducing rt_xzFactor to 0.99999998 seems to make it work again up to the vanilla world border.