World Eater example
This page presents the details of the example project 7_WorldEaterExample. If you'd like to run it yourself, a world download with everything setup is available along the project files.
The idea is pretty simple: dig an area using bots. The execution, however, is much harder than what it looks. There are a lot of edge cases you need to take into account if you want a fully autonomous program (to name a few: make sure you don't trap yourself in a hole, don't mine the block you stand on, don't let lava spill on you, don't die due to floating sand structure collapsing...). This program should be able to deal with all these issues from the top of the world to the bottom, assuming you provide enough tools and food.
The program can be started with various arguments, you can use 7_WorldEaterExample --help to display them and their default values. Here is a detailed list of what they do:
-
--address: the address of the server to connect to, make sure it's set on online-mode: false (unless you have enough accounts and in this case you'll need to change the connection call to use them instead of the predefined bot names) -
--numbotthe number of bots to run in parallel. Make sure the server can handle that many players. Each bot will be assigned to a dedicated lane of the work area. A good value is$widthOfTheArea / 8$ . Having 8-wide lanes allows the bots to reach al the block from the center of the lane without moving, reducing the amount of time spent walking around. Having more bots will probably not increase the speed too much on "soft" layers (i.e. that you can instamine), but could help on layers with blocks that are longer to mine (e.g. deepslate). -
--numworldnumber of worlds shared by the bots. If numworld == numbot, it means that each bot has its own world representation. A lower value means some bots will share their world. As they are all in the same loaded area, it's not a problem to share the world, and it allows to save a lot of RAM. Having too few will however slow the bots down, as they can't access/modify it as the same time. For a vanilla generated world with a render distance of 10, a world takes around 450 Mb of RAM. This will go down during the program as more and more chunks are replaced with air. -
--startand--endrequire three integers each. These are the coordinates of the corners of the area you want to mine (similar to Minecraft fill command). The whole area must fit in the render distance (this is a constraint for the planning algorithm). For bigger areas, you might want to split them in smaller chunks and run the program multiple times. -
--tempblockis the name of the block used to fill water/lava and bridge over the void. You can use any solid full block you want except sand and gravel. I recommend using a block that is both easy to get in large quantities and quick to mine. I use basalt in the example, but dirt or cobblestone are also good options -
--sparedis a comma separated list of blocks you don't want the bot to mine. By default, spawners (and torch) will be left untouched by the bots. Be careful, this can prevent the program from running smoothly. See spared blocks and pathfinding dedicated section below. -
--collectedcomma separated list of items you want the bots to keep. If your provided tools don't have silk touch, make sure to put the name of the items and not the block name here. Be aware that the bots won't collect them actively: they will keep the ones they get walking nearby, but won't specifically go to them to collect them. If you want to be sure to collect all the diamonds, it might be safer to do it by hand while the bots are working. -
--stopwordif someone says this word in the chat, all bots will stop working and go to their respective assigned end position (lime concrete). Once all are arrived, the program will shutdown. You can restart it later with the same parameters and it will start back where it left.
Before you start the program, you need to check a few things with the server. The first thing to do is to make sure you are allowed to use bots on the server. Ask an admin first if that's not your server or you might be banned by some anti-cheats system. Then, you need to make sure the max-players property is high enough for all the bots to connect. You might also want to make sure the server is powerful enough to handle the task. The main issue being all the items entities created by mined blocks. In the case of the example, I used lithium because vanilla performance is, well, vanilla and staaaaaaaaaaaack to group more items together and reduce the server load. Without the entity merge radius changed, the server had to deal with peaks of ~3000-4000 entities, while only ~1000 at most with staaaaaaaaaaaack. On a smaller area or with fewer bots a vanilla server should be fine. Make sure to monitor the TPS to see if it can handle it and if not, maybe reduce the number of bots.
Having beacon effects (speed, haste) over the working area is a big plus as it speeds the mining operations, but not mandatory. If the bots are under beacons effects, they will automatically adapt their digging/walking speed based on the effect level. If you build beacons, don't forget to build them low enough, as their range extend only 50 blocks below them but indefinitely above them.
As the bots have all the tools available, it should be able to mine any block without problem. However, there are a few blocks that can cause some trouble when running the program. The first kind of blocks are non full solid blocks. As botcraft pathfinding system is block-based, they can cause some wrong path being detected as walkable while they are not. Fortunately, they have a very low occurence in generated worlds. Examples of such blocks are beds, fences or carpets. Another type of rare blocks you want to deal with is interactable blocks (such as furnaces, brewing stands, crafting table...). These blocks will cause issues if the bot tries to "right click" next to them to place a block (as they will interact with the block instead). This is rather infrequent too in regular worlds. In both cases, you can either try to break the blocks before starting the program, or just wait for a bot to be stuck because of them and go break the block then. You should see some warnings in the console when this happens.
Bots are not programmed to fight. I assume that if you want to dig a perimeter, you also probably have a mob switch. I recommend turning it on during the operation. Regarding spawners, the first bot to load the area will tell you the location of all the spawners near the perimeter, so you can spawnproof them. Usually, putting a torch above them is enough. Make sure you add the torch to the spared blocks when launching the program (or alternatively, you can just break the spawner if you don't want to keep it). If you don't want to "cheat" knowing the position of the spawners in advance, you can just let the bots dig and go spawnproof the spawner once you see a death message in the chat.
Before starting the program, you need to make sure there is a basecampe with enough resources for the bots to work with. You also need to place some colored concrete blocks to indicate some interest points. Here is the detailed list:
Concrete:
- a red concrete block: inventory drop position. All the nearly broken tools and --collected items will be thrown here. You might want to add some water and a sorting system for conveniance
- lime concrete blocks: these will be the resting position of the bots once the work is finished. You don't need to have one per bot, but make sure you have less bots than the entity craming threshold per block or else...
Shulker box:
- cyan: with pickaxes. They don't need to be netherite or diamond, neither fully enchanted. Just any pickaxes and the bot will work with what's available. You can even have a mix of diamond and netherite pickaxes
- black: temp blocks. These must contain the blocks you passed with --tempblock when starting the program. The bots will try to always have at least 5 stacks when taking items, so if you have more than 5 bots make sure there are more than one shulker box
- brown: ladders
- yellow: golden carrots
- light_blue: axe, same thing as pickaxe
- blue: shovel, same thing as pickaxe
- purple: hoe, same thing as pickaxe
- magenta: shears, same thing as pickaxe
- orange: lava bucket
For all the colors, the bots will be splitted evenly to different shulker boxes so you can have more than one of each color and each bot will go only in the one it is assigned to.
For all tools, they will be returned to the red concrete block when they are low on durability. So if you want, you can retrieve them here fix them using mending and put them back in the system. Or just have a bunch of them.
The bots assume that they will all spawn on one side of the area to mine (NOT inside it), with all available tools and the area entirely loaded in the render distance. They will also need a clear path from the area with all the tools and the working area. They don't need to be able to get to the top/bottom of the area though, only one block between them at the center of their lane. That's where the pillar with ladders will be built to allow the bot to go up and down while the area is mined.
The program has been tested and should work properly and autonomously. There are however a few points you want to check and monitor when running it.
It can happen that one bot will die for various reason (lava bucket misuse, mobs...). This does not affect the program and it will continue to run with no issue. However, the respawn position must fulfill the same criteria as when you start the program (working area fully in render distance, access to tool picking shulker boxes, access to the working area).
While the progam is running, you will see some log messages in the console. Most of them will be some warnings about some failed actions (block placing, breaking, lava bucket use etc...). You don't need to worry too much about these warnings. The program is built so the bot has some fallback actions to handle unexpected situations. If the same action fails three times in a row, the bot will go back to start base to empty it's inventory, pick new tools/blocks and then go back to work. If you see the same message logged more than three times in a row, and other similar failures from the same bot, that could however mean that something is not right and you should take a look. This will probably happen with failed pathfinding if you add amethyst geodes to spared blocks as they are complex to navigate through.
Items listed under --collected are not actively collected. The bot will only keep the one it collects by walking nearby. It you want to collect all the diamonds in the area, make sure to do it manually while the bots are working. You won't impact their work by being there or stealing some blocks.
When a bot has to place a block (for example to create a bridge or to remove some fluid), it can happen that an entity is in the way (yes I'm looking at you villagers). In this case, the block placement will fail. Typically, the bot will stop working and take a break at basecamp dropping items and picking up new tools. The entity should have moved by the time it comes back to continue. In the rare event of a non movable entity (like a minecart) you will have to manually break it.
The algorithm to plan the order of block removal on a layer is based on the assumption that the previous layer above is empty. This is the case when you mine all the blocks, but not when some are spared. For spawner, this is usually not a problem, as they are often quite distant from each other, and therefore you have some space to pathfind around it. If you want to spare the budding amethyst however this is another story. They are often close to each other and can create some pathfinding issues. In this case, I recommend close monitoring of the bots when around geodes and manually add/remove some blocks to help them pathfind the area. You can remove the blocks once they are two layers below the geode.