"Looping" behavior while building schematic

mvrozanti commented 3 years ago

Some information

Operating system: Linux 5.8.13-arch1-1 Java version:

openjdk version "1.8.0_265"
OpenJDK Runtime Environment (build 1.8.0_265-b01)
OpenJDK 64-Bit Server VM (build 25.265-b01, mixed mode)

Minecraft version: 1.15.2 Baritone version: v1.5.3 Forge mods (if used): Forge is not installed; using Impact client

Exception, error or logs

http://ix.io/2DOd

How to reproduce

Can't really tell more than using this schematic file

Modified settings

allowInventory
assumeStep
buildInLayers
simplifyUnloadedYCoord

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.
[] I have not used any OwO's or UwU's in this issue.

scorbett123 commented 3 years ago

Your log file doesn't seem to include the error, is it possible that you could upload another with the error in it.

mvrozanti commented 3 years ago

Oh my bad here's the latest.log. Hope this isn't a duplicate or a dumb issue :smile:

mvrozanti commented 3 years ago

I should add: the build started fine. A bit "loopy", in that it would glitch a bit when it found water but that was fixable by just moving around and resuming.

But every time I start it back up in the same position I previously started building (not resume) and it goes for build layer 6, the whole game crashes. When I try again, it also crashes.

mvrozanti commented 3 years ago

setting simplifyUnloadedYCoord to false seems to fix it.

mvrozanti commented 3 years ago

That problem seems to have fixed itself but I still get a lot of "looping" while building. It will put down a necessary block for the schematic and then break it to go somewhere and when that location is reached it builds back a path to where it put the necessary block, breaks it, and repeats this process.

I tried toggling buildInLayers as I read in another issue, to no avail.

Shouldn't "don't break positionally correct blocks for the build" be a rule?

ZacSharp commented 3 years ago

It is already penalized by having ten times the cost by default

/**
 * Multiply the cost of breaking a block that's correct in the builder's schematic by this coefficient
 */
public final Setting<Double> breakCorrectBlockPenaltyMultiplier = new Setting<>(10d);

mvrozanti commented 3 years ago

Oh ok I didn't know about that setting. I'm still kinda confused why it loops so much though. It happens quite frequently.

ZacSharp commented 3 years ago

are the blocks it breaks and places repeatedly orientation specific (e.g. chests or doors)?

mvrozanti commented 3 years ago

No, it's dirt, which belongs to the acceptableThrowawayItems setting

ZacSharp commented 3 years ago

and it places it in a spot where the schematic wants dirt?

mvrozanti commented 3 years ago

No, dirt is not a part of this schematic

ZacSharp commented 3 years ago

It places the dirt to get somewhere, breaks it as a wrong block and needs to go there again?

mvrozanti commented 3 years ago

It places the dirt to get somewhere

Yes

breaks it as a wrong block and needs to go there again?

I'm not able to tell. Dirt is definitely a "wrong block", but I'm not sure if it breaks it as such or if it needs to go there again. But it do

ZacSharp commented 3 years ago

the dirt doesn't belong there so it is a wrong block. What I meant is: it breaks the dirt before it is where it wanted to go to and then starts over

mvrozanti commented 3 years ago

Yes that's the behavior I'm seeing

ZacSharp commented 3 years ago

don't think there is a good way to prevent that right now. Maybe try allowBreak, buildIgnoreExisting or bridging with materials it can't break with the available tools But I doubt that any of those will work well

mvrozanti commented 3 years ago

Thanks I'm going to try that.

Here's some footage of that behavior

ZacSharp commented 3 years ago

Can you try enabling breakFromAbove? That's for standing on it not breaking from above in general, crap.

mvrozanti commented 3 years ago

Didn't work :/

footage

ZacSharp commented 3 years ago

at least it didn't waste glass. buildIgnoreBlocks is my last hope. It should make baritone completely ignore the dirt

mvrozanti commented 3 years ago

Let me try that one

mvrozanti commented 3 years ago

That actually seems to work great! It leaves behind the dirt blocks but that's nothing that mine can't solve. Thanks a lot @ZacSharp

I think this issue can be closed now

ZacSharp commented 3 years ago

that solution is just a workaround, it should be possible to build schematics in one step

mvrozanti commented 3 years ago

Ok so I'm gonna change the title so it's not misleading

typecasto commented 3 years ago

I've had this behavior too, happened while buildinlayers was set to true or false, only unique thing i can think of was that the schematic material was among the throwaway material. In addition to this behavior, it also had a certain spot that it just pathfinded to for no reason every now and then, a block in the middle of the schematic it would get to no matter the cost, jump at, and then leave, sometimes getting stuck in the loop of doing that 30-40 times before just going back to normal.

zausa commented 3 years ago

if I set buildIgnoreBlocks to stone , it will not clear the stone like a throwaway blocks? Or mapart mode can clear the block that effect the mapart?

ZacSharp commented 3 years ago

buildIgnoreBlocks is my last hope. It should make baritone completely ignore the dirt

@zausa Yes it will just ignore everything on buildIgnoreBlocks and you will have to clear them later (might even work to just reset buildIgnoreBlocks and build again in the same spot). And no, map art mode only makes it ignore blocks that are not visible on the map (i.e. covered by other blocks).

ZacSharp commented 2 years ago

Why did you close this? It has not been fixed yet.

cabaletta / baritone