Allow customizable block placing and destroying range

[Camotoy]

(I want to preface this by saying that I am no anticheat expert, nor have I extensively worked with Minecraft internals. I am quite familiar with packets at the Java code level.)

Is your feature request related to a problem? Please describe.

I'm one of the developers at Geyser (a Bedrock-client-to-Java-server proxy). While a lot of things translate over nicely from Bedrock to Java (and vice versa) without server interference, one of the difficulties between the platforms is the block range differences. Whereas Java range is capped at 6/7 blocks (depending on gamemode), mobile Bedrock players can go as far as 12 blocks in creative mode.

Describe the solution you'd like

I propose adding new methods to the API to allow for changing a specific player's block reach. I've loosely tested this functionality (by replacing the hardcoded numbers), and I am proposing a feature request before a PR to make sure this is something fit for Paper (I would PR this myself). There are two individual but related checks: block placing and block destroying.

The general structure I propose involves two new methods added with getters/setters: get/setCreativeBlockReach and get/setSurvivalBlockReach that ultimately control player reach. (Alternatively: two getters and one setter?: setBlockReach(int survivalReach, int creativeReach)). This should probably have a bounds check of the vanilla survival/creative reach numbers; otherwise, with lower numbers, ghost blocks will occur on vanilla clients.

For block placing (in PlayerConnection, under the listener for "PacketPlayInUseItem"), there are two checks put in place: a vanilla reach check that simply ensures a block is within a distance squared of 8 * 8, and a check added by CraftBukkit that measures eye location and a more strict reach check of either 7 (creative) or 6 (survival). SURVIVAL_PLACE_DISTANCE_SQUARED and CREATIVE_PLACE_DISTANCE_SQUARED (two static constants that control this check) can be replaced with the player's reach getters. The vanilla distance check - currently hardcoded to 64D - can probably be something like player.getMaxReachDistance (the greater range number between the two reaches) + 1.

For block destroying (in PlayerInteractManager#a(BlockPosition, PacketPlayInBlockDig.EnumPlayerDigType, EnumDirection, int), there is a hardcoded reach check of 36D (6 * 6). This can be set to the previously described player.getMaxReachDistance minus 1 (Since we aren't placing a block but interacting with an existing block).

Describe alternatives you've considered

Alternatively, with direct server access, Geyser doesn't need to send the block place packet, and can just manually place the block on the server and call the player interact event ourselves. This has a couple of downsides:

• From what I can tell, it requires NMS, making it not immediately forwards-compatible and more difficult to implement for future versions while maintaining backwards compatibility.
• Knowing plugins, attempting to replace the entire block placing/breaking system will likely break something obscure. While such a feature request described here would certainly break certain anticheats, having a getter for block reach would enable other plugins to verify block placement.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Camotoy]

No.

[Owen1212055]

I feel something like this is too specific for the paper api, and seeing as how the PR sat idle for a while I am guessing that this was something others thought too.

Especially since that this would just be a server side thing, would this just be better to just use something like the in future paper plugin mixins instead (if that even happens)?

[Camotoy]

Mixins would be more ideal if that happens, I agree. The demand for a feature like this is low - I suspect, for us, it truly only affects people who want to use creative mode.

[lynxplay]

Closing this, given how all-over the place these values are inlined in the server source I doubt the diff is doable nicely. Sorry we couldn't make this happen. If a large interest in this comes up in the future, I'll happily re-open this :)