Some information

Operating system: windows 10 64bit
Java version: Version 8 Update 241 (build 1.8.0_241-b07)
Minecraft version: 1.15.2
Baritone version: 1.5.2
Forge mods (if used): Impact is installed (not via forge)

How to reproduce

• Attempt to build a very long custom tunnel #tunnel 3 3 1000 with space to run around the tunnel (such as into a mountian with a way to go around)
• baritone will run around the tunnel

video

bbug.zip

Modified settings

my guess as to whats happening

judging by impact saying that it's "building clear area" im guessing that custom tunnels use the same code as the selection stuff, and this makes baritone try to path in weird ways to clear the rest of the selection
im not sure if custom tunnels without a depth paramater do this because they dont work #1451

Final checklist

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

randomly coming back after a while
like i said in the issue, i think the large tunnel uses completely different code than the custom tunnel code which is a problem
tunnel 1x2 does it sequentially while the larger tunnels just use the selection code so baritone goes Bonkers

You are right about custom tunnels using other code than the 1x2 ones.
1x2 tunnels are actually an unreachable goal for the pathfinder (GoalStrictDirection iirc). The magic happens in the heuristic which decreases (more and more negative) in the direction of the tunnel but rapidly increases as soon as the considered position deviates from the tunnel. The result is that Baritone walks in the desired direction ("towards the goal") and accepts really suboptimal paths to not have to deviate from the tunnel. Usually you need "infinte" cost movements like walking through lava or bedrock to make it take a detour.
Custom tunnels on the other hand are air schematics of the requested size and are built using BuilderProcess just like any other schematic. This means (almost) all build* settings apply to them and I would recommend using buildRepeat and buildRepeatCount instead of making the tunnel a thousand blocks long.

As for why the builder behaves like that in your case, here's my guess: Baritone scans for wrong blocks in two "passes". One is executed every tick and scans a radius of builderTickScanRadius blocks around you, the other is only executed if no wrong blocks are known and scans the whole schematic (which is why large schematics sometimes freeze the game for a second). Baritone considers unloaded blocks incorrect unless it knows they are correct and only remembers a maximum of incorrectSize incorrect blocks and in addition, after scanning, if distanceTrim is enabled (enabled by default), all positions farther away than 10*sqrt(2) blocks are pruned, unless that would remove all known incorrect positions. Both scans work from low coordinate values to high coordinate values and your tunnel probably goes towards -x or -z. That means if it happens that all incorrect blocks within the tick scan radius are also within reach it will break all known incorrect blocks and as a result start a full scan. Because your tunnel goes towards -x / -z it starts scanning from the other side of the tunnel and once it has found incorrectSize (100) wrong blocks it stops and starts pathing to its known incorrect positions, which now are all on the last 14 14 to 100 (depending on the iteration order) meters of the tunnel. Only if by chance it walks close enough to some other part of the tunnel those blocks come into the tick scan radius and are recognized (and distanceTrim discards the far away positions) and Baritone starts walking back into the tunnel. In the end of the video it did not come past another part of the tunnel, so it kept walking towards the end.

Another thing the builder does wrong.