Describe your suggestion

The bot should be able to enter prone in front of 1x1 spaces or tunnel in prone mode by placing a water bucket, entering swim mode, and picking the water bucket back up after entering the next target block. The bot could use this in place of regular tunneling in any case where it can place a water bucket to save on durability and reach destinations faster.

Settings

allowWaterBucketProneTraversal - Allow the bot to enter prone mode if it has a water bucket and can place water for traversing locations that are targeted for tunneling.

Context

Being able to allow the bot to fit in a 1x1 space instead of a 1x2 space would conserve tool durability and increase the speed at which the bot can travel.

Final checklist

• I know how to properly use check boxes
• I have not used any OwO's or UwU's in this issue.

1.13+ swimming has already been suggested
Using it for smaller tunnels (not suggested before) adds another state (1x1) to the nodes (in addition to x, y, z). I'm not sure if that would work and if it does it would double the amount of possible nodes in a specific area and thus slow down Baritone by quite a bit I think (though not to 50% speed)

The latter would be rejected, and yes, the former is a duplicate suggestion.

1.13+ swimming has already been suggested
Using it for smaller tunnels (not suggested before) adds another state (1x1) to the nodes (in addition to x, y, z). I'm not sure if that would work and if it does it would double the amount of possible nodes in a specific area and thus slow down Baritone by quite a bit I think (though not to 50% speed)

The latter would be rejected, and yes, the former is a duplicate suggestion.

You wouldn't need to do any adjustment to the state, since, this would only apply to cases where tunneling is done. The bot can simply ignore the second layer block if in prone mode without making any pathfinding adjustments.

Additionally, this isn't a request for 1.13 swimming itself, this is a request on handling of prone mode by the bot. The swimming part is not relevant to the suggestion because the same effect can be created with, for example, a trapdoor, it'd just be significantly harder to implement that way.

It would be slower to crawl and dig a 1x1 than to walk and dig a 2x1

It would save durability, however. If you are using cheap pickaxes it is effectively slower due to mining speed and requiring more pickaxes every so often. It's a tradeoff but I also expect that it would improve speed.

1. An additional state property would be needed to keep track of when to ignore the second layer
2. Imo Trapdoors would be easier because they don't flow

It would be slower to crawl and dig a 1x1 than to walk and dig a 2x1

and that makes it obsolete anyway

Baritone doesn't care about durability.

Baritone doesn't care about durability.

That's not really relevant to the intent of my suggestion, which is primarily just to give an option to improve efficiency. Like I said, its a tradeoff and I would expect it to improve overall speed in cases where efficiency is more important.

Also, trapdoors don't flow but you have to 1. Take into account item pickup, 2. Handle the placement of the trapdoor (you can't place a trapdoor on a block you are standing in) 3. Handle opening/shutting the trapdoor.

With a water bucket, the bot just needs to enter prone mode and go towards the next block in its path which it already handles, the bot can traverse through flowing water just fine.

I don't know how Baritone's pathing system works internally, but, if I had to guess, its probably not necessary to change any of the pathing code other than a condition for when to mine certain blocks, there's no need to change the pathfinding code.

When the bot is picking the next block to mine, it can see if the block below whatever block is targeted is marked to be mined, and, if so, use that block instead so long as the player is in prone mode. If there is interference with the bot needing to have the space above it free to continue, that would get more complicated, but, I still think its feasible to implement.

I might just try and do it myself and create a pull request, in that case if I end up being completely wrong about my assumptions, at least you told me so 🤷🏼‍♂️

Anyways, this isn't a duplicate at least.

I might just try and do it myself and create a pull request

do that. I'd be surprised if you manage to do anything more than execution-time crawling (not considering it during pathing) without an extra state and a significant slowdown and if you can prove that the water method is easier.

Also, trapdoors don't flow but you have to 1. Take into account item pickup, 2. Handle the placement of the trapdoor (you can't place a trapdoor on a block you are standing in) 3. Handle opening/shutting the trapdoor.

With a water bucket, the bot just needs to enter prone mode and go towards the next block in its path which it already handles, the bot can traverse through flowing water just fine.

lol don't compress the thing you want to be easier into less detailed steps than the thing you want to be more difficult

Also, water is easier to place and pickup but you have to 1. Take into the current pushing you away, 2. Handle falling sand and stuff that could fall on your head 3. Handle starting to swim in 1 or less deep water.

With a trapdoor, the bot just needs to enter prone mode and go towards the next block in its path which it already handles, it can then simply mine the trapdoor.