Buildcraft 7.1.20 for MC 1.7.10

• Miner robot freezes if there are unreachable ore blocks in designated area - as soon as it clears all available blocks he just gets stuck and sits in one place until it runs out of power - he goes to its station, recharges and sits on station being active - debugger says "Search and Go to Block AI program" it's currently trying to do. For this issue to appear ore blocks must not be covered by stone/dirt/whatever from all sides - say, a secluded cave having ores exposed with no entrance from anywhere in the world, but with air blocks inside.

• To reproduce the issue - create superflat world, place few ore blocks exposed to robot and few more covered by other blocks but with air blocks between them and ores. Robot clears exposed ores and freezes.
  Tried different setups with pure BC 7.1.18, 7.1.19, 7.1.20 and 7.1.21 as well as different "covering" blocks from few mods - result is the same all the time. Forge versions tested - 1558, 1614, 1566 for MC 1.7.10

• The same issue affects knight robot as well, just replace ores with mob in this cut off area and viola.
  I suspect shovelman can also be affected, but I've never used it anyway.

thank you for the very detailed bug reports, if only all reports we got about robots where as detailed

we'll have to test to see if this is still heapening with BC8 ( @AlexIIL or @afdw any idea or could you guys test?), sounds like eighter the pathfinder is eighter allowed to search indefinatly or isn't ignoring unreachable locations and keeps trying over and over

this might not get fixed for 1.7.10 though, it depends on the exact root cause and how simple it would be to fix or not

Robots are not yet ready in 8.0.x. @AlexIIL started work on them.

I really wish you could fix it for 1.7.10, of course if only it would not require a complete rewrite of pathfinding algorithm or something. Maybe some restrictions in pathfinding just for block-breaking robots.

By the way, since AEnterprise replied, I would like to thank him for awesome BC additions mod and all BC devs for their hard work - I really enjoyed playing BC since MC 1.5 or even earlier, can't quite remember now, the fun thing is that I've never used robots a lot and now I've tried to do almost anything with them and ran into this issue.

This sounds like the robot doesn't add the ore found to an "unreachable block list", and so retries that block forever. if it is this then it might be a simple fix. The robot code is mostly similar in 8.0.x and 7.1.x though, so I'll probably fix this in 7.1.x and port it forward :)

@GoHereStayThere thanks for your kinds words :) glad we have made things that you enjoy playing with

as for the fixing (like alex just sniped in): it all depends on the differences, if it's just a simple matter of a missing line of code to add to the list then it can definatly be fixed for 1.7.10, but in the case that a large rewrite is needed and that can't be used for BC8 then it might not

but most likely it can be fixed for both, i just said that it might not because i'm not an active BC dev and didn't want to promise a fix that i can't garantee will be made

@AlexIIL Good to hear it, hope 7.1.x gets this bugfix as well as future 8.0.x versions.
And what about knight robot? Is it affected by the same issue, since mob is not a block or something else?

Most likely the same thing, yes.

Duplicate of #2195?

Looks very similar, but this scenario has nothing to do with protected blocks, it's hard to say from the description of #2195 if mentioned blocks were reachable or not.

Anyway, last comment there is 9 months old and since this issue potentially affects all world-interacting robots, it looks like quite a big problem if not for 1.7.10, then at least for future releases. I'll test later if lumberjack and shovelman are affected.

UPD
Shovelman and lumberjack are affected just like miner and knight are - if logs/dirt surrounded by air blocks in their secluded "cave", robots get stuck. If this entire "cave" around minable blocks is filled with covering blocks - no issue at all.

this isn't a duplicate of that issue, though in case that the ai failes to break a block (or whatever it's trying to do with it) it should also add it to the ignore list like unreachable ones, similar but not the same

Previous speculation is not correct.

If you take a look at BuildCraft's current pathfinding algorithm, it goes like this:

• scan the area in a specified radius for matching blocks
• create pathfinders for at most five
• wait for the pathfinders to finish

That last step can take a very long time, as the current default radius is 96, which - with a lot of empty space - easily becomes over a million blocks to scan.

The algorithm has to be redesigned so that it can manage new pathfinders (and cull old ones) by listening to neighbor updates, as well as getting rid of the limit of concurrent pathfinders. Sadly, that is an amount of work I am not willing to tackle. It probably should be done for 8.0.x's robot rewrite, however.

(For expanding, non-zone-based pathfinding, it might also prove useful to combine the "scanning" and "pathfinding" stages for many, many added performance increases.)

However, as the algorithm is not very dependent on Minecraft's version itself, doing it for 7.1.x first might prove to be a good stable testbed - and fix one of the longest-running issues related to robots.

Note that the robot does not actually freeze - it would unfreeze after a few hours of very unnecessary computation.

EDIT: Wait. I have an idea. (It may fix this specific scenario, but it won't fix the problem - the algorithm still has to be redesigned to listen for neighbor updates.)

Nevermind. The workaround would have been to make the scanner try and cull unreachable blocks, but that gives me memory usage concerns at this radius.

What pathfinding algorithm is being used? A*?

Yes.

Another idea would be to not pathfind from the robot to potential targets, but from the targets to the robot - that way, tracking neighbor updates becomes easier: if a target is added, you just add a new pathfinder from that endpoint; if a target is removed, you do likewise.

I also recently ran into a same issue. It also relates to planters. Can see details in my closed issue #3856
Reading this here, this indeed seems to be a rather complicated issue to work around. From my experience the robot usually finds the path rather quickly tho. How about just adding a time limit for how long it searches for a path? I know this would theoretically cause some paths not to be found, but in practice would probably work just fine.(Would then need to add the found block in the "not valid" list or this would turn into a loop)
2nd idea is to take different approach for different robots. For example a miner robot could mine it's way through for the ores if it doesn't find a path to in say... 30 seconds?. For a planter could make it possible to add y coordinates in the zone planner. And the knight.... a bit more difficult, but perhaps make it teleport if it doesn't find a path (a bit OP and could cause issues, but might work)
Just some ideas. Hope they can help you with solving this issue. Also want to thank you for this awesome mod and good work! ;)