Some information

Operating system: Ubuntu playing Multiplayer on Constantiam Java version: 11 Minecraft version: 1.19.4 Baritone version: The one that comes with Meteor 0.5.3 for Minecraft 1.19.4 Other mods (if used): Meteor, Fabric loader, Fabric API, JourneyMap.

How to reproduce

This comes up when using schematics (litematic) to repair highways in the nether. Often there is nothing to do if the highway has not been griefed, Baritone will run a long way before finding the next defect. Where the defect is a single block in the road bed that is not obsidian, say it is cobblestone, Baritone flags that block for replacement. Every single time, Baritone will run up and stand directly onto of the block in question and then break it. The problem is, nether highways frequently do not have a solid block directly under them, so the player falls, suffering fall damage. From time to time nether highways have lava under them, sometimes only 10 blocks down, sometimes more than 100 blocks down. Baritone must be able to know the consequence of breaking the block under its feet and not do it that way.

The very first thing we learn in Minecraft is never dig straight down.

Like why not run up 2 blocks short of the block that needs to be replaced with obsidian, break it and put in obsidian without ever standing on the block? Why does it have to stand directly on the block it intends to break ?

Modified settings

To get the modified settings run #modified in game

Final checklist

[x] I know how to properly use check boxes
[X] I have included the version of Minecraft I'm running, baritone's version and forge mods (if used).
[X] I have included logs, exceptions and / or steps to reproduce the issue.
[X] I have not used any OwO's or UwU's in this issue.

The very first thing we learn in Minecraft is never dig straight down.

And even BuilderProcess has checks in place to ensure Baritone doesn't break that rule. What you describe here is supposed to be impossible.

Did you enable breakFromAbove (and goalBreakFromAbove)? Does it break the block as part of the path to get there or does BuilderProcess stop the path and break the block on its own? (if you run #proc while Baritone is breaking the block and it says something about "REQUEST_PAUSE" then it's BuilderProcess, if it's some GoalComposite whatever then it's path execution)

OK, so, no it is not tunneling to get to someplace. It highlights the block in a red box from a great distance away, only one block, to show it is a target that is not obsidian that needs to be changed to obsidian, stands on it, breaks it and falls.

After it falls, if it does not die, and is now under the highway, it does all sorts of unnecessary parkour stuff over death defying falls, lava, working on the highway from below, which just makes no sense either and makes me very scared to watch it. These antics that were never in the path highlighted on the screen before the fall tells me Baritone is surprised by the fall and re-plans its route. In highway building/repairing, all of the work can be done without ever going below highway level.

When there are 4 blocks together in the highway that need to be replaced, I have seen it plan a path over the rail and down under the highway to try to correct the blocks. Again, the problem can always be solved from above.

I have never used breakFromAbove or goalBreakFromAbove.... but I do not know what Meteor has those set to by default.

Is there a breakNeverBlockUnderFeet that I can set to true, so it just never does it ?

I see no problem breaking the block beside you from above -- breakFromAbove is too general.

Also,

I can run #proc and hope that I do not die inconveniently, and get those logs for you. If I see a block coming, I will try to #pause take screenshots, resume, pause, screenshot, etc, to catch it in its glory. I will also post the schematic I am using, but they are all pretty simple, just a section of highway, with sand blocks everywhere to make use of "#buildSkipBlocks sand" -- thank you again Zac for that addition to Baritone.

Ok, so I contrived the situation twice by running ahead, creating the situation, going back, activating the build and pausing. In both cases, there were the same results, Baritone did not actually stand on the block it was going to break, but, there are some interesting interim results.

First, I created this, a fall trap, covered by one block of netherrack.

2023-06-19_10 41 28

Then I backed off and started the build command.

buildrepeat 0,0,-1

buildSkipBlocks sand

build ConZ6Sand_negXrail.litematic ~ 119 ~

I paused it as soon as the netherrack covered fall trap came into view...

2023-06-19_10 42 09

And it clearly shows from the red line, Baritone was planning to fall into the trap, but intended to stop one square short of the edge. Here is a second closer view from the reverse angle, showing the red line goes down into the fall trap, but does so on an angle from the solid block before the trap, not on the trap.

2023-06-19_10 43 08

And it did indeed not actually fall in, in these contrived tests. I have seen it on diagonal highways, and it occurs to me, it may only happen on the first or last corner of a chunk -- diagonal highways, 2 out of 16 centerline squares are chunk corners. But I have seen Baritone fall through the highway mining out blocks under its feet that I know were not chunk corners because they were not the center diagonal. Also, I have seen it do it on straight highways too. I will test the chunk boundary hypothesis next.

I started the build from some distance away to make sure the defect was not in loaded chunks.

(useless log file deleted)

I cancelled the build at the end of the test.

If you do local tests its less scary...

Anyway #proc shows information about what Baritone is currently doing so running #pause before #proc will always show "I'm currently being paused".

Once again, breakFromAbove should not allow Baritone to stand on the block it's breaking.

That line going into the hole is probably due to your test hole having a bottom so Baritone plans to hop down there for some reason. If you try again with a more floaty piece of highway (singelplayer and a big obsidian platform work as well, no need to commit suicide) I'd expect the planned path to not end midair.

I don't know why it would walk into the hole though. With goalBreakFromAbove enabled it should try walking next to the defect, break the wrong block without moving into the hole and then place the obsidian from above.

The idea about chunk borders is interesting, but I'd expect that it's rather loaded vs. unloaded, if at all (and you seem to be experimenting with that already).

Ok, so I need to keybind a macro for #proc and hit it rapid fire. Maybe a key that repeats if you hold it down. Gotcha.

You know I am posting this because I have witnessed it happening. I am not assuming it happens when I look up from a gameboy and I am already falling and merely guessed what happened. No,I have witnessed the whole process, from working properly, to doing something nonsensical, to the whole gut churning fall, many times, since 2019 when I learned about Baritone.

Standing on a block and then breaking it is not a race condition, it does not seem to be a server thing, it seems like a bug.

I will find a way to reproduce it.

You know I am posting this because I have witnessed it happening.

I'm not doubting you on that (It sadly sounds very plausible). I'm doubting statements where you imply this happens because nobody tried to prevent it.

Specifically this line https://github.com/cabaletta/baritone/blob/6c8f2698d697c3ffaca7022f29644c6317435494/src/main/java/baritone/process/BuilderProcess.java#L273 should prevent BuilderProcess from doing it and all movements should (didn't check them just for this comment) always check they end on "solid" ground. And the #proc shenanigans are an attempt to get a hint which one of the two failed.

Ok having grown up with machine code, where one has complete control of what the processor is doing every microsecond, and many high level languages that are essentially just shorthand for machine code, the exact execution path of Java has boggled me. I have asked many people and I can only conclude not only do they not know either, they dont understand the question. My understanding of both minecraft and mods is that each operate on event handlers that initiate processes in parallel in response to events, and there are generally multiple threads at all times. I have programmed in X windows X11 so I am familiar with event handlers, and separately programmed early parallel computing systems.

I have also done a lot of xxgdb/gdb with breakpoints and watch variables, but frankly, all the best code I wrote was full of

#ifdef DEBUG  
   fprintf(fnlog,"I am here, I think I am doing this, this the the data I am about to decide future exrcution on\n");
   fflush(fnlog);
#endif

Scattered at all major decision points... just recompile with DEBUG defined and the code is half way to self debugging. Any crash/misbehaviour is then bracketted in a small amount of code, 10 more ifdefs and I have it narrowed to a clause... way easier than xxgdb and its multiple windows.

The parallel implementation of that gets hairy, new debug files each time there is a new process, but complete data is possible. But my understanding is, baritone only does one thing at a time (except when it tries to do two contradictory things at the same time and gets stuck), even if it may be considering alternatives in parallel.

It should be possible to spawn a process that just #proc's continuously until the player dies or I #cancel. Such a process could do it at higher rates and without wearing out my keyboard or fingers. All it takes is a custom fork and a new command #procs that I start with every build, pulling the trigger on the debugging process. The output would be more like spy, less like ifdef DEBUG, but like you said, it would be a start.

My log files will be huge but you would have complete data at a higher rate than I could give you manually. If my character dies, one only needs to tail the log file.

And if baritone gets stuck in a contrary loop, I have data on that too -- repeatedly sampling, eventually it will report both contrary goals.

2x a second should be fast enough without jamming my disk space.

if you want more debugging information adding something like

logDirect("blockpos to break: "+pos.toString());
logDirect("player pos: "+ctx.playerFeet().toString());
logDirect("rotation: "+rot.toString());

at line 533 would probably do the trick https://github.com/cabaletta/baritone/blob/7bb311687b1979ce8d0a59a413c0c9bc2117ffd4/src/main/java/baritone/process/BuilderProcess.java#L531-L534

^^ At this point the much better idea... Staring at the code trying to prevent the considering the block one is standing on looks solid, but approaching from the point of view of, finding every place in the code where Baritone will break a block for any reason and placing this code there (with logged information to identify which piece of code called for the break) will eventually catch the culprit. Then instead of staring at the start of the process, one can work backwards from the actual error.

Very good idea @rycbar0

#proc doesn't spit out that much information. A single sample while it's breaking the block is all I wanted.

My first attempt at reproducing this on master failed. I'll try other versions as well. If you can use rycbar's idea to pin down the exact line that would be great.

My understanding of both minecraft and mods is that each operate on event handlers that initiate processes in parallel in response to events, and there are generally multiple threads at all times

Half true. Mods usually act on events / hooks placed in game code, but those are usually processed synchronously. Technically there are a dozen threads running, but usually you will only interact with the main thread and can ignore the rest unless you use it directly (the rest being some JVM threads, netty, the integrated server, netty for the integrated server and a handful of worker threads).

If one could place a call to #proc at that point also, then it will maybe give more of an idea what Baritone thinks it is up to at this point in the code.

Eureka, I caught it breaking a block under its feet. I hit the #proc macro key as fast as I could and captured this:

[13:40:19] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:19] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:19] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:19] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:19] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:19] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=-1,y=119,z=-43736}, GoalGetToBlock{x=0,y=119,z=-43736}] [13:40:19] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:19] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:19] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:19] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:19] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:19] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=-1,y=119,z=-43736}, GoalGetToBlock{x=0,y=119,z=-43736}] [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=-1,y=119,z=-43736}, GoalGetToBlock{x=0,y=119,z=-43736}] [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH JankyComposite Primary: GoalComposite[GoalBlock{x=-1,y=120,z=-43736}] Fallback: GoalComposite[GoalGetToBlock{x=0,y=119,z=-43736}] [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH JankyComposite Primary: GoalComposite[GoalBlock{x=-1,y=120,z=-43736}] Fallback: GoalComposite[GoalGetToBlock{x=0,y=119,z=-43736}] [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=-1,y=119,z=-43736}, GoalGetToBlock{x=0,y=119,z=-43736}] [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BackfillProcess [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: 5.000000 [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: true [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: INACTIVE [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: REQUEST_PAUSE null [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:20] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=0,y=119,z=-43736}] [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH JankyComposite Primary: GoalComposite[GoalBlock{x=0,y=120,z=-43736}] Fallback: GoalComposite[] [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH JankyComposite Primary: GoalComposite[GoalBlock{x=0,y=120,z=-43736}] Fallback: GoalComposite[] [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=0,y=119,z=-43736}] [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH JankyComposite Primary: GoalComposite[GoalGetToBlock{x=0,y=119,z=-43736}] Fallback: GoalComposite[] [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Repeating build in vector class_2382{x=0, y=0, z=-1}, new origin is class_2338{x=-3, y=119, z=-43737} [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:21] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=0,y=119,z=-43737}, GoalGetToBlock{x=-1,y=119,z=-43737}] [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=0,y=119,z=-43737}, GoalGetToBlock{x=-1,y=119,z=-43737}] [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BackfillProcess [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: 5.000000 [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: true [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: INACTIVE [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: REQUEST_PAUSE null [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=-1,y=119,z=-43737}] [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BackfillProcess [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: 5.000000 [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: true [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Backfill [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: REQUEST_PAUSE null [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Repeating build in vector class_2382{x=0, y=0, z=-1}, new origin is class_2338{x=-3, y=119, z=-43738} [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=0,y=119,z=-43738}, GoalGetToBlock{x=-1,y=119,z=-43738}] [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:22] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=0,y=119,z=-43738}, GoalGetToBlock{x=-1,y=119,z=-43738}, GoalGetToBlock{x=0,y=119,z=-43737}] [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=0,y=119,z=-43738}, GoalGetToBlock{x=0,y=119,z=-43737}] [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=0,y=119,z=-43738}, GoalGetToBlock{x=0,y=119,z=-43737}] [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BackfillProcess [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: 5.000000 [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: true [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: INACTIVE [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: REQUEST_PAUSE null [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=0,y=119,z=-43737}] [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BackfillProcess [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: 5.000000 [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: true [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Backfill [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: REQUEST_PAUSE null [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=-1,y=119,z=-43737}] [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: CANCEL_AND_SET_GOAL null [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=-1,y=119,z=-43738}] [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=-1,y=119,z=-43738}] [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Repeating build in vector class_2382{x=0, y=0, z=-1}, new origin is class_2338{x=-3, y=119, z=-43739} [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Repeating build in vector class_2382{x=0, y=0, z=-1}, new origin is class_2338{x=-3, y=119, z=-43740} [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Repeating build in vector class_2382{x=0, y=0, z=-1}, new origin is class_2338{x=-3, y=119, z=-43741} [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Repeating build in vector class_2382{x=0, y=0, z=-1}, new origin is class_2338{x=-3, y=119, z=-43742} [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Repeating build in vector class_2382{x=0, y=0, z=-1}, new origin is class_2338{x=-3, y=119, z=-43743} [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Repeating build in vector class_2382{x=0, y=0, z=-1}, new origin is class_2338{x=-3, y=119, z=-43744} [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Repeating build in vector class_2382{x=0, y=0, z=-1}, new origin is class_2338{x=-3, y=119, z=-43745}

(walking away repeated lines removed)

[13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Repeating build in vector class_2382{x=0, y=0, z=-1}, new origin is class_2338{x=-3, y=119, z=-43840} [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Repeating build in vector class_2382{x=0, y=0, z=-1}, new origin is class_2338{x=-3, y=119, z=-43841} [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH JankyComposite Primary: GoalComposite[GoalGetToBlock{x=1,y=119,z=-43841}, GoalGetToBlock{x=0,y=119,z=-43841}, GoalGetToBlock{x=-2,y=119,z=-43841}, GoalGetToBlock{x=-3,y=120,z=-43841}, GoalGetToBlock{x=-1,y=119,z=-43841}, GoalGetToBlock{x=2,y=120,z=-43841}] Fallback: GoalComposite[] [13:40:24] [pool-4-thread-4/INFO]: [STDOUT]: 33456 movements considered [13:40:24] [pool-4-thread-4/INFO]: [STDOUT]: Open set size: 2715 [13:40:24] [pool-4-thread-4/INFO]: [STDOUT]: PathNode map size: 4240 [13:40:24] [pool-4-thread-4/INFO]: [STDOUT]: 117307 nodes per second [13:40:24] [pool-4-thread-4/INFO]: [STDOUT]: Path goes for 102.0 blocks [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000 [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConZ6Sand_negXrailI.litematic [13:40:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH JankyComposite Primary: GoalComposite[GoalGetToBlock{x=1,y=119,z=-43841}, GoalGetToBlock{x=0,y=119,z=-43841}, GoalGetToBlock{x=-2,y=119,z=-43841}, GoalGetToBlock{x=-3,y=120,z=-43841}, GoalGetToBlock{x=-1,y=119,z=-43841}, GoalGetToBlock{x=2,y=120,z=-43841}] Fallback: GoalComposite[] [13:40:26] [Render thread/INFO]: [System] [CHAT] [Baritone] > pause [13:40:26] [Render thread/INFO]: [System] [CHAT] [Baritone] Paused

The bolded portions may be where it happened, but, it definitely broke a block under its feet, and fell 1 block into a hole.

Ok, so that was path execution breaking the block. However there's a catch: falling into one block deep holes or anything else up to maxFallHeightNoWater (defaults to 3) and with a water bucket up to maxFallHeightBucket (defaults to 20) and with existing water up to the maximum world height is actually fine (not sure abut water on lava). You can turn down the fall heights to prevent falling for longer distances and you can disable allowDownward to prevent it from breaking the "never dig down" rule when it knows it would be safe, but you cannot prevent it from first mining the block and then stepping into the hole (which is the case with the diagonal line into the hole). You said you had it fall in lava, which definitely is not covered by the cases above so can you maybe reproduce that instead?

Tip: you can use <details><summary>Short description</summary>Very long content</details> to create spoiler tags like this one.

Short description

Very long content

or drag and drop the log file into the comment to reduce the comment length.

Thank you for the tips.

Little update: I tried again on 1.16 and (if breakFromAbove was enabled) it always broke the wrong block from above, placed an obsidian in its position and continued building the "highway". Tested on a ~100 blocks long 5 blocks wide obsidian platform with 2 chunks render distance. I placed the defect (a block of netherrack) at one end and and then started building from the other end, using buildRepeat and #selection fill obsidian.

OK, once again, I caught Baritone standing right on the block it was about to break. I saw it coming with the red line going straight down into the hole. I paused, programmed a #proc macro, resumed and hit #proc as fast as I could. It fell into another 1-deep hole that it never needed to go into.

I know, it is a 1 deep hole, it is allowed to fall into it by fall distance, but, this conflicts with the other code you showed, where it eliminates the case from consideration, continues the loop, where it is contemplating breaking the block under its feet. We know the code you showed is not responsible for this behaviour. I am ready to run a modded version of Baritone that dumps debug information. I am ready to run a modded version that catches itself falling and dumps the last 5 things it decided to do. Anything to help debug where it gets the idea to routinely break blocks under its feet.

[15:13:23] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc
[15:13:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess
[15:13:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000
[15:13:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false
[15:13:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConMP5Sand_m8_1.litematic
[15:13:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=19610,y=119,z=-19614}]
[15:13:23] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc
[15:13:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess
[15:13:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000
[15:13:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false
[15:13:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConMP5Sand_m8_1.litematic
[15:13:23] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=19610,y=119,z=-19614}]
[15:13:24] [Render thread/INFO]: [System] [CHAT] <BibleCampVictim> HERE?
[15:13:24] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc
[15:13:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess
[15:13:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000
[15:13:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false
[15:13:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConMP5Sand_m8_1.litematic
[15:13:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=19610,y=119,z=-19614}]
[15:13:24] [Render thread/WARN]: Received packet for unknown team a04: team action: REMOVE, player action: null
[15:13:24] [Render thread/INFO]: [System] [CHAT] hemuli5407 left the game.
[15:13:24] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc
[15:13:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess
[15:13:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000
[15:13:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false
[15:13:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConMP5Sand_m8_1.litematic
[15:13:24] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=19610,y=119,z=-19614}]
[15:13:25] [Render thread/INFO]: [System] [CHAT] YandexGo joined the game.
[15:13:25] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc
[15:13:25] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess
[15:13:25] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000
[15:13:25] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false
[15:13:25] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConMP5Sand_m8_1.litematic
[15:13:25] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH JankyComposite Primary: GoalComposite[GoalGetToBlock{x=19610,y=119,z=-19614}] Fallback: GoalComposite[]
[15:13:25] [Render thread/WARN]: Received packet for unknown team a58: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a57: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a56: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a55: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a54: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a53: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a52: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a51: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a50: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a49: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a48: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a47: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a46: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a45: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a44: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a43: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a42: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a41: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a40: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a39: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a38: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a37: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a36: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a35: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a34: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a33: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a32: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a31: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a30: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a29: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a28: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a27: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a26: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a25: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a24: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a23: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a22: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a21: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a20: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a19: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a18: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a17: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a16: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a15: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a14: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a13: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a12: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a10: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a09: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a08: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a06: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a05: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a03: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a02: team action: REMOVE, player action: null
[15:13:25] [Render thread/WARN]: Received packet for unknown team a01: team action: REMOVE, player action: null
[15:13:26] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc
[15:13:26] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess
[15:13:26] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000
[15:13:26] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false
[15:13:26] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConMP5Sand_m8_1.litematic
[15:13:26] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH JankyComposite Primary: GoalComposite[GoalBlock{x=19610,y=120,z=-19614}] Fallback: GoalComposite[]
[15:13:26] [Render thread/INFO]: [System] [CHAT] [Baritone] Repeating build in vector class_2382{x=-1, y=0, z=1}, new origin is class_2338{x=19609, y=119, z=-19618}
[15:13:26] [Render thread/INFO]: [System] [CHAT] [Baritone] Repeating build in vector class_2382{x=-1, y=0, z=1}, new origin is class_2338{x=19608, y=119, z=-19617}

Caught it doing illogical things again:

2023-06-29_16 49 42_2

Yep, that is a plan to break a currently good piece of obsidian, so it can jump in a hole, so it can break two blocks of oak planks.

The Proc of it:

[16:49:32] [Render thread/INFO]: [System] [CHAT] [Baritone] > buildrepeat -1,0,1
[16:49:32] [Render thread/INFO]: [System] [CHAT] [Baritone] Successfully set buildRepeat to -1,0,1
[16:49:32] [Render thread/INFO]: [System] [CHAT] [Baritone] Old value: -1,0,1
[16:49:32] [Render thread/INFO]: [System] [CHAT] [Baritone] > buildSkipBlocks sand
[16:49:32] [Render thread/INFO]: [System] [CHAT] [Baritone] Successfully set buildSkipBlocks to sand
[16:49:32] [Render thread/INFO]: [System] [CHAT] [Baritone] Old value: sand
[16:49:32] [Render thread/INFO]: [System] [CHAT] [Baritone] > build ConMP5Sand_m8_1.litematic ~-8 119 ~
[16:49:32] [Render thread/INFO]: [System] [CHAT] [Baritone] Successfully loaded schematic for building
[16:49:32] [Render thread/INFO]: [System] [CHAT] [Baritone] Origin: BetterBlockPos{x=18922,y=119,z=-18931}
[16:49:32] [Render thread/INFO]: [System] [CHAT] [Baritone] Repeating build in vector class_2382{x=-1, y=0, z=1}, new origin is class_2338{x=18921, y=119, z=-18930}
...
[16:49:32] [Render thread/INFO]: [System] [CHAT] [Baritone] Repeating build in vector class_2382{x=-1, y=0, z=1}, new origin is class_2338{x=18886, y=119, z=-18895}
[16:49:32] [Render thread/INFO]: [System] [CHAT] [Baritone] Repeating build in vector class_2382{x=-1, y=0, z=1}, new origin is class_2338{x=18885, y=119, z=-18894}
[16:49:35] [Render thread/INFO]: [System] [CHAT] Saved screenshot as 2023-06-29_16.49.35.png
[16:49:36] [Render thread/INFO]: [System] [CHAT] Saved screenshot as 2023-06-29_16.49.36.png
[16:49:37] [Render thread/INFO]: [System] [CHAT] Saved screenshot as 2023-06-29_16.49.37.png
[16:49:38] [Render thread/INFO]: [System] [CHAT] Saved screenshot as 2023-06-29_16.49.38.png
[16:49:39] [Render thread/INFO]: [System] [CHAT] Saved screenshot as 2023-06-29_16.49.39.png
[16:49:40] [Render thread/INFO]: [System] [CHAT] Saved screenshot as 2023-06-29_16.49.40.png
[16:49:41] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc
[16:49:41] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess
[16:49:41] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000
[16:49:41] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false
[16:49:41] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConMP5Sand_m8_1.litematic
[16:49:41] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=18885,y=119,z=-18886}, GoalGetToBlock{x=18886,y=119,z=-18886}]
[16:49:41] [Render thread/INFO]: [System] [CHAT] Saved screenshot as 2023-06-29_16.49.41.png
[16:49:42] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc
[16:49:42] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess
[16:49:42] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000
[16:49:42] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false
[16:49:42] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConMP5Sand_m8_1.litematic
[16:49:42] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=18885,y=119,z=-18886}, GoalGetToBlock{x=18886,y=119,z=-18886}]
[16:49:42] [Render thread/INFO]: [System] [CHAT] Saved screenshot as 2023-06-29_16.49.42.png
[16:49:42] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc
[16:49:42] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess
[16:49:42] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000
[16:49:42] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false
[16:49:42] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConMP5Sand_m8_1.litematic
[16:49:42] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=18885,y=119,z=-18886}, GoalGetToBlock{x=18886,y=119,z=-18886}]
[16:49:43] [Render thread/INFO]: [System] [CHAT] Saved screenshot as 2023-06-29_16.49.42_2.png
[16:49:43] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc
[16:49:43] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess
[16:49:43] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000
[16:49:43] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false
[16:49:43] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConMP5Sand_m8_1.litematic
[16:49:43] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=18885,y=119,z=-18886}, GoalGetToBlock{x=18886,y=119,z=-18886}]
[16:49:43] [Render thread/INFO]: [System] [CHAT] Saved screenshot as 2023-06-29_16.49.43.png
[16:49:43] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc
[16:49:43] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess
[16:49:43] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000
[16:49:43] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false
[16:49:43] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConMP5Sand_m8_1.litematic
[16:49:43] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=18885,y=119,z=-18886}, GoalGetToBlock{x=18886,y=119,z=-18886}]
[16:49:43] [Render thread/INFO]: [System] [CHAT] Saved screenshot as 2023-06-29_16.49.43_2.png
[16:49:44] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc
[16:49:44] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess
[16:49:44] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000
[16:49:44] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false
[16:49:44] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConMP5Sand_m8_1.litematic
[16:49:44] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=18885,y=119,z=-18886}, GoalGetToBlock{x=18886,y=119,z=-18886}]
[16:49:44] [Render thread/INFO]: [System] [CHAT] Saved screenshot as 2023-06-29_16.49.44.png
[16:49:44] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc
[16:49:44] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess
[16:49:44] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000
[16:49:44] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false
[16:49:44] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConMP5Sand_m8_1.litematic
[16:49:44] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=18885,y=119,z=-18886}, GoalGetToBlock{x=18886,y=119,z=-18886}]
[16:49:45] [Render thread/INFO]: [System] [CHAT] Saved screenshot as 2023-06-29_16.49.44_2.png
[16:49:45] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc
[16:49:45] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess
[16:49:45] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000
[16:49:45] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false
[16:49:45] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConMP5Sand_m8_1.litematic
[16:49:45] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=18885,y=119,z=-18886}, GoalGetToBlock{x=18886,y=119,z=-18886}]
[16:49:45] [Render thread/INFO]: [System] [CHAT] Saved screenshot as 2023-06-29_16.49.45.png
[16:49:45] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc
[16:49:45] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess
[16:49:45] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000
[16:49:45] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false
[16:49:45] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConMP5Sand_m8_1.litematic
[16:49:45] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=18885,y=119,z=-18886}, GoalGetToBlock{x=18886,y=119,z=-18886}]
[16:49:45] [Render thread/INFO]: [System] [CHAT] Saved screenshot as 2023-06-29_16.49.45_2.png
[16:49:45] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc
[16:49:45] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess
[16:49:45] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000
[16:49:45] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false
[16:49:45] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConMP5Sand_m8_1.litematic
[16:49:45] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=18885,y=119,z=-18886}, GoalGetToBlock{x=18886,y=119,z=-18886}]
[16:49:46] [Render thread/INFO]: [System] [CHAT] Saved screenshot as 2023-06-29_16.49.46.png
[16:49:46] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc
[16:49:46] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess
[16:49:46] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000
[16:49:46] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false
[16:49:46] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConMP5Sand_m8_1.litematic
[16:49:46] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=18885,y=119,z=-18886}, GoalGetToBlock{x=18886,y=119,z=-18886}]
[16:49:46] [Render thread/INFO]: [System] [CHAT] Saved screenshot as 2023-06-29_16.49.46_2.png
[16:49:46] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc
[16:49:46] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess
[16:49:46] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000
[16:49:46] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false
[16:49:46] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConMP5Sand_m8_1.litematic
[16:49:46] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=18885,y=119,z=-18886}, GoalGetToBlock{x=18886,y=119,z=-18886}]
[16:49:47] [Render thread/INFO]: [System] [CHAT] Saved screenshot as 2023-06-29_16.49.47.png
[16:49:47] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc
[16:49:47] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess
[16:49:47] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000
[16:49:47] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false
[16:49:47] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConMP5Sand_m8_1.litematic
[16:49:47] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: FORCE_REVALIDATE_GOAL_AND_PATH GoalComposite[GoalGetToBlock{x=18885,y=119,z=-18886}, GoalGetToBlock{x=18886,y=119,z=-18886}]
[16:49:47] [Render thread/INFO]: [System] [CHAT] Saved screenshot as 2023-06-29_16.49.47_2.png
[16:49:47] [Render thread/INFO]: [System] [CHAT] [Baritone] > proc
[16:49:47] [Render thread/INFO]: [System] [CHAT] [Baritone] Class: baritone.process.BuilderProcess
[16:49:47] [Render thread/INFO]: [System] [CHAT] [Baritone] Priority: -1.000000
[16:49:47] [Render thread/INFO]: [System] [CHAT] [Baritone] Temporary: false
[16:49:47] [Render thread/INFO]: [System] [CHAT] [Baritone] Display name: Building ConMP5Sand_m8_1.litematic
[16:49:47] [Render thread/INFO]: [System] [CHAT] [Baritone] Last command: CANCEL_AND_SET_GOAL null

And here it is, in the hole it just made, that it did not need to make....

2023-06-29_16 49 47_2

BTW, The default value of #breakfromabove is false when I checked.

A variational analysis: Baritone was planning to break the block under its feet.

2023-06-29_17 42 34

So I go, OK, lets dig a pit under that block...

2023-06-29_17 44 24

Cancel walk back a distance and start the build all over again.... now it plans something complex involving going under the highway and pillaring up from below.

2023-06-29_17 45 19

Like how is that the solution to an A* algorithm ? How is that the easiest way to do this ? Digging out 3 blocks and placing 2, just to dig out the target block, and replace it with obsidian from below... It is a head scratcher.

Did you enable breakFromAbove (and goalBreakFromAbove)? They are disabled by default because they can cause Baritone to get stuck but you really need them here. Without those settings enabled BuilderProcess can't break the block in the hole from above (i.e. the highway surface) so it has to do crazy things.

You probably noticed that in order to get next to the defect it can't break from above it breaks the obsidian from above, so here's an overdue overview:

There's two main components in play here

PathingBehavior is responsible for walking around. It's told where to walk by processes (e.g. BuilderProcess) and the green boxes show you where that is (usually, sometimes they don't show up for reasons). It uses A to find a path to get to it's goal (that's the flashing blue lines and the red line once it's done). Path execution is handled by PathExecutor (which does some weird things you don't want to think about) and primarily the individual `Movement`s and can place blocks to stand on and break blocks in the way (red and green boxes).
BuilderProcess is the thing which handles all the building (it's pretty monolithic). It doesn't render anything to screen so if you see some boxes or lines then that's path execution doing something because BuilderProcess asked PathingBehavior to walk somewhere.

The way BuilderProcess decides what to do is pretty dumb and involves no planning at all (pretty much the opposite of builder-2, once that's functional). Here's what happens in a tick:

Search for reachable blocks to break. It scans ±5 blocks in the x and z direction and 5 blocks up and depending on breakFromAbove it scans one block down or starts at foot level.
Search for placeable blocks to place. Scans ±5 blocks in all directions, not really of interest here.
Do some black magic to come up with a goal to hand to PathingBehavior and to hopefully make it walk somewhere useful. To place a block it tests some conditions to decide whether it wants to walk to some side of the block or right above it to force path execution into placing the block (there's a special so path execution places the schematic block instead of a throwaway block, other processes can't use this trick). To break a block it also tests some magic conditions to decide whether it wants to force path execution into breaking the block (a.k.a. walking into the block) or wants to walk next to it (on the same level) or if goalBreakFromAbove is enabled next to the block up to one block higher than the block itself.

I've left out a bunch of details (like why it doesn't always wall in itself) but it should be enough to understand most of the behavior you have observed and why there are inconsistencies like when BuilderProcess can't break a block from above so it tells PathingBehavior to walk next to it, which results in path execution breaking a block from above. Or why it can dig straight down despite that line I linked to (that line is part of step 1. of a BuilderProcess tick).

If breakFromAbove doesn't help then sadly I don't know how to fix it. Planning how to build something is really hard (let's hope leijurv can get builder-2 to work anyway) and I have no idea how short-term lookahead for BuilderProcess would work. Actually, builder-2 can't break blocks so even if Baritone will at some point be able to build anything without moving parts, that still won't help you fixing a highway. Because breaking blocks complicates things by a lot.

Long story short: Looks normal, I don't know how to fix it, hopefully you now understand what's happening.

If you can't fix it with those settings I can maybe try fixing it just for your case by breaking general purpose schematic building even more. Basically I'd make it always walk onto a neighbor of the block it wants to break / place and hope there's no cases where that doesn't work.

I did enable breakFromAbove in the later half of my work yesterday. I have plenty of screenshots that I have yet to share of nonsensical things. There was one case where Baritone got caught in a loop breaking and placing the same block, the problem is it eventually just broke the block while it was standing on it, above an 8 block drop, and I landed right beside lava. Baritone scared the crap out of me a couple more times that the smallest server glitch or the smallest nudge from a zombie pigman might have meant death, that I just stopped using it and taking screenshots for the rest of the session.

I did not enable goalBreakFromAbove because in my mind, something that is not a goal is not an anti-goal, it is not prohibited. When breaking from above is the simplest solution, A* should find this as the simplest solution, or so I assumed. Again, all sorts of tunneling under the highway behaviour was noted, so, does goalBreakFromAbove false make it an anti-goal... seems so.

So I have now integrated {"#breakFromAbove true"} and {"#goalBreakFromAbove true"} into my initiation keymacro for building to assure, for all future experiments these variables are set.

Thank you very much for the detailed explanation as to how Baritone divides and solves the problems. I will keep this in mind for experiments when I again get to an area where I am unlikely to be dropped hundreds of blocks into lava and withers. That will be soon.

Ok so to be clear, this is my keymacro for starting to build on Meteor client...

{"#breakFromAbove true"} {"#goalBreakFromAbove true"} {"#buildrepeat 1,0,0"} {"#buildSkipBlocks sand"} {"#build ConX6Sand_negZrailI.litematic ~ 119 ~ "}

All of these commands are executed in sequence following the press of one key.

I have watched Baritone run this now for most of an hour. It has not done a single thing that seems risky, unwise, or unnecessary. I will let you know if I see something.

I did not enable goalBreakFromAbove because in my mind, something that is not a goal is not an anti-goal, it is not prohibited.

Of course ending a path outside the goal is not ok. Imagine your navigation app of choice sending you to the next restaurant because you didn't explicitly tell it that ending at the restaurant instead of your home is not ok.

When breaking from above is the simplest solution, A* should find this as the simplest solution, or so I assumed. Again, all sorts of tunneling under the highway behaviour was noted, so, does goalBreakFromAbove false make it an anti-goal... seems so.

I'm not sure what you expect of A here, it is really just a path finding algorithm and knows nothing about your schematic. Baritones A implementation will generate a path to wherever BuilderProcess told it to path to and if that's inside a hole in an unsupported obsidian road then the only way to get there is pillaring into it from below (try it, you won't find a better way). Doesn't make sense for the schematic, but that's nothing the path finder can know. The nonsensical part is wanting to stand in the hole in the first place, which is up to BuilderProcess to decide (actually up to you because you are the one toggling goalBreakFromAbove on or off). Once again, compare this to a navigation app. If you want to buy bread but input the address of a power plant, would you expect the navigation app to lead you to a bakery nonetheless because that is the simplest solution to buying bread?

A* works in N dimensions. I have used it in 6 and over 50 dimensions. It is possible to do anything with it. I have a great many ideas that I have typed out at various points in this thread, and then cut and pasted them all to a file I have saved. If I had a way to send a message to you privately Zac, I would share those thoughts. I am positive they would run into the realities of how Baritone is programmed now. The reality of how Baritone is programmed will determine what is easy, what is hard, and if anything is worth doing.

I was uncertain about what false meant for goalBreakFromAbove. I had imagined that it was like a navigation app where you can specify waypoints or which direction to enter the parking lot upon arrival. I took the goal to be to break the block. To me goalBreakFromAbove being false said I do not care about the details, the colour of the car or which way it enters the parking lot when it gets there, dont rule anything out, or constrain it to pass through any waypoints (like I had imagined "FromAbove" to be, like a waypoint, not a goal), just get me there. I never imagined that false meant do not break it from above. I made an assumption, and I was wrong.

You have made it clear, I should be using goalBreakFromAbove, so I am now. There has been a night and day difference in the way Baritone behaves. I am not sure how a new user would know how much of a difference this makes. I would be curious why there are two variables, breakFromAbove and goalBreakFromAbove if either one being false negates the effect of the other and how a new user would learn that.

I will test the recommended configuration extensively in safer areas, and if I cannot make it screw up in any particularly blatant way then I will acid test it on spawn. I will set a bed, store all my valuable gear, eat an egap and send Baritone paving through 0,0, to see what it does. I do not expect flawless, just that it would do credibly-comparable to me working manually. I have screwed up and fallen in lava all by myself before, but, never by breaking the block under my feet.

A little more testing and I will be adding these settings to my standard Baritone training program to help educate people I introduce to Baritone.

A* works in N dimensions. I have used it in 6 and over 50 dimensions. It is possible to do anything with it

I failed at 3 position + 3 velocity dimensions and never tried a holonomic problem in more than 3 dimensions so I might be biased towards assuming something to be infeasible (theoretically you can do anything with brute force as well), though I still doubt searching the 1000003D state space of a 100x100x100 schematic build would complete in reasonable time.

If I had a way to send a message to you privately Zac, I would share those thoughts

You can reach me on libera.chat (ZacSharp) and matrix (zacsharp:matrix.org), but I'm not the only person working on Baritone and I also don't think I'm the best to attempt major changes either (quite the opposite) so maybe you want to share them here instead.

specify waypoints or which direction to enter the parking lot upon arrival

Oh, yeah. You overestimated it's capabilities by a fair bit. goalBreakFromAbove means "position the goal so you can break from above once there" not "restrict the path to enter the goal from above". Baritones A* is really just a 3D pathfinder, no extra dimensions for directions or sequence positions or velocity or block states or whatever. A state is a position in the Minecraft world and a goal is a collection of positions (implemented as a predicate). The only slight twist is tweaking movement costs to encourage or discourage certain actions (e.g. pillaring up where the schematic wants blocks placed is "almost instant" but doing so where the schematic wants air "takes ages") (yes you read that right, the pathfinder doesn't know it will change the world at execution time)

breakFromAbove and goalBreakFromAbove if either one being false negates the effect of the other

They are actually completely independent. breakFromAbove makes BuilderProcess break up to one block down if it can reach a wrong block there, goalBreakFromAbove makes it place the pathfinder goal to get into such a position. Obviously, turning goalBreakFromAbove on without breakFromAbove will easily get it stuck because it walks into a position from where it can't do anything. I guess they are separate because breakFromAbove alone might also make sense (not sure when that would be though).

Good idea and should be relatively straightforward to implement.

It is me.

Ok, so I have been watching Baritone with breakFromAbove and goalBreakFromAbove set. It no longer ever breaks the block under its feet in the middle of the highway.

It has unintentionally fallen several times, near lava because at the edges of the highway, it has this desire to pillar up when it is putting one block on top of the other, where, it never needed to stand on either block. I think Baritone gets a few milliseconds ahead of the server, Baritone thinks it has placed a block there, then the server goes, what block, and Baritone falls.

This goes into a concept of risk I have been thinking about. Baritone is choosing a risky maneuver, in the presence of real world realities.

Is there a way to turn pillaring off, so it never tries to follow up a scaffold with a pillar, so, it never tries to place a block below its feet ? I am going to go read the documentation, see if I can find something.

I have also observed Baritone place a block in the wrong spot. I think the rotation was set completely wrong and it was trying to place a block somewhere else. This happens about as often as an unintentional fall.

I tried #jumpPenalty, because pillaring requires jumping.

Default setting of #jumpPenalty is 2.0

I changed it to 20, no change in behaviour, it would not place a block on top of another block without walking onto the lower block and jumping.

I changed the penalty to 1000, Baritone just froze up, it could not find a solution.

I changed the penalty back to 100. The behaviour was precisely the same as 2.0 and 20.

It seems for these blocks, Baritone knows only one way, and that is pillaring.

So I have discovered, when Baritone sneek-places a block and then jumps to put another block on top of it, that is not considered jumping. With jumpPenalty still set to 100, it did its thing at the edge of a highway, sneak placing, jump, block disappeared, it fell, and then because of thhe high jump penalty, it could not find a way back up.

Captured mid-confusion, candidate paths jumping like lightning everywhere.

2023-07-06_10 02 06

Looking up at what we Baritone fell off of. The block Baritone was trying to place was diamond-to-the-right of the cobblestone block seen in the photo -- the block that is not there directly above the player. I let Baritone try this section because there was no lava under it.

2023-07-06_10 02 10

So, it is not exactly fitting the title, Baritone is not intentionally breaking the block under its feet, it is trusting a block it just placed, when it does not need to, and it is falling almost certainly because of a momentary miscommunication between client and server -- an unavoidable eventuality that Baritone should accomodate for.

The solution is to change when Baritone sees it is going to place two blocks one on top of the other, right now it seems it thinks of them as a unit, with only one way to place the second block. It needs to divide the task into two so that it considers jumping to place the second block as a move with more penalty -- it will back off and place the block standing on top of an adjacent block. If there is a momentary miscommunication with the server, Baritone is not jumping, so it will not fall if the first block fails to be accepted by the server.

As fast as I could screenshot, this is a sequence of the plan that does not fail on this occasion, but, causes Baritone to fall sometimes when it persistently tries this again and again.

The plan... we need to put a block in that hole, and then place obsidian on top of it. Clearly from this point of view one can stand right were the camera is currently and place both blocks. Baritone is planning something risky when something simpler can be done without moving at all.

2023-07-06_10 16 33

Here are the two blocks that are going to be placed....

2023-07-06_10 16 33_2

And the red line seems to say this is how it is going to be done. Clearly the lower block can be placed by shooting the visible face of the obsidian right thereto the left of the lower block... but no, Baritone is going up ... I have watched Baritone do things like this so many times, doing it the hard risky way instead of the easy way.

First block placed, it seems from the side, not from scaffolding, sneak-hanging over the side and putting it under its feet.

2023-07-06_10 16 33_5

And we jump to place the second one, this time it seems from mostly over the historic block, not entirely on the freshly placed block. It does not do the most risky thing every time.

2023-07-06_10 16 34_6

Clearly, one could not have fallen in the last example if this was always the case.

To be clear, all the times it is falling now, it is doing this same maneuver, at the rail, placing the lower block and them it jumps up off the lower block to place the upper block. I hope this helps narrow this behaviour down in the code.

There is no human-noticeable lag in the server right now. But Baritone is a little faster.

TPS is 19.7 now, I do not know what it was when it fell, but it was certainly above 18, could easily have been 19.5. Many multiplayer servers operate for long periods of time with a TPS of 12-15.

If that is a question, would it be possible to explain it better ?

TPS sync would slow down Baritone to the speed of the server so if the server is running at 5 tps Baritone would do so as well instead of acting at "lightning speed" (from the server POV).

Lambda has a NoGhostBlocks module which looks like it might help (not sure how Baritone would react to blocks not appearing), but the meteor version of that module only handles block breaking.

Contrary to your observations placing a block and then pillaring up does count as a jump, but Baritone probably doesn't find a different way of placing those blocks. The first one cannot be placed without sneak placing and while the second one would be placeable after walking to the side Baritone doesn't do so because BuilderProcess always tries walking onto blocks it wants to place. If it can place them earlier it does so, if not it just waits until path execution placed the block. In your case it the shortest path from on the first block to on the second block is pillaring up so it does that. It has to jump at least once regardless of the path it takes so jumpPenalty doesn't change anything.

What do you think should make a movement more costly due to being risky? (Checking few additional blocks would be nice for performance.) One simple one would be adding a penalty to placing against air (i.e. throwaway blocks, remember they don't exist during planning), but you also wanted to penalize walking near edges and before I start implementing some checks which turn out to not get the job done I thought I'd ask you for a clearer definition of "walking near an edge" (or any other kind of risky movement).

most 1.19 servers should not need tps sync as paper has lag comp for mining blocks.

What about placing blocks?

The first one cannot be placed without sneak placing and while the second one would be placeable after walking to the side Baritone doesn't do so because BuilderProcess always tries walking onto blocks it wants to place. If it can place them earlier it does so, if not it just waits until path execution placed the block. In your case it the shortest path from on the first block to on the second block is pillaring up so it does that.

Sorry, am I the only one who stands still and places a block over air by placing the block against the side of the hole by clicking on the left rear block backing up this hole visible it this photo ?

Then once the lower block is in place, still without moving, target the top face of the just-placed block and place the upper block ?

Zero movement from the position of this picture. Zero jumps. Zero times relying on standing on a just-placed block over air.

https://user-images.githubusercontent.com/69666047/251479631-28439f58-1a0f-4c2a-9f28-e7021920a1ed.png

What do you think should make a movement more costly due to being risky?

Relying on standing on a just-placed block over air would be one thing I would penalize/add a high A cost. Standing still on historical obsidian, that can only be destroyed by a wither, that would have zero penalty, no addition to the A cost.

I observed behaviour like this on 1.12.2 -- when one fell it was often at the rail. I do not recall if I was using noghostblocks.

For the current report it is 1.19 and Meteor.

When one is in Wither territory, one has to be prepared to pause/cancel baritone and deal with it or run away. It would be nice if Baritone ran away for you but that is a lot to ask. Withers are only placed by people, they are not part of the naturally occuring terrain in Minecraft.

Everywhere is Ghast and Creeper territory, they are automatically generated by the game. They are not the same hazard as Withers but they do routinely blast big holes in netherrack and other not-blast resistant blocks. On 1.12.2 I was able to set autolog for creepers... I do not see that for Meteor. So when I said standing on historical obsidian would have no penalty, standing on historical netherrack should have at least a small penalty, because of Ghasts and other soft blocks in the overworld because of creepers.

Sorry, am I the only one who stands still and places a block over air by placing the block against the side of the hole by clicking on the left rear block backing up this hole visible it this photo ?

Uhm, right. When it enters the position you took the screenshot from it should notice it can place the lower block and pause the path to do so. Once that's done it's hopefully not already partially inside the upper block so it can place that as well. (and when I tested this it worked like that. No bridging or pillaring happened.)

Concerning the risk factors I was mainly interested in factors applicable to the current pathfinder so "don't stand on blocks you just placed" simply means "don't place blocks" and there is no concept of standing still (and for a pathfinder which places blocks for reasons other than walking onto them I'm not sure whether it's a good idea. Tracking which block/bloks was/were just placed means at least 3 more dimensions and makes movements depend on how it got to do them, which is not nice. Static checks like "don't stand on unsupported netherrack" are better from an implementation perspective) Two weaker versions which are doable with Baritones 3D A* would be adding a penalty to bridging over air (it rarely bridges over solid ground so I don't see much use for this. Just increase the placing penalty) and adding a penalty to walking on unsupported blocks in general (though checking the whole crater radius of a creeper explosion might be a bit expensive. It would be opt-in so I guess a 10x slowdown would be acceptable?).

Have you tried adding netherrack to blocksToAvoid? I'm not quite sure what it does anymore but maybe it makes Baritone avoid walking on netherrack.

Ok, as a testable, repeatable problem, I made the following schematic. I am building it in the overworld, over water with the following Meteor macro, just so I do not have to keep retyping all of this:

Deploy Echests for breaking:

{"#buildSkipBlocks sand"} {"#buildIgnoreDirection true"} {"#buildIgnoreProperties true"} {"#buildrepeat 0,0,1"} {"#breakFromAbove true"} {"#goalBreakFromAbove true"} {"#build deploy2.litematic x y z"}

macro mapped to key ==> h

Copy and paste works for macros to avoid retyping.

x, y and z were fixed numbers so it keeps placing echests on the same bridge again and again so they can be harvested again and again -- an obsidian farm. After the first run of deploy, one generally does not fall because one is not building new bridge, just placing echests. If one lets it go to build more bridge, then one will fall.

The schematic is:

deploy2.litematic.zip

The file is not zipped, just remove the .zip extension it is a normal schematic file. GitHub will not allow one to attach a file that is not a photo or zipped. It is a small schematic.

It builds a bridge out over water and puts echests on the bridge for breaking with a second schematic later. One must have obsidian, echests, and torches in the hotbar. In practice, I have put a netherrack bar below the centerline of the bridge so the character falls 6 or 7 blocks, damagingly but not fatally onto netherrack to eliminate the possibility that Baritone planned to fall into water.

On Constantiam 1.19.4 it rarely makes it 5 advances before falling in the water, sometimes only 2.

The repeatable fall-failure when building this schematic might assist in determining what is happening.

Does it require server lag to fall? I've successfully turned an inventory full of materials into a bridge without falling in singleplayer.

I am not surprised the result is different in single player, where only one computer is involved. There was no detectable server lag that I observed at the time of the test.

This was tested on a multiplayer server, Constantiam, running between a TPS of 17 and 19, which for multiplayer servers is pretty good conditions, and for Constantiam is good conditions. There was no human-visible server lag present at the time of the test.

There are a lot of differences between single player and multiplayer, and there is inevitably some chance of a change in timing of communications in the best of conditions -- no communication over the internet can be guaranteed to be free of glitches in all links of a route, over an extended period of time. There does not specifically have to be server lag for there to be differences between single player and multiplayer.

If in the end this entire issue report is chalked up to server lag without any examination of the parts of Baritone that might be less robust, more vulnerable, to any difference between single player and multiplayer, or more robust to the normal and expected conditions in multiplayer, then it is as good as saying it is not a desirable outcome that Baritone work better in multiplayer. Baritone becomes far less interesting if it is not at least a desirable outcome for Baritone to work better in multiplayer, if not a goal or requirement.

There does not specifically have to be server lag for there to be differences between single player and multiplayer.

That slight difference between a real network and in-memory communication is what I meant with "server lag" and I ask because testing in singleplayer is considerably easier than setting up a test server, especially if localhost or even the home LAN is still too fast to get the desired effects. Also so far I only want to know why it is failing and do not plan on fixing it. Movement execution isn't quite fun to work on and unless it's an easy fix I'll probably not spend my spare time on it. Baritone not working as well in multiplayer as it does in singleplayer wouldn't be desirable, but wanting something and finding someone to do it are two different things.

cabaletta / baritone

Baritone runs to a position, and digs the block from under its feet, falling, sometimes into lava, and dying. #3995