Same as issue #1754, but I think I have provided better steps to reproduce the issue.

Some information

Operating system: Win 10
Java version: build 1.8.0_241-b07
Minecraft version: Forge 1.12.2
Baritone version: 1.2.15
Other mods (if used):
Schematica-1.12.2-1.8.0.169-universal.jar
LunatriusCore-1.12.2-1.2.0.42-universal.jar

Exception, error or logs

Please find your latest.log or debug.log in this folder and attach it to the issue

Linux: ~/.minecraft/logs/

Windows: %appdata%/.minecraft/logs/

Mac: /Library/Application\ Support/minecraft/logs/

How to reproduce

It seems to happen when baritone wants to ascend a staircase with carpets on it while building a schematic, I have attached a schematic file with a simple example where It happens whenever you start building from ground level. One 'solution' I have found; having buildinlayers set to true prevents the issue.

Modified settings

To get the modified settings run #modified in game
No modified settings although I tried setting allowDownward to false to no avail along with messing with a lot of the other movement related settings none of them seem to have any effect.

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.

carpet test 2.zip

ZacSharp@2d9852f (artifacts here) should fix the weird behaviour plus another bug that happened way more often because of that fix.

EDIT: the workflow artifacts are long expired, here's a manually created Artifacts.zip

well, you fixed the problem in the video so I think you have a solution!

#sel p1
#sel p2
#sel ex a up 1
#sel fill carpet

It started the loop with and without that "fix"

well, you fixed the problem in the video so I think you have a solution!

Not really what I was looking for. Having build in layers on when using a very large schematic is much less practical and comes with a whole other slew of issues regarding what I think is the baritone cache size. This results in baritone not actually building anything and just running around and 'rechecking if it is done with the layer or not'.

I was looking for a solution that didn't require build in layers since it is not practical for my application.

This results in baritone not actually building anything and just running around and 'rechecking if it is done with the layer or not'.

cut up the schematic into parts that actually fit in render distance

While that definitely helps (buildOnlySelection is also an option) I'd really like to know why Baritone can't handle such big schematics because it should never forget about correct positions and always focus on correcting nearby incorrect positions and as a result should not walk back and forth to scan the schematic.

While that definitely helps (buildOnlySelection is also an option) I'd really like to know why Baritone can't handle such big schematics because it should never forget about correct positions and always focus on correcting nearby incorrect positions and as a result should not walk back and forth to scan the schematic.

I have tried 'cutting' the schematic up into smaller pieces but the one main issue with that the pathing will often use/break the surrounding are thus un-doing work from other schematics as well it is a pain to do. I haven't messed around with buildOnlySelection since id doesn't seem to be showing up in my settings menu, but I suspect it would suffer from the same issues I just mentioned.

As far as why baritone is forgetting correct positions, there was a key detail that I forgot to mention in my previous post. Thanks to baritone sometimes getting me kicked from the server I am on from getting stuck, it seems to have to recheck correct positions upon reconnecting, and that can take quite a while when the schematic is 8x16 chunks in my case.

Can you maybe test ZacSharp@74b708e (build artifacts are here)? It should prevent the loop but at the same time seems to introduce some new odd behaviour, maybe it works for you.

Carpet is really odd because it effectively is the top face of the block below it and it seems like it's not handled properly in other parts of Baritone as well. E.g. Baritone does fall for the double carpet trick normally used to fool mob ai and can't even walk off of a 1 by 1 carpet pillar.

Also the builder can't place blocks at eye height with air above them (because it would block itself) so if you have a spot where it just needs to but a carpet onto a block on the floor it will probably get stuck standing next to the position.

Can you maybe test ZacSharp/baritone@74b708e (build artifacts are here)? It should prevent the loop but at the same time seems to introduce some new odd behavior, maybe it works for you.

Not exactly sure how I would go about testing this.

you click the button on the text "here" and then click on "Artifacts" which downloads a zip containing the usual baritone release jars for 1.12.2. then you test it the way you were testing it

you click the button on the text "here" and then click on "Artifacts" which downloads a zip containing the usual baritone release jars for 1.12.2. then you test it the way you were testing it

Thanks for the explanation, I'm not an avid github user.

This seems to be working. It is def doing some weird stuff but it isn't getting stuck to that's all I care. I'll do some more thorough testing with some actual map art, but all seems to be well so far. Thanks so much for the help!

Can this be looked into please? Still occurring on the 1,20 elytra beta build aswell as the latest 1.20 stable release for standalone. Makes creating staircased mapart incredibly tedious as it is fully impossible to let it run AFK. Will test with a flat mapart soon to see if its the case with that as well (doubt it), Would it be possible to treat carpets in a way that it cannot be stood on the block to place it but essentially "ignore" the fact there is a carpet placed on top of a block for pathfinding?

The problem is not the pathfinding itself but rather the way certain blocks have to be placed and that however you fix it you inevitably have to fix more and more follow up bugs because the builder decision logic can't handle the complexity.
E.g. you could fix this bug by not pillar placing blocks that can't be walked on, but when I did that it caused some other bug related to where it has to stand to place certain blocks (carpets in this case, don't know anymore what exactly broke) and fixing that leads to Baritone no longer automatically placing the supporting block first. Detecting whether a block needs a supporting block is nearly impossible (and hardcoding wouldn't work with mods) so that's where I stopped when I had a look at it, because at this point the effort increases dramatically.
One could try making it learn placement constraints (everyone seems to like neural networks, decision trees are an option, maybe something I don't even know would work too) but then again, that's a whole lot of effort and in the end chances are it wouldn't be of much use because larger scale loops where Baritone places a support block / scaffolding block and then breaks it would become more likely and fixing that as well is where you are better off rewriting the whole thing.

This does not mean this is not fixable with less effort, just that so far nobody found an easy fix. If you have one, please share it.