Baritone often struggles when building stuff. It isnt a core competence of baritone to build but the current implementation could be improved.

• support for strucute block files #3317
• add ability to rotate schematics without the use of a schematic mod #3711
• improve pathfinding so baritone can build player position dependent blocks without to pause so often (chests, stairs, standing signs, furnaces)
• add standart value to the ignoreProperties liste for most common use case (grow state of crops, berry bushes, splings, etc) #3697
• enable baritone to build blocks that require multiple clicks to cycle there state (powered levers, delayed repeaters, open doors, note blocks, etc)
• enable baritone to build blocks that require repeated placements (snow layers, candels, turtle eggs)
• enable baritone to use flint&steal / fire charge to lit blocks (campfires, candles, fire, netherportals)
• torches have two blocks (minecraft:torch and minecraft:wall_torch)
• handeling water loged blocks
• enable right click tool usage (path block, farmland, stripped logs)

Some low level improvements. Some of them become irrelevant if we actually replace the current logic with a proper planner + executor pair.

• A way to properly temporarily ignore/place wrong blocks. Currently ignoring wrong blocks easily leads to "Unable to do it" because there are known incorrect blocks but none of them can be acted upon. This is the number one problem I face with a lot of improvements.

  • Blacklisting positions to place/break from (didn't try yet)
  • Not randomly failing due to missing materials
  • Not flooding everything
  • Properly removing liquids
  • Properly handling temporary scaffolding
  • Multi-interaction placements (didn't try yet)
  • Enforcing a certain building order

  This could be based on persistent state (e.g. setOverride(x,y,z,DIRT) and later setOverride(x,y,z,null)) but having some schematic.desiredState style method with a good caching strategy is probably better.

• (Full) scans should run from the player position outwards.

• Rely more on block updates and less on scanning.

• Un-hardcode the two ways of changing blocks (placing / breaking), essentially a requirement for half of the original list

• Proper support for multi part schematics. E.g. If I build a multi-layer iron farm litematic with one subregion per layer there is no need to scan all the air between the layers.

• Proper way of having holes in static schematics

• Schematics shouldn't be a weird combination of context sensitive and not expected to change. Planning ahead requires the schematic to not change.

  • approxPlaceable should be removed. It is a guesstimate and doesn't work at all for directional/positional blocks.
  • If a schematic accepts multiple blocks in a position, it should be able to return all of them.
  • If schematics get context then it should be more than just a single block at at time (whole build are? absolute position?)
  • Schematics shouldn't depend on changes made by building. For example replacing blocks has to cache where the old block was because at some point it will be air instead. However anticipating builder actions like that is fragile because the builder simply doesn't have to do what the schematic says. It might be wrapped in other schematics, there is plenty of settings to change what is placed (buildSubstitutes, buildIgnoreExisting and the likes) and scaffolding is unpredictable anyway.

And features more in line with the original list

• Support for some types of entities (item frames, armor stands, boats, etc.)
• Support for some types of tile entities (filling chests, furnaces, etc.)

Progress there is a bit lacking though. Is there any news on builder2 besides the latest commit?

the ability to select an area and then build that again with a offset would also be nice

like for repeating layers of a farm

the third one is technically wip under the builder2 branch

add standart value to the ignoreProperties liste for most common use case (grow state of crops, berry bushes, splings, etc) #3697

Basically we could move all the normalizations from BlockOptionalMeta to buildIgnoreProperties. (Need to make sure we don't break other things using BlockOptionalMeta though)