Friday Facts #374 - Smarter robots

[Nukedpenguin]

An obvious solution: make bots immune to the fire AoE DoT

Might be a bit tooo QoL, one could even say cheaty

Well the trouble is that there is no way at all to prevent them flying into the fire.
I used to have a timer circuit, which would forcefully remove the bots from the perimeter repair outpost sections, but what that would lead to is 285778956389762093475 flashing warnings how repair packs are missing, and then upon reinsertion nothing getting repaired - since the repair queue works the same way, as the construction queue, 600 at a time are checked.

Yes the circuit can help keep the bots out of harms way but it's always distracting to see the missing bots/items icon spamming everywhere when you intentionally did it. I think there should be a toggle on the roboport to not show building alerts, because we can set up a speaker saying if that network doesn't have any bots or repair packs, but simplifying it to a single alert instead of 601+ damaged/missing materials. Also it would be a super nice Qol feature if roboports also have a toggle to read entity ghosts so we can supply as needed.

[MacFeejj]

Love the robot improvements! One thing I've found when playing the Space Exploration mod is that its superchargers, roboports that have no bot capacity and charge extremely fast, are often ignored in favour of roboports. While this change would help to mitigate that, I think including the charging speed of the roboports in the heuristic would improve this behaviour (perhaps estimating how many charging slots will be free by the time the bot reaches the charger)

[MrGrim]

Well, when people speak of pathfinding, they usually refer to dynamic obstacles and collision detection. Since bots are flying, none of them is applicable. There's just a number of static waypoints. Unlike the true pathfinding, this operation is quite cheap.

Waypoints is pathfinding. It was popular with quake bots, for instance. That way they didn't have to worry about clipping through walls and such. There's no fundamental difference between finding paths through a network of roboports and finding paths through a grid of tiles - minor features of the network may differ, but the algorithms are the same. It's still pathfinding, and I'm fairly certain that's what the FFF author meant - pathfinding among a network of roboports is still a variety of pathfinding. And still expensive both in CPU and complexity of code. And the lighter you tried to make it on the CPU, the more complex the code would be, and the more difficult to debug. Which is my point, really.

The difference is that if you can guarantee the path won't ever need to change then all of the complexity can be hoisted out of the tick function and only performed during task assignment. The lack of collision and dynamic obstacles allows this. There's no need to check every tick if something got in the way. In fact, the new queueing system literally is waypoints!

[dupraz]

Life saving changes, been dealing with those exact issues with every single one of my use of robots, even stopped using them in wide area scenarios altogether, and had specific hopes for fixing the pathfinding, especially if you consider the case of networks spanning a large (empty) perimeter for rebuilding defenses and automatically self-expend (say worst case scenario: based on an infinitely large perfect square, would one bot be able to get from the middle one side to the middle of the opposite one without softlocking nor crawling all the way along the edge following your new robotport picking algorithm rather than the closest one?), but wouldn't having the bots calculate the maximum radius distance it can reach (may be constant since speed increases also increases energy consumption but I never calculated if this increase was linearly correlated), and then picking the closest one (or following your demonstrated, or improved picking/pathfinding algorithm) to the destination allow them to reach their destination faster in most cases? having bots crawl half the map (repeatedly) just to make small jumps in progress every time is definitely not optimal, and real pathfinding would probably be the only definitive solution to avoiding crawl + softlocks, but anyway I'm assuming repeatedly picking closer bots for larger tasks (say place 4k walls), coupled with assigning bots to specific roboports for balancing (but could you at least confirm whether this works for both logistic and construction bots as well?), could already fix most of the issues in this case.

One other issue left that is still really annoying is bots starting to crawl away to the nearest network (possibly very far away and in large amounts), forcing you to hunt them down and pick them up manually (one-by-one!) when removing robotports (especially common when switching from portable ones to say legs), I guess having them stay put in this scenario, at least until you put in back on (in case of portable robotport), would save lots of time especially since once they made the decision to crawl away half the base there is no way to bring them back.

[jgilmore42]

Well, when people speak of pathfinding, they usually refer to dynamic obstacles and collision detection. Since bots are flying, none of them is applicable. There's just a number of static waypoints. Unlike the true pathfinding, this operation is quite cheap.

Waypoints is pathfinding. It was popular with quake bots, for instance. That way they didn't have to worry about clipping through walls and such. There's no fundamental difference between finding paths through a network of roboports and finding paths through a grid of tiles - minor features of the network may differ, but the algorithms are the same. It's still pathfinding, and I'm fairly certain that's what the FFF author meant - pathfinding among a network of roboports is still a variety of pathfinding. And still expensive both in CPU and complexity of code. And the lighter you tried to make it on the CPU, the more complex the code would be, and the more difficult to debug. Which is my point, really.

The difference is that if you can guarantee the path won't ever need to change then all of the complexity can be hoisted out of the tick function and only performed during task assignment. The lack of collision and dynamic obstacles allows this. There's no need to check every tick if something got in the way. In fact, the new queueing system literally is waypoints!

Who cares? It's still pathfinding, which is explicitly off the table. It's already been explicitly said: "This is because for performance reasons, we don't do any pathfinding at all." Period. Adding such performance for such a minor improvement isn't even a possibility. More to the point, it's a minor improvement that wouldn't benefit very many people at all. The current algorithm is good enough. The improved one proposed in this FFF is a fairly major improvement, gained by a minor change. IMHO oddly shaped areas are an edge case, and SHOULDN'T be improved too much. This is because they're usually (always?) mining outposts. Little mini-bases that you now have to worry about supplying instead of just running a line of roboports and requesting everything you need from the bot network.

Trying to supply minibases with their bullets, replacement walls, etc. is part of the game, and making it TOO easy is counter to the purpose.

As opposed to the "large area personal roboport inefficiencies" problem, which make building the rail lines out to those mini mining bases a massive and continual pain, all because construction robots prefer to build things at the edge of the construction area first for some damn fool reason, instead of building things right next to the player, thus effectively waiting until the player walks (or rides a train) over to that part before building it.

I have no words for how disappointed I was when I tried building rail lines with my shiney new personal roboport, only to find that not only does it NOT WORK, but upgrading the roboports and getting multiple of them, makes the problem worse instead of better.

[MiXtE]

I, on the other hand, encountered a problem with placing upgrade modules in constructors and becons. They need a lot of time to find all the places to place the upgrades.

[gGeorg]

1. Did you solve the "over-delivery" problem ?
Example: requester box asks for 2 walls, logi-bot with 4 slot capacity bring 4 walls.
Is it possible trust logi network to a point, when I ask for certain amount, then logi network delivers the exact requested amount?

If items are constantly taken from the requester chest by an inserter, and especially if the inserter takes the items one at a time (with a low inserter limit), a new robot would start with a single item after each action of the inserter. So in this case there would be unnecessarily many robots flying around.

But perhaps this behavior could be offered as an option via checkbox for each individual Requester Chest.

I see. Hmm, perhaps a "precise delivery" (option) x "bulk delivery" (default value) two state switch in the Requester Chest would do the trick.
So player could choose deeliveery opimised for:
a] volume - common production or train station loading
b] precision - low volume delivery systems like repair stations along the defence wall or "production on demand" lines like mall or delivery high cost items like satellite

[Adael]

I do really love FFFs, I'm enjoying them as much as I enjoy the game. The improvement on the bots are absolutely great!

[malventano]

TL;DR: For personal roboports only, we really, really, really need jobs sorted by distance from the player.
...

This could honestly be done as a tweak to the deconstruction planner/blueprint deployer, at least I'd guess... Just adding tasks in a different order onto the queue, so the close ones get assigned first.

Nope. The player MOVES, and thus the order would need to be re-sorted, at least occasionally, for the tasks nearest to the player to stay at the top of the queue.

Also, I'm not sure what order the queue is in, it may already be sorted in some manner. There's no requirement that tasks only be added to the end of the queue, after all.

I'm a bit surprised there was no mention of a Closest First type of optimization in this FFF, especially given that mod has thousands of downloads and that type of optimization has been requested many times in the forums/Reddit(1,2,3). It's one of the things that is a UPS hog in mod form, but would very likely be doable if coded into the game itself, especially if the devs have already added in distance sorting and the like. With the current optimizations, it feels like they are 99% of the way to achieving this, just missing that one extra piece of context with respect to personal roboports combined with player movement getting a job done considerably faster.

[deepcut]

Will you also look at the way bots behave around fire ?
This is the single point in Factorio to me that feels like an oversight.
Losses are expected, but the way robot losses currently work with flamethrowers feels unfair and something that I have no way to mitigate.
Bot navigation around lakes I can mitigate by building charging stations across the water, fire is worse imo.
I tried the Fireproof Bots mods, but it feels too much like a free lunch; I opted to turn off wall repairs instead.

[BicycleEater]

TL;DR: For personal roboports only, we really, really, really need jobs sorted by distance from the player.
...

This could honestly be done as a tweak to the deconstruction planner/blueprint deployer, at least I'd guess... Just adding tasks in a different order onto the queue, so the close ones get assigned first.

Nope. The player MOVES, and thus the order would need to be re-sorted, at least occasionally, for the tasks nearest to the player to stay at the top of the queue.

Also, I'm not sure what order the queue is in, it may already be sorted in some manner. There's no requirement that tasks only be added to the end of the queue, after all.

Eh, maybe, but at least initialising the queue in a good order would improve things. Sorting it is likely to be completely unfeasable, but initialising it nicely is very possible.

[jgilmore42]

TL;DR: For personal roboports only, we really, really, really need jobs sorted by distance from the player.
...

This could honestly be done as a tweak to the deconstruction planner/blueprint deployer, at least I'd guess... Just adding tasks in a different order onto the queue, so the close ones get assigned first.

Nope. The player MOVES, and thus the order would need to be re-sorted, at least occasionally, for the tasks nearest to the player to stay at the top of the queue.

Also, I'm not sure what order the queue is in, it may already be sorted in some manner. There's no requirement that tasks only be added to the end of the queue, after all.

I'm a bit surprised there was no mention of a Closest First type of optimization in this FFF, especially given that mod has thousands of downloads and that type of optimization has been requested many times in the forums/Reddit(1,2,3). It's one of the things that is a UPS hog in mod form, but would very likely be doable if coded into the game itself, especially if the devs have already added in distance sorting and the like. With the current optimizations, it feels like they are 99% of the way to achieving this, just missing that one extra piece of context with respect to personal roboports combined with player movement getting a job done considerably faster.

WAIT!!! YOu're telling me that "closest first bot priority" is AVAIALABLE!!@>!@ HWERE??!

I need that SO BAD. (Checking it out now...)

[jgilmore42]

TL;DR: For personal roboports only, we really, really, really need jobs sorted by distance from the player.
...

This could honestly be done as a tweak to the deconstruction planner/blueprint deployer, at least I'd guess... Just adding tasks in a different order onto the queue, so the close ones get assigned first.

Nope. The player MOVES, and thus the order would need to be re-sorted, at least occasionally, for the tasks nearest to the player to stay at the top of the queue.

Also, I'm not sure what order the queue is in, it may already be sorted in some manner. There's no requirement that tasks only be added to the end of the queue, after all.

Eh, maybe, but at least initialising the queue in a good order would improve things. Sorting it is likely to be completely unfeasable, but initialising it nicely is very possible.

OK, I'll admit that initializing the queue in "distance to player" order when slapping down a blueprint would help quite a bit. For almost all use cases, that would be enough.

It wouldn't help if you then get distracted, come back to it, and try to build while walking the other way. Nor would it help (much) with laying out larger more two dimensional builds. In the later case, it would be significantly better than what we have now. For doing it backwards later, it would be significantly WORSE than what we have now. But I think that case is contrived enough to be quite uncommon. It would make the priority ordering in the "large print" case look REALLY funky though, even if it's NOT strictly speaking worse than what we have now.

Ohhh... If you also added that slapping the same blueprint down again would eliminate and then re-add things, that would fix the large build case too!

And it would at least make the "I'm so powerful I can ride a train and build a track as we go!" work a damned sight better. It's maybe naive, but that was the expectation that I had when I first built a personal roboport. I was kinda pissed when it not only didn't work but upgrading made it worse instead of better. And this simple fix (if the queue works that way) would address that problem. And a major mismatch between expectation and reality is a problem no matter what the context is.

[Nerdsie]

Thank god for the infinite loop fix, that was the only issue with robots that was super annoying. The rest of the improvements are amazing too, robots are gonna be as smooth as butter

Are we going to have to wait for the expansion to get these smart robots? Or are engine updates going to come out between now and then?

[Khagan]

And it would at least make the "I'm so powerful I can ride a train and build a track as we go!" work a damned sight better. It's maybe naive, but that was the expectation that I had when I first built a personal roboport. I was kinda pissed when it not only didn't work but upgrading made it worse instead of better. And this simple fix (if the queue works that way) would address that problem.

Building a track while you go is always going to be limited primarily by the speed of the bots. Queueing tricks won't change that.

[BicycleEater]

...

Yeah, and it could check if the player roboport range overlaps with the blueprint/deconstruction (if there's multiple in multiplayer, you could, say, build it outwards from both players). It would certainly give the game a good shot initially, though I'd guess it wouldn't affect their role in the global queue, since, to my knowledge, it would only change how tasks got given out initially. But with the bot task queue, that's sufficient anyway, as the personal robots would take all the tasks anyway. Then the tasks would never be waiting for bots, so would be done in the order they were created in.
If any ended up without bots doing them, those would come back in how factorio does task allocation anyway, which is... fine I guess.

For added coolness, the game could allocate all blueprint and deconstruction tasks outwards from the centre, so the bots fill the middle, and work out. Its a bit closer to what might be wanted normally, and would make building prettier. Pretty niche change though.

[malventano]

WAIT!!! YOu're telling me that "closest first bot priority" is AVAIALABLE!!@>!@ HWERE??!

I need that SO BAD. (Checking it out now...)

Yeah, it's been a thing for a while in mod form, but it is UPS-heavy and the implementation is less than ideal (the initial wave of bots will go far away as they leave before the mod can reduce the range to 'force' the closer tiles to be placed first). It was reviewed when it first launched back in 2019 here.

[jgilmore42]

And it would at least make the "I'm so powerful I can ride a train and build a track as we go!" work a damned sight better. It's maybe naive, but that was the expectation that I had when I first built a personal roboport. I was kinda pissed when it not only didn't work but upgrading made it worse instead of better. And this simple fix (if the queue works that way) would address that problem.

Building a track while you go is always going to be limited primarily by the speed of the bots. Queueing tricks won't change that.

Order of operations is MASSIVELY important when the player is moving. For roboports? Yeah, your right, the build order makes not one jot of difference. However, for a moving player, when the robots build the furthest part first, that job takes a long time. If they build the closest part first, that job only takes a moment. And if the player can walk along, staying close to the jobs that are actually happening, the build will be MUCH MUCH quicker. Or, if they robots build the furthest job first, every job takes a very long time, and the build overall can easily take 10-100x longer to complete.

I'll note that when the player's using solar panels, and power for charging is a large concern, the player is much more likely to try to follow the robots. And be disappointed when the robots scatter all over, taking further jobs instead of closer ones, and making any effort to optimize their location pointless and even counterproductive.

If you have a very large build area, and only a few robots (which is easy to arrange in vanilla) this problem is at its worst, is very easy to replicate and is very, very, obvious. The degenerate case is only one robot, of course. Which would be an interesting experiment, now that I think of it.

One scenario where I've seen this clearly, is when the player's speed is close to or slightly slower than the speed of the bots. Assuming the players on a train going left to right across the screen, the bots will launch as each new tile comes into the build area. From there, they'll seem to hover as they "fly" at about the same speed the train is moving. The ones building the track across the bottom of the screen will appear to move more-or-less straight down, and come more-or-less straight back up.

Ideally, anyway. If you can time things right. But anytime you fail to time things just right, a piece of track doesn't get built and the train comes to a jarring halt while you wait for a robot to FINALLY launch and place it. Placing the closest rails first would make this much less likely, and make the overall build take MUCH MUCH less time, and be much less sensitive to small variations in the player's speed.

[mrfitzie]

Will you also look at the way bots behave around fire ?
This is the single point in Factorio to me that feels like an oversight.
Losses are expected, but the way robot losses currently work with flamethrowers feels unfair and something that I have no way to mitigate.
Bot navigation around lakes I can mitigate by building charging stations across the water, fire is worse imo.
I tried the Fireproof Bots mods, but it feels too much like a free lunch; I opted to turn off wall repairs instead.

Here is my idea. The issue is that sometimes in a dogfight you need the repair robots to sacrifice themselves to keep up the repairs, but sometimes you don't want them to, like in border walls with spitters and flamethrowers. I suggest either a global toggle for "work or retreat" or a specific area toggle to trigger this behavior modification.

Of course you could go for total fireproof, but that's unrealistic like you say. maybe they could do with with an upgraded robot frame. An upgrade frame would work well with the robot logistic requester they announced though.

[ChoGGi]

I missed FFF, thank you for bringing them back.