Restore epsilon in block collision checks or add a config toggle to fix AI pathfinding regressions

[TKostofan]

Is your feature request related to a problem?

Yes. Starting from build #116 (commit 1f1406f), there is a significant regression in how automated entities (bots/AI) interact with terrain. By removing the epsilon value for whole-block collision checks, the server now enforces "pixel-perfect" collisions.

When an AI entity (like a Mineflayer bot) moves flush against a block to jump, the server rejects the upward movement because the hitbox is perfectly aligned with the block's edge. This causes bots to get stuck and "vibrate" in place instead of jumping. This was perfectly working in builds #112-#115.

Describe the solution you'd like.

I would like to see the "epsilon padding" restored for collision checks with solid blocks, or at least a configuration option in paper-world-defaults.yml (e.g., collisions.use-legacy-epsilon) to restore the previous behavior. This would allow AI entities to maintain enough "gap" from blocks to perform vertical movements (jumping/climbing) without being blocked by the new strict collision logic.

Describe alternatives you've considered.

1. Reverting to build 1.8.8 bug (invalidconfigurationexception) #115 (Current workaround).
2. Attempting to "hardcode" movement offsets in the bot's framework (e.g., forcing the bot to move back before every jump), which is inefficient and breaks natural movement fluidness.
3. Modifying max-entity-collisions in Paper config, which does not resolve the core mathematical collision issue introduced in build Banner waving workaround #116.

Other

The commit message for 1f1406f explicitly stated: "I'm sure this is going to cause some collision problem but we will cross that bridge when it happens." As a developer of an AI framework for Minecraft, I can confirm that this "bridge" has been reached. Strict vanilla collisions are great for players but break many existing AI pathfinding implementations that rely on the tiny epsilon gap to navigate slopes and stairs.

[SeasonPhan]

for the love of god makes this a configurable entry
it took me 2 days of searching around wondering why the bot didnt jump properly

[TKostofan]

I feel your pain. After spending a lot of time digging into this, it's clear that the "bridge" the developers mentioned in the commit has indeed collapsed for all of us.

Since it seems we're left to "cross this bridge" on our own without any one-click fix or config toggle from the server side, I've found a workaround. For those of you using mineflayer, you can simulate the missing epsilon by slightly adjusting the client-side physics.

Just add this to your bot's spawn/init logic:

if (bot.physics) {
  bot.physics.playerHalfWidth = 0.302; // Restores the tiny gap needed to jump
}

It's a "client-side band-aid" for a "server-side wound," but it works. Until (or if) the devs decide to prioritize our experience over "pixel-perfect" collisions, this is the way.

[TKostofan]

Just a heads-up for everyone implementing this workaround:

If the Paper devs eventually decide to revert these changes and restore the epsilon, this client-side fix might cause slight "over-padding" (making the bot feel slightly wider than normal), which could potentially interfere with very tight navigation.

To keep your code maintainable, I suggest making this a configurable toggle in your bot's settings rather than a hardcoded value:

const usePaperCollisionFix = true; // Set to false if the server is updated/fixed

if (bot.physics) {
  bot.physics.playerHalfWidth = usePaperCollisionFix ? 0.302 : 0.3;
}

This way, you can quickly switch back to vanilla physics without hunting through your code if the server-side "improvement" is ever undone.

[Owen1212055]

How does this compare to vanilla? Generally this prolly won't be fixed because we prefer vanilla behavior.