[1.16.4] Endless pathing
juleklO opened this issue · 38 comments
OS: WinPro10 64bit
Mod version: 1.6.2
Settings used: buildInLayers true, layerorder true, buildinlayers true;
When I select a large area to mine out the bot mines for a while and than stops in place and tried to find path. Even when I try moving the bot that has been standing in place for a while to a different spot it takes over and tries to return to the block where it was standing and trying to path.
Additionally when a selection is made where "layer 0" is comprised exclusively of air the bot doesn't select the layer as "complete".
I will try to answer any and all questions below.
https://youtu.be/GRW-gAq3rIc <- this in video form with some changed settings, all in desc.
It does, you might need to restart pathing though
What do you mean by restart pathing?
stop and start it
after testing with allowbreak and the such, baritone changes it's path when settings are changed
stop and start it
after testing with allowbreak and the such, baritone changes it's path when settings are changed
I did as show in the video, I changed the settings, did #cancel and than (visible in the video) #sel cleararea with the changed settings applied
can you run #modified, in the video it seemed that you were thinking those were the changed settings, however this will tell you for certain all of the settings that you have changed.
https://youtu.be/e0gqi1E0Eh8 give it a sec to upload, but still no changes
Yes, as you said it looks like it is something wrong with the command - however they do the exact same thing, maybe try #sel set air. That should do the exact same thing as cleararea, however it may work, this is really weird behaviour that definitely shouldn't happen, however I doubt there will ever be a fix due to there being a work around and baritone not being in active development.
Yes, as you said it looks like it is something wrong with the command - however they do the exact same thing, maybe try #sel set air. That should do the exact same thing as cleararea, however it may work, this is really weird behaviour that definitely shouldn't happen, however I doubt there will ever be a fix due to there being a work around and baritone not being in active development.
I tried it after I stopped the recording, it does exactly what #sel cleararea does, it stops in the same place and tries to path
Yea, if you know that work around then just use it, this is probably an issue with the Fill schematic, however in my brief look over it now I can't see anything drastically wrong.
I know that this is an issue (I have seen it before), however can you try without any settings changed and check for any difference in behaviour. This will just let us know whether a single setting is messing this us or if everything is broken. Do you happen to have sodium installed as well?
I know that this is an issue (I have seen it before), however can you try without any settings changed and check for any difference in behaviour. This will just let us know whether a single setting is messing this us or if everything is broken. Do you happen to have sodium installed as well?
If I don't know what sodium is than most likely I do not have it installed, but what can change a thing or two is that I'm using the barritone as an integration from impact client. I will test with unchanged settings and update you on the situation.
https://youtu.be/UKCdEm3GdCA TL:DR changing settings doesn't change the behaviour
Yea, if you know that work around then just use it, this is probably an issue with the Fill schematic, however in my brief look over it now I can't see anything drastically wrong.
Unfortunately #sel replace stone air only affects stone, well it's always something, I guess we can keep this ticket open in case any changes arise
Update:
I think I know what causes the problem, it seems like the bot tries to replace air blocks with air. Therefore when there's a pocket of air in the area selected (like a cave) bot tries to "mine out air", which is impossible and this is where it gets stuck.
This is my interpretation of what I see, but maybe it can lead you to the actual problem.
Can anyone confirm if this is happening on 1.12.2 (or any other branches), or is this problem isolated to just 1.16.
Didn't try to confirm anything, but to me #2318 (comment) looks like a plausible explanation. If cave_air is indeed the problem here, then 1.12.2 would be the only version not having the problem.
The solution would be to treat cave_air, void_air and air the same like @m-sarabi suggested (although void_air should never occur, it only generates outside the world and I don't know any reason why servers might want to use it)
Maybe it would be better to create a new issue about this exact bug, then it would be able to close this and #2318 as they are essentially duplicates but just with different symptoms.
Maybe it would be better to create a new issue about this exact bug, then it would be able to close this and #2318 as they are essentially duplicates but just with different symptoms.
I'm down to whatever you are. I don't mind this being open
The same thing happened to me while I was digging out a chunk. I selected the chunk and started the cleararea with reverse layer order. it did a pretty great job at first and then after reaching some caves it suddenly broke, it stood at one spot doing nothing.
After testing a lot of unrelated things and failing of course, finally I turned on the chat debug (XD) and realized that it had a goal that was empty. I simply placed a block at that spot and It temporary started mining again before it stopped at another spot. Well the thing is that as of 1.13 caves and underground structures generate minecraft:cave_air instead of air inside them. so by simply adding the cave_air into the buildIgnoreBlocks list suddenly everything started working again.
Temporary solution: Add cave_air in the buildIgnoreBlocks
Solution: Baritone should treat air, cave_air and void_air the same.
Indeed this fixes the problem. Thank you for assistance
I could have sworn I fixed this literally two years ago 717779f#diff-63dc3b66352cd86578e9c3c8dbee3dfaa77f195d08480abc9384e93371d71221R587
Baritone treats all types of BlockAir the same?
FillSchematic seems to be the culprit here.
} else if (current.getBlock() != Blocks.AIR) {
return Blocks.AIR.getDefaultState();
}
As I said I am not a java developer.
for now you could solve the problem like this:
Block cannot be mined.
try again.
Block cannot be mined.
Ignore this block.
or:
Block cannot be removed.
try to put a block there.
try to remove block.
It may well be that my solution attempt is completely stupid.
Maybe @L1ving could write something about this or another java developer.
Someone just has to change it to:
} else if (current.getBlock() != Blocks.AIR & current.getBlock() != Blocks.CAVE_AIR ) {
return Blocks.AIR.getDefaultState();
}
But someone actually has to do this.
You have said.
Someone just has to change it to:
} else if (current.getBlock() != Blocks.AIR & current.getBlock() != Blocks.CAVE_AIR ) { return Blocks.AIR.getDefaultState(); }But someone actually has to do this.
Shit, sorry man...
Yeah, and actually test it, I don't trust myself that much, there is also another type of air in minecraft 1.12 that should be added here as well. I might get around to doing it properly soon, however doing it properly involves fully testing it to make sure that it actually fixes the problem.
FillSchematic seems to be the culprit here.
} else if (current.getBlock() != Blocks.AIR) { return Blocks.AIR.getDefaultState(); }
In which file did you find the code?
Yeah, and actually test it, I don't trust myself that much, there is also another type of air in minecraft 1.12 that should be added here as well. I might get around to doing it properly soon, however doing it properly involves fully testing it to make sure that it actually fixes the problem.
I'd wait with "doing it properly" until 1.17.x. Alot might change than, so we don't want to put work into something that will become obsolete with the next update.
So only one function is missing to ignore air blocks?
No, there's about 16 occurrences of a comparison to "Blocks.AIR" on master, though some of them are correct usages. This function is just what I think causes this specific bug.
I'd wait with "doing it properly" until 1.17.x. Alot might change than, so we don't want to put work into something that will become obsolete with the next update.
We're talking about a project that supports 1.12+, so everything in 1.12 will still be relevant after the update.
I think just removing this if-block should work, because the builder itself already breaks wrong blocks. (I actually did this on my branch for #2323 and haven't noticed problems with it so far)