BuildCraft|Core

BuildCraft|Core

7M Downloads

Robots pathing does not work for far away stations

chemdork123 opened this issue · 19 comments

commented

I found that robot pathing fails to work when they are headed to a station that is a considerable distance away. If a robot is headed toward a "close" docking station, it will seek to avoid solid blocks normally; however, if a robot is headed toward a "far away" docking station--not sure at what distance this happens--they will go directly toward the station and phase through all solid blocks along the way.
Again, I'm not sure at what distance this occurs, but in a flat creative world I setup a simple transfer of liquid from one tank to another. A full tank was setup with 6 docking stations to allow robots to pull liquid. One tank was placed within 30 blocks of the full tank, but only with one docking station to drop off liquid. One tank was placed about 200 blocks away with 5 docking stations to drop off liquid. A wall of stone was built between the full tank, close tank, and far away tank. When 6 tank robots were set to work, they all pulled liquid normally, but only the one going to the closest tank avoided the wall - the others phased right through it.

commented

@hea3ven I think you're missing the point. The point is that robots go through walls. (And chemdork123 is the first one for whom they do.) Robots should not be going through walls.

commented

yeah, there's a bug that when the pathfinding fails, the robots still run the go to in a straight line ai.

commented

Hmm, it didn't feel like, but I guess the station was out of range. Technically speaking the range is a path length of 96 blocks, so it depends on how many corners and blocks the robot needs to go around. Usually assuming a 64 blocks radius is a safe bet. I'll fix the range for the next version.

Regarding how to rework it in your world, I won't tell you my solution since you are the kind of guy that likes to figure out things, plus there's more than one way to do it. But I will mention something that would be hard to learn by yourself, and that is that the "Go to station" action can take a map location of a block and side as a parameter, and that will make the robot go to a station in that block and side, and set it as it's main link.

commented

They should try with another station/go to sleep, because the target station either is out of range or unreachable.

commented

Should robots have a longer path length (and the bug with straight line pathfinding fixed)? [Also, we might want to add a way for robots to signalize errors with their LEDs.]

commented

Or what about adding a feature to use a station as an "access point" or "waypoint" for robots? Not sure how that feature would work, but maybe by adding a gate action "use waypoint" and then associating that action with a map location similar to how the "Go to station" feature works? The robot would look for a station to do work, and if it didn't find anything, it would go to the "waypoint" station...

commented

Is the range of the robots unlimited? I’d imagine this would cause issues with chunk loading. Why not add a limit so that the path finding doesn’t need a waypoint and they don’t go off into the sunset? I know you can already enforce a limit with the “work in area” trigger but is there any limits in the code at all?

commented

@hea3ven @asiekierka Yes, I will try for now to setup a "waypoint" station to force pathfinding. I've played around with the "go to station" + point map location before (which has other cool uses...), so was actually planning to do that anyway.

By the way, what is the action of robots supposed to be if path-finding fails instead of going through walls?

commented

Should robots have a longer path length?

Increasing the range exponentially increases the time it takes for the pathfinding to detect unreachable targets. This affects all robots, including for instance the picker. On my machine this already takes around 40 sec.

I always went with the 64 block radius guideline when tweaking the numbers and optimizing the algorithm. @dj3520 the robots can go anywhere, but the pathfinding is limited, like I said to a 96 block path. The idea of waypoints or "signal repeaters" does sound interesting.

commented

maybe a new gate action that takes a map location with a robot station as parm, you can use that to tell a robot to go there but it doesn't set the station as it's main link so it's still controled from the initial station

commented

Isn't it possible that robot going after work (picker) will go too far from home station and then the go station signal wouldn't work with flat path finding limit.

commented

I wonder if robots could pathfind from docking station to docking station, or if docking stations could keep paths to other docking stations cached.

Like using the pathmarks to specify something like a robot highway and being able to place docking stations to connect?

commented

@chemdork123 Not necessarily. Essentially "a docking station knows how to get to all neighboring docking stations it can reach; a robot can hop from docking station to docking station to get to the docking station it eventually wants to reach"

commented

docking stations caching paths is no good idea, if the path becomes obstructed the same thing will heapen

commented

@AEnterprise - The path can be re-checked before moving. Checking if a path still has empty blocks is hundreds of times faster than finding the path to begin with.

commented

true, though an occasional refinding of the path might be benifitial, in case a better path becomes possible over time

commented

I wonder if robots could pathfind from docking station to docking station, or if docking stations could keep paths to other docking stations cached.

commented

is this gona stay in the factory of dreams?

commented

Thinking a bit about this, the mechanic becomes very useful if you are able to keep distant chunks loaded (chunks all along the "robot highway"). Not sure how realistic that would be...