Check Line of Sight of Player Before Block Placements and Opening Containers

[Axionize]

This prevents players from using Freecam and interacting with blocks through walls. For example, accessing a chest behind a wall they shouldn't have access to.

Can be used to check all block interactions, but currently only checks containers for maximum performance. The list of blocks being interacted with to check will be configurable to all or a list.

This also prevents laggy players from being able to break a block in regions protected by plugins such as Worldguard and quickly opening a container behind it before the block reappears client side.

Currently making a PR To ask for feedback on:

• What changes, if any, need to be made for latency compensation.
• If suggested configuration options are appropriate
• What the result of using the Player.BLOCK_INETRACTION_RANGE attribute will have for players on < 1.20.5
• Note that the existing code has comments and print statements to make it more clear what's going on that may not be in the final PR.

EDIT: This could have the potential to close #1498

[ManInMyVan]

this should be done in rotationplace, but I added a review anyways (I gave up halfway through so some things don't have comments)

[Anthony01M]

This needs a lot of rework and seems like is still in draft, please change the status from Open to Draft

[Axionize]

I wrote this as a quick port of a hacky spigot-api based check I had in a custom plugin for a very specific problem on a specific server, which I wanted to move to a proper anticheat.

I'm not that familiar with GrimAC's codebase, but I noticed that Sam was working on something similar: #1238

I cleaned it up a little here: https://github.com/Axionize/Grim. I'm going take to modifying Sam's check to also work for Blocks/Entities/Digging in the reach-wall-check branch and continue providing dev builds with the reach check's and latest GrimAC updates in the 2.0 branch in my fork.

I plan to make a separate draft for this new approach when I'm ready to get some feedback.

I greatly appreciate your time and help, and I'd still like for the code to be reviewed. If there's anything I can do to make that easier, please let me know.

[SamB440]

The problem with my draft is that it falses due to the movement threshold, you could be anywhere within 0.03 and thus the raytrace is wrong

[Axionize]

Wasn't that bug fixed past 1.18.2?

I've taken a look at how you account for this movement and I don't see anything obviously wrong with it? Are there any reproducible circumstances under which you can cause it to fail I can investigate?

In any case, I don't see anything wrong with disabling the 0.03 offsets if the player's version is > 1.18.2. It would be better than nothing and most modern (non 1.7/1.8) servers only keep support for the last couple of major MC versions anyways.

Please let me know if I'm overlooking something or you have a better alternative in mind.

[ManInMyVan]

Wasn't that bug fixed past 1.18.2?

no it's still a thing, it's just 0.0002 and not 0.03, it's just called "0.03" because it's the same mechanic

[Axionize]

Hey @AoElite and @SamB440 , this check I've been working on for blockface + line of site raytracing is done. Problem is its a bit on the slow side. I got a lot of things I'm doing to optimize it, one of which is making everything use primitives.

Nevertheless, I'm hesitant to force you all to become functional programmers. For now I've just basically duplicated a lot of the functions I need to use primitives instead. Doing this alone gives me a measurable (over 35% in the worst case) performance increase for my check.

Are you okay if I gut out significant parts of the math, vector, and reach libraries here to use primitives? Would you prefer to keep object-based versions as a wrapper around the primitive functions (since if you're using objects you probably don't care about performance)? Finally, should that be a separate PR or included in the check? I'd prefer it to just be part of the check PR since it makes my life a lot easier but I can understand if you would like it to be otherwise.

[Axionize]

@SamB440 @AoElite can I get a review and merge? Check is done and @ManInMyVan has confirmed we're good on falses. We have 1 engine related issue (like trapdoor + door when clicking over 20 cps and changing state) but a similar problem exists in simulation with the same causes and can't be fixed by us without an engine overhaul.

[ManInMyVan]

@ManInMyVan has confirmed we're good on falses.

I'm not done