Some ore is not being considered for mining

[maxsupermanhd]

Some information

Operating system: Arch Linux
Java version: zulu17.46.19-ca-jdk17.0.9
Minecraft version: 1.20.2
Baritone version: baritone-standalone-fabric-1.2.19-597-ga945cfaa
Other mods (if used): meteor, meteor rejects, sodium, lithium, starlight, concurrent chunk management engine, krypton, ferrite core, immediately fast, lazydfu, litematica, some more misc that should not matter

Exception, error or logs

There is nothing in the logs relatable to this issue, no exceptions, errors or warnings.

How to reproduce

Mine for a long time and watch it not mine parts of the vein. (Redstone for example, both regular and deepslate variant)
After you spotted a not fully mined vein, stopping and trying to execute process again it still does not consider it for mining.
There is no lava nor falling blocks anywhere near leftovers.
It does not highlight them or anything.

Ore Y level is at -58 and -59 but even with legitMineYLevel set lower it does not attempt to mine them. (idunno maybe someone forgot an if somewhere)

Enabling ChatDebug shows that pathing was not considered to anywhere near leftover ore.

Modified settings

No modified settings, literally did a #reset all

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.

[maxsupermanhd]

I managed to catch it with screenshot, it does not even select it as green.

[ZacSharp]

The two ones encased in bedrock are explicitly excluded from being mined.

[maxsupermanhd]

That is a different clump and when it is encased in bedrock it is not really an issue but ones that are not are really annoying, will take a picture as soon as I encounter it again (in couple minutes)

[maxsupermanhd]

How about this one?

[maxsupermanhd]

And this one

[maxsupermanhd]

And quick note: all leftovers always look the same

[maxsupermanhd]

If chunk gets updated or player moves somewhere it seems to "update" and pick them back as goals, unsure how this is happening but when pathing through them I decided to stop and re-execute mining command and it did pick them up

[maxsupermanhd]

I can confirm, all not-fully-mined clumps are separated in 2 different chunks. Removing concurrent chunk management system...

[ZacSharp]

You might also want to try building Baritone with the old world scanner to check whether it's a problem exclusive to the new one.

[ZacSharp]

And quick note: all leftovers always look the same

What does that mean? Always three ores in an L shape in the same cardinal direction?

[maxsupermanhd]

in an L shape in the same cardinal direction

Exactly

[maxsupermanhd]

I removed concurrent chunk management system and it seems to update more frequently and now it does capture globs on chunk borders fully. Still watching, will close it if I will be sure that it is a cause.

[maxsupermanhd]

After disabling c2me and observing it for 15 minutes I can say that problem is still clearly there but it is less noticeable. Also I don't think root cause is c2me but it is likely just catalyst that drives this bug to absurd. Without c2me, as I already noted, it does scan chunks more frequently but still sometimes not enough to avoid leaving behind target blocks.

Also, sometimes, if being very lucky, it will highlight some of the clump, start mining it and due to diagonal ore it will not update the goal or something and will leave it be and after next clump is mined it backtracks and mines what is left behind.

I would like to know how to build it with old world scanner, are there commits I can locally revert or is there some toggle?

[maxsupermanhd]

For example this:

It was highlighted as green as it was walking beside it, not sure if it was when nearby ore was mined.

[ZacSharp]

If you look at the sources under src/main/java/baritone/cache there's FasterWorldScanner and WorldScanner, those are the new and only old ones respectively (the old one being dead code). You should be able to swap them out by changing the getWorldScanner method in BaritoneProvider to return WorldScanner.INSTANCE.

MineProcess simply scans every mineGoalUpdateInterval ticks without caching so player movement or chunk updates are not supposed to influence MineProcess. Apart from buggy scanner logic missed ores might also be caused by the scan being limited to 64 ores (relevant constant is ORE_LOCATIONS_COUNT in MineProcess) and generally poor ordering since scanning happens chunk wise.

[maxsupermanhd]

I did exactly what you described, increased ORE_LOCATIONS_COUNT to 512 and had not noticed any significant slowdowns/lags/negatives. I really believe that such thing as ORE_LOCATIONS_COUNT should be configurable at runtime just like any other setting.

Those modifications completely fixed issues I was having.

[wagyourtail]

since scanning happens chunk wise.

subchunk wise, but yeah.

should be configurable at runtime just like any other setting.

yeah, probably.

[maxsupermanhd]

So after a lot of watching baritone mining (around 2.5 hours, don't ask me why I watched baritone mine, it is like watching a fireplaace or smth) it still got one occasion when it did not mined a block. I suppose mine process abuses "goto" command to mine blocks and it does not work in all the cases. Sometimes there are also very questionable decisions about mining target blocks for example mining 3/4 blocks and for last one mining a staircase around it only to mine it from the top and so on.
I believe whole mine process is kinda flawed in this way, some blocks are left behind, some drops will not be picked up and similar imperfections, it really bothers me. Is there really no way to specify that player needs to path to this place and then mine those specific blocks? Also 90% of the time player is able to get drops that are under the block of bedrock so it might as well mine it.
I don't know what did I touched but for me it also randomly decides not to wait for drops even though time to wait is set to absurd 1.5 seconds and there is no way server lagspikes that much without me noticing it. A task to specifically collect items will be a great addition since I play on a server where stack clumping is increased a lot and they just bunch up outside of player's mine position by a block.

[ZacSharp]

I don't know what did I touched but for me it also randomly decides not to wait for drops even though time to wait is set to absurd 1.5 seconds and there is no way server lagspikes that much without me noticing it

Perfectly matches my observations.
EDIT: but when I tried finding the cause it did wait...

Is there really no way to specify that player needs to path to this place and then mine those specific blocks?

That's what BuilderProcess does and you don't want that either. Trust me, MineProcess is better at its job than BuilderProcess. It is surely possible to do some reasonable mining, but it's a lot more effort than just piggybacking on PathingBehavior being good at walking and all you would get from it is a a couple seconds and a handful ores.