baritone
baritone copied to clipboard
#mine cannot find ancient debris but #goto can
Some information
Operating system: windows Java version: 8 update 2.1 Minecraft version: 1.16.4 Baritone version: 1.6.3 Other mods (if used): see logs
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/
latest.log
Mac: /Library/Application\ Support/minecraft/logs/
How to reproduce
- type #mine ancient_debris, baritone will say "can't find block" or something similar
- type #goto ancient_debris, it works fine.
Modified settings
parkour, sprint, avoidance, freelook
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.
Can you maybe try again with only Baritone (you don't even need fabric-api)? If it works without other mods, try finding the minimum set of mods for this bug to occur.
Doesn't goto use caching / exploring yet mine just uses the render distance, so it may help if you move to an area that you haven't explored much yet and try there.
I had this issue as well a while ago and there definitely was ancient debris nearby. I now use a different set of mods as well as a different mc version and it is gone, so I assume it's one of the mods (though I don't know which). Checking sources anyway.
this (taken from searchWorld in MineProcess) looks like it should find any cached blocks in the region the player is in + its neighbours right away
for (BlockOptionalMeta bom : filter.blocks()) {
Block block = bom.getBlock();
if (CachedChunk.BLOCKS_TO_KEEP_TRACK_OF.contains(block)) {
BetterBlockPos pf = ctx.baritone.getPlayerContext().playerFeet();
// maxRegionDistanceSq 2 means adjacent directly or adjacent diagonally; nothing further than that
locs.addAll(ctx.worldData.getCachedWorld().getLocationsOf(
BlockUtils.blockToString(block),
Baritone.settings().maxCachedWorldScanCount.value,
pf.x,
pf.z,
2
));
} else {
untracked.add(block);
}
}
and GetToBlockProcess actually uses exactly the same method
private synchronized void rescan(List<BlockPos> known, CalculationContext context) {
List<BlockPos> positions = MineProcess.searchWorld(context, new BlockOptionalMetaLookup(gettingTo), 64, known, blacklist, Collections.emptyList());
positions.removeIf(blacklist::contains);
knownLocations = positions;
}
hes not using a diamond or netherite pickaxe. that's prob why
@thenewuser02, is Ethan right and if so, does using a diamond/netherite pickaxe help?
yes
I specifically asked @thenewuser02.
@thenewuser02, is Ethan right and if so, does using a diamond/netherite pickaxe help?
@ZacSharp I had a diamond pickaxe in my hand. In response to your first comment, I tried uninstalling every mod and also reinstalling the fabric loader and continued to have the same issue. (sorry for the very delayed response)
when the bot can find no viable targets, it will cancel the #mine operation, but with the #goto operation it will search randomly

This was changed in #2736 and since then MineProcess as well explores when exploreForBlocks is enabled.
This was changed in #2736 and since then
MineProcessas well explores whenexploreForBlocksis enabled.
I think I need to reopen this issue since I'm facing a similar issue. Currently, if you try to mine with legitMine false and exploreForBlocks true, it does search and doesn't give up(which this pull requested fixed) until it finds an ore, then, when the first set of ores it found get mined, and there is none nearby anymore, it gives up again.