cabaletta / baritone

google maps for block game

Baritone

A Minecraft pathfinder bot.

Baritone is the pathfinding system used in Impact since 4.4. Here's a (very old!) video I made showing off what it can do.

Baritone Discord Server

Quick download links:

Forge	Fabric
1.12.2 Forge
1.16.5 Forge	1.16.5 Fabric
1.17.1 Forge	1.17.1 Fabric
1.18.2 Forge	1.18.2 Fabric
1.19.2 Forge	1.19.2 Fabric
1.19.3 Forge	1.19.3 Fabric
1.19.4 Forge	1.19.4 Fabric
1.20.1 Forge	1.20.1 Fabric
1.20.3 Forge	1.20.3 Fabric
1.20.4 Forge	1.20.4 Fabric

Message for 2b2t players looking for 1.19/1.20 Baritone If you like, please try the beta for Baritone Elytra for 2b2t, find it in #announcements of the Baritone discord. It supports 1.19.4 and 1.20.1, Forge or Fabric. If you have to see it to believe it, watch this YouTube video.

How to immediately get started: Type #goto 1000 500 in chat to go to x=1000 z=500. Type #mine diamond_ore to mine diamond ore. Type #stop to stop. For more, read the usage page and/or watch this tutorial playlist. Also try #elytra for Elytra flying in the Nether using fireworks.

For other versions of Minecraft or more complicated situations or for development, see Installation & setup. Also consider just installing Impact, which comes with Baritone and is easier to install than wrangling with version JSONs and zips. For 1.16.5, click here and see description. Once Baritone is installed, look here for instructions on how to use it. There's a showcase video made by @Adovin#6313 on Baritone which I recommend.

This project is an updated version of MineBot, the original version of the bot for Minecraft 1.8.9, rebuilt for 1.12.2 onwards. Baritone focuses on reliability and particularly performance (it's over 30x faster than MineBot at calculating paths).

Have committed at least once a day from Aug 1, 2018, to Aug 1, 2019.

1Leijurv3DWTrGAfmmiTphjhXLvQiHg7K2

Getting Started

Here are some links to help to get started:

• Features

• Installation & setup

• API Javadocs

• Settings

• Usage (chat control)

Stars over time

API

The API is heavily documented, you can find the Javadocs for the latest release here. Please note that usage of anything located outside of the baritone.api package is not supported by the API release jar.

Below is an example of basic usage for changing some settings, and then pathing to an X/Z goal.

BaritoneAPI.getSettings().allowSprint.value = true;
BaritoneAPI.getSettings().primaryTimeoutMS.value = 2000L;

BaritoneAPI.getProvider().getPrimaryBaritone().getCustomGoalProcess().setGoalAndPath(new GoalXZ(10000, 20000));

FAQ

Can I use Baritone as a library in my custom utility client?

That's what it's for, sure! (As long as usage complies with the LGPL 3.0 License)

How is it so fast?

Magic. (Hours of leijurv enduring excruciating pain)

Additional Special Thanks To:

YourKit supports open source projects with innovative and intelligent tools for monitoring and profiling Java and .NET applications.

YourKit is the creator of the YourKit Java Profiler, YourKit .NET Profiler, and YourKit YouMonitor.

We thank them for granting Baritone an OSS license so that we can make our software the best it can be.

Why is it called Baritone?

It's named for FitMC's deep sultry voice.

baritone's Issues

Path through stronghold iron doors by pressing the button

Probably not really necessary, but cool!

Avoid triggering pressure plates?

Possibly? Maybe we could analyze what blocks it would power. For example, a pressure plate that just opens a door is fine, but one that goes to a line of redstone should probably be avoided.

Revisit canWalkOn / canWalkThrough checks

For example, decide whether end rods and flower pots should really be canWalkThrough since they do collide (even in a small way).

Should we make shulker boxes canWalkOn even though they expand when opened?

In general, should canWalkOn's bounding box check be changed to only do the Y coordinate? Or maybe something smarter...

Should anvils be canWalkOn?

Should grass_path and farmland be canWalkOn?

Should glass be canWalkOn?

Magma should probably be a separate check due to the sneaking cost, it's good that it's not canWalkOn

Fences / walls

It should be able to walk on top of them, but recognize it can't do so in a 2 high space, and recognize it can't jump onto them from the ground. This might be more trouble than it's worth.

Fix falling on "replaceable" blocks

When falling, the bot will take a high jump and fail to cushion its fall with water if the bottom block is something like a shrub.

This is most likely because the block is considered "passable" when calculating the cost for the path, however, the raytrace fails to hit the actual desired block and instead says it can't be seen.

Replace usages of player().setSprinting(true) with the sprint keybind

Would this affect behavior at all?

can't water bucket fall if a passable and replacable block like bushes is above the goal

it raytraces and thinks it's looking at bushes so it doesn't place the water

Render GoalComposite like how it renders GoalBlock and GoalXZ

Perhaps it should be a little more complicated than just rendering every subcomponent of the goal... or maybe that should just be it

Automated testing framework

This might tie in with #20

I'm thinking both small scale (almost like unit tests) and large scale.

Small scale would be like "in this scenario of blocks, this movement should be COST_INF". However, that would be really time-consuming to create for not much benefit. I think larger scale integration-style tests give way more bang for you buck (the amount of functionality it tests vs how time consuming it is to write).

Perhaps something like "can the bot path from 0,0 to 1000,1000 in a world generated from seed _____ within X minutes without taking damage?"

Difficulty handling vines

Soul Sand walk cost

I just put it as the same as water but that was a guesstimate. How fast do you actually walk on soul sand?

Falling water bucket placement

Follow-up issue (to #15): if it's bucket falling onto ground, and there's a torch on that ground, it'll never actually place the bucket because torches have a real hitbox (unlike bushes) and it would place above.

I think the check should be converted from any kind of raytrace to a simple right click hold starting when the ground it's intending to hit should be within range.

Adjust goal heuristic based on whether or not sprinting is possible

Walking is 4.63 ticks per block, and sprinting is 3.56.

If sprinting is allowed, any heuristic greater than 3.56 is an overestimate.
The default is 3.5 right now.

However, if you can't sprint, this is such an underestimate that pathing becomes practically very difficult and almost Dijkstra-like.

It should be 3.5 when sprinting is possible, and 4.6 otherwise.

Automatically break block while suffocating

Trapdoors

Worth implementing?

Unit Tests

Files which are easily testable and require unit tests:

• LookBehaviorUtils

Magic Value Optimization

Ideally, some of the values that you are unsure of we can optimize. We can do this assuming we have a good test path and speed up the tick speed of Minecraft. I think the easiest way is just to have a random search with early stopping. The hardest part of this is just overfitting to the test path.

I would be interested in implementing this, but I need a list of all tunable values.

Chat control to clear goal

Currently there's no way to clear the goal (set it to null).

Smarter pathing with status effects

For example, while under fire resistance, path through lava. Maybe even detect fire resistance potions on hotbar and use them.

Bot tries to open iron doors by right clicking

Should add a check to make sure the door is wood.

Splice current and next path tighter

Right now there's a tick of inaction between when one path ends and the next begins. You can see this where it stops sprinting for a second in the recordings. We should do something akin to how PathExecutor jumps to the next Movement in the same tick that the previous one finishes, maybe recursively in the same way.

Framerate issues

Even a short path cuts my framerate in half, can't really explain why. Well not quite in half, but significant drop. Like 60 to 45.

Save and quit to title doesn't clear input overrides

It should

Bedrock breaking cost isn't infinite

it's not COST_INF but it should be

Stairs

they dont work

Store inventory contents

An addition to the chunk caching system: whenever an inventory is opened, store its coordinates, type, and contents in the caching system.

This is just a feature I need for myself, basically /pathToAndOpenClosestChestContaining minecraft:leather

Setting the goal to a specific Y level causes the player's hand to turn white and gray

Save and quit issue

Long distance path ending in ocean causes drowning

This isn't an issue with Baritone pathing per se... but if you set a 10k block path, leave your computer, and come back, you might be surprised to discover that it brought you to your destination, but your destination was in an ocean, and the moment the path ended it stopped floating and you drowned.

Perhaps if a path ends in water it should continue floating until some keyboard input is detected?

CalculationContext should include if the player has enough hunger to sprint

Perhaps it should even look at what food items are currently in their inventory, for how many blocks of sprinting is reasonable?

Store locations of special blocks

There are two applications of this:

1. While doing long distance pathing, some blocks are better than others. Right now, anything that is canWalkOn is stored as SOLID, however that doesn't capture things like magma, soul sand, etc. Storing the locations of those alongside might be beneficial. This is somewhat mitigated by path trimming to loaded chunks (it will already avoid the first part of the soul sand / magma patch, and when it plans the next segment it'll avoid the next) but it isn't great because it can get trapped in corners and stuff. (see #18)

2. Valuable blocks. For example, /pathToAndRightClickNearest minecraft:ender_chest. Obvious reasons. We should store the locations of:

• Ender Chests
• Chests
• End portals
• Nether portals (the blocks, not the obsidian frame)
• Shulker Boxes
• Furnaces
• Hoppers
• Blocks of {Iron, Gold, Diamond, Emerald}
• Beacons
• Brewing Stands
• Mob Spawners (with type)
• Item frames (with item)
• Skulls (player, mob, wither)

Only mob spawners spawn commonly from this list, but they're interesting enough that I think it's no big deal to keep them. Uncommon natural spawns include brewing stands in igloos and end ships, loot chests in nether fortresses, strongholds, villages, etc, End portals in strongholds, furnaces in villages and igloos.

Slabs

they dont work

Standardize on Blocks.FOO.equals(block) vs block instanceof BlockFoo vs block.equals(Blocks.FOO)

MovementDiagonal over Magma

Right now its COST_INF, it should instead be sqrt(2)*SNEAK_ONE_BLOCK_COST and during execution it should know to sneak over magma to avoid damage.

"cancel" control while pathing should result in the path never being executed

Right now if you tell it to cancel while it's calculating a path, it will be completely ignored.

MovementAscend into double sand bug

Basically, it breaks the lower sand, which causes the stack to fall. In this time, they're falling entities, so the blocks are actually AIR. It thinks "oh i'm done breaking time to jump up" and does. It gets slightly into the falling space, but in then pushed back. However, while it's glitched into the falling sand stack, it calls the movement over and goes onto the next one.

Smarter ETA for full path

Currently the API can give you the ticks remaining in the current path segment fairly accurately, by summing up the freshly recalculated costs of the remaining movements.

This could be easily extended to the planned next path.

However, for longer distance paths this doesn't work, as the segments aren't calculated yet. How can we give an ETA of the entire thing, from start to goal, even if it isn't calculated yet?

I'm considering something like: goalHeuristic(currentPos) * ticksElapsedSoFar / (goalHeuristic(startPos) - goalHeuristic(currentPos))

Improve path safety

Right now, every Movement just expects that the player is standing in src. However when things get screwed up that isn't the case. And there are some really crappy heuristics that it uses. For example traverse jumps when its Y level is below what it expects it to be even though that's NOT its job. Instead of canceling the path if it's been more than 2 blocks away for more than 5 seconds, it should immediately cancel it when the player is off the path. This also helps if the real player is trying to take over (like if there's a mob) and doesn't want to type cancel, they can divert away from the path.

MovementAscend jump cost needs tuning

I just guessed you'd jump after 0.5 blocks of walking but that isn't accurate. What should the cost really be for movementascend?

Doors

They don't work

Fence gates

It should be able to right click and open them just like doors

Generate and cache bitmap image of surface

For future features, a map should be generated not unlike Dynmap in 2D mode that is cached, to allow for cool visualizations and the likes.

Fix block hardness calculation so it doesn't require currentItem

Currently, block hardness calculation (in ToolSet.java) does this:

        // Set the best slot
        player().inventory.currentItem = slot;

        // Calculate the relative hardness of the block to the player
        float hardness = state.getPlayerRelativeBlockHardness(player(), world(), pos);

        // Restore the old slot
        player().inventory.currentItem = oldSlot;

This is bad because your hotbar flickers all around while pathing, and there's a race condition where if you really set your hotbar currentItem while pathing in the other thread in between these instructions it could get a wildly inaccurate result.

Automatically disable auto-jump while pathing is active

We jump ourselves, and it messes up MovementDiagonal edging around blocks (it jumps on top because it thinks we want to, for example if we were edging around magma this would cause us to take damage and lose the path, and continue to take damage while recalculating)

Better benchmarking of internal processes

For example, during a path it might be interesting to see which movement types consistently underestimated vs overestimated how many ticks they would take.

Also, I think a warning of when the onTick handler took more than X milliseconds would be helpful, same for renderFrame (but in nanoseconds).

More aggressive path splicing

Right now, if playerFeet intersects with any position of next, it jumps immediately onto that path. This is fine and good if, for example, next begins with a bit of a backtrack of current, you'll never end up executing those redundant parts at all and can skip to what happens next on next.

However, it doesn't always backtrack the same way. A few times I've seen it make a big loop where it goes ~10 blocks diagonal into a corner, then next moves one block to the side and goes all the way back. It never intersects with next but it's really really close and should totally just jump on it.

A duct tape patch solution would be to calculate all movement costs from playerFeet and if any of them intersect with next, take it... but that only applies to a gap of 1 block.

A more interesting solution would be to have more than one start node in the A* pathfinding. Normally, you start off by setting one node (your start node) to be 0 cost and adding it to your open set, then starting the graph search loop from there. I wonder if it would be possible to set the blockpos of every node in current to be 0 cost while calculating next. That way it would get the current full path, but be able to jump off it anywhere it wants instead of just at the very end. And with the goal heuristic combined cost in the openset selection process, it would (most of the time) end up just popping off the end node first (because it has the lowest goal heuristic, because current and next were calculated with the same goal), and running from there. So it wouldn't have any negative impact on normal splicing with no backtracking, but would allow more efficient backtracking.

So the TODO is figure out if this would have any negative impacts or gotchas that I'm not thinking of, and to try it out.

moveTowardsBlock should consider moving backwards as well as forwards

Right now it just looks at the destination and holds W, it should instead consider looking away and holding S if close enough. Basically, something like MovementManager.moveTowardsCoords from MineBot: https://github.com/leijurv/MineBot/blob/master/mcp918/src/minecraft/minebot/movement/MovementManager.java#L136

Sprint through ascend and descend, if possible

Related to #29

Write javadocs for every entry in Settings

Obscure ladder bug

Pathing from the top of this pillar to the top of that pillar will fail in execution every time. (I'm sneaking off the edge to show that both pillars have ladders facing each other. You would actually start the path standing on the center of the pillar, not sneaking off the edge)