Friday Facts #374 - Smarter robots

[cid0rz]

Hello, great news! QoL and optimizations are very appreciated by the hardcore factorio players . As many people have requested please implement more circuit network mechanics, with the roboports, with the trains and in general with the game. It gaves a new dimension to every aspect of the game!

Cheers!

[Allexz]

I don't think i've commented in at least a year here, but THIS.
THIS is what made it worth to log in

Well, to be fair the new expansion might just be super awesome, but polish like this is just beautiful for someone who has been playing for 10 years... it's just pure gold!

[ptx0]

that's really cool! it's amazing how intuitive and straightforward the solutions were, especially after Rseding91 told players for years that it couldn't be done!

[roy7]

With this new feature, we can set all the roboports near our resupply point to always have 100 logistic robots available. Once we arrive, our needs are serviced in record time, and afterwards you can see robots arriving to get the roboport back up to 100.

In the example animation, it seemed the robots that brought us goods then flew off to another part of the base, while the replacement logistic bots also came from another part of the base. Is fulfilling the logistics standby robot request not added to the queue like other tasks? It seems it'd have been faster for the robots fulfilling our personal requests to just land back into those roboports.

[Klonan]

With this new feature, we can set all the roboports near our resupply point to always have 100 logistic robots available. Once we arrive, our needs are serviced in record time, and afterwards you can see robots arriving to get the roboport back up to 100.

In the example animation, it seemed the robots that brought us goods then flew off to another part of the base, while the replacement logistic bots also came from another part of the base. Is fulfilling the logistics standby robot request not added to the queue like other tasks? It seems it'd have been faster for the robots fulfilling our personal requests to just land back into those roboports.

Many of them flew off far away to drop-off the trash they picked from the character inventory

[roy7]

Many of them flew off far away to drop-off the trash they picked from the character inventory

Doh! Such a simple explanation. It didn't occur to me they were taking from us, I was thinking they were only refilling from the chests. Thanks.

[MassiveDynamic]

These are excellent improvements, and fixing some of the minor inconveniences we've asked about. Thank you. Will this be in a bugfix? Or is it strictly part of the new content?

[RedViper]

Regarding the pathing over lakes: it seems that now you are using the selection of a roboport closer to the destination basically as a failure mode for when the robot needs to charge. Wouldn't it be possible to check immediately after a job is assigned to a robot if the distance is actually reachable without charging (either assuming a full charge or if possible considering the actual charge level of that robot) and if not immediately path to a roboport closer to the destination instead, then try again.

That would mean robots altogether avoid situations where they are out nowhere running out of charge and instead intelligently move along roboport lines. That would solve the problem described by Hares below and would also make robots move more predictably as they would not cut corners by a huge amount, thereby even somewhat mitigating the problem of robots flying into biter nests (although not a full solve, as they would still fly outside robot ranges by some amount, but maybe enough).

This has a few problems, first it's more UPS intensive, I think the devs have stuck with the "path in a straight line" because of just how fast it is.

Second, in several situations it would actually be slower to do what you suggest than just path in a straight line. Even the implementation show here suffers from this, it takes longer to go to a nearby port and recharge than it would have taken to just fly on low energy to the final destination.

To fix the second issue you'd need to make estimates for how long both paths would take and how long it would take the robot to recharge, but again this makes robot significantly more UPS intensive.

One more thing that needs improving but wasn't mentioned is robot recharching in general. I have seen countless times robots fly toward their destination, only to stop 5 meters before they finish and they fly backwards 50 tiles to a random roboport to recharge. That is really annoying.

The better way would be to calculate if they can make it to target before hand when they start (one calculation) and if they don't, they should path towards a roboport along the path to begin with, and not stop and turn around 2 meters before the finish point.

This is adressed in the last topic of the FFF.

And see above for why your proposed fix doesn't work (Imo anyway)

Thank you so much for the updates to bots, they (were) probably the most annoying issues in the game, and this goes a long way.
Just thinking though, can we maybe see something like this? viewtopic.php?f=6&t=103400
Just since you're on the topic, and if bots work the way they seem to, they have a "current destination" (or queue of them), as well as a "charging destination" for them to pick a roboport to recharge at. You could implement that suggestion by: looking ahead to where the bot will need recharging (a multiplication), and then finding a charging roboport from there (exactly as normal, but different starting location), and setting the drone to recharge at that roboport, rather than try and go straight to the destination. Drones can clearly go to recharge before reaching low power, so this seems very doable... If I'm wrong about how it works, and theres a programming reason why that would be hard, that's fine, but I can't see any requirement for anything you don't already have code-wise... Maybe at least give it a shot, so many people here would LOVE YOU.
Seriously, these improvements are so nice to see.

(also note that this would allow you to make drones not recharge at roboports further (or as far) from the destination than the original start point, which, with some tweaking, may result in drones naturally following the contours of the network in most cases, and could even get to the point where crawl states virtually never happen... which would be amazing.
Also also, will there be modding support for controlling robot behaviour? We currently have almost no control over them via the API...

Same as above, this solution, while it works, can make the robots slower is some situations and would make them massive performance hogs.

[Terry]

Cool change!

One thing about the logistic system that has been bugging me is how by default requester chests ignore buffer chests. In some of the use cases I have for them, I do want them to supply all requests, and it's super annoying to have to remember to check the "request from buffer chests" box every time.

Same here! I personally can't think of an example where you would not want to request from buffer chest. I generally use buffer chests to manage items that are both waste and request products, such as empty barrels. The first time I set this up I spend half an hour wondering why nothing was delivered.

[gallomimia]

AWESOME!!!!!

I honestly figured you would eventually make these exact improvements. Almost as if it was deterministic. In lockstep.

[BicycleEater]

Regarding the pathing over lakes: it seems that now you are using the selection of a roboport closer to the destination basically as a failure mode for when the ...

This has a few problems, first it's more UPS intensive, I think the devs have stuck with the "path in a straight line" because of just how fast it is.

I've heard this a lot "it's more UPS intensive" seems the catchall counter to "bots should be better". I don't see any reason why this would be noticably more UPS intensive. The operations involved are:
1. like 4 multiply operations to find the location the robot would recharge at
2. "find roboport to recharge at" (notably this operation would have had to be done anyway)
3. literally nothing else
I'm not clear why it's believed this problem exists, and I'd like you to explain what you think would be so UPS intensive

Second, in several situations it would actually be slower to do what you suggest than just path in a straight line. Even the implementation show here suffers from this, it takes longer to go to a nearby port and recharge than it would have taken to just fly on low energy to the final destination.

Well, no, the implementation shown here is objectively better than the original, performing at least as well. Note that in the original, flying on low energy to the destination was not the behaviour the bots showed. They just got stuck. The new behaviour is an improvement.
The solution we are proposing can *literally never* result in a longer path than the new behaviour. It doesn't result in the best possible behaviour, but it is a good approximation, and a consistent improvement is a consistent improvement.
Proof that it is always better:
- If the previous behaviour would reach the destination without recharging, the proposed behaviour would also do so.
- If the previous behaviour would not reach the destination without recharging, it would instead take a non-straight-line route to the charging point. The proposed behaviour takes a straight line route to the charging port, which is shorter.
There are no other cases, so the proposed behaviour is always as good or better than the new behaviour, which is as good or better than the old behaviour.
There may be other behaviours which are better yet, but again, improvements are improvements.
If you can find a flaw in this proof, (or just a counterexample), I'll consider it, but, like, those are the only cases.

To fix the second issue you'd need to make estimates for how long both paths would take and how long it would take the robot to recharge, but again this makes robot significantly more UPS intensive.

Yes, path finding would be better for bot routing, but would be UPS-intensive, hence, the proposed solution is not path finding.

...

This is adressed in the last topic of the FFF.

And see above for why your proposed fix doesn't work (Imo anyway)

No, the last part does not address it. If there is no closer roboport to the destination than the drone currently is, the drone will still turn around, away from the destination to recharge, at least, that's my interpretation. They stated:

...so that the robot tries to always charge at a roboport that is closer to the destination than the robot is...

so the current logic would seem to apply in there were no roboports closer than the robot. Of course, that's up to interpretation, and we'd have to get the devs involved to clear it up. Either way, it's not clear they've solved this, though crawling to destination would be an 'alright' solution. It's just really annoying to be waiting for a drone to do something, and watch it almost get there, then turn around and recharge. This hasn't changed.

...

Same as above, this solution, while it works, can make the robots slower is some situations and would make them massive performance hogs.

Again, same as above, this can't make the robots slower in any situation, except in comparison to a hypothetical alternative routing system, which doesn't exist.
Also same as above, it doesn't seem to add any non-trivial performance cost to robot journeys. A single linear extrapolation per flight is, like, almost exactly nothing. If you want, I could work out some sketch code, and count processor cycles for you, but that seems unnecessary.

The proposed changes by the devs do solve, like, a lot of the issues, reducing the savings from this approach, but a huge factor is how much it would reduce the visual annoyance and make the robots look smart(er).

[bombcar]

These are the kinds of Friday Facts I love - clear description of problems I've encountered, the issues around it, and then an elegantly simple solution that make everyone say "why wasn't it done that way from the beginning?"

[Hares]

The proposed changes by the devs do solve, like, a lot of the issues, reducing the savings from this approach, but a huge factor is how much it would reduce the visual annoyance and make the robots look smart(er).

I agree with @BicycleEater.
Literally every single statement he said is true.

Also, addressing the UPS performance. There are some ways to optimize robot pathfinding, like pre-calculating maps from tile to tile, etc.
However, even if the new pathfinding would be slower, it would be a breakthrough because robots are already UPS-intense entities so you should not rely on them when your base is so big that the performance drop would be noticeable. I.e., I am building a 2k eco-friendly megabase (which generates mathematically the lowest amount of pollution possible), and this means huge, enormous fields of 12-beaconed assemblers and 16-beaconed oil refineries. And you know what? I didn't have that many UPS drops while tens of thousands of construction robots flew away. Yeah, there were some drops, but there were tens of thousands of them. As long as you do not passthrough the entire factory bus via the bots, the UX should be fine.

[juliejayne]

The "solution" for bots running out of fuel and turning back, seems like a good idea when you have it set up as in the example. But if their start point was the nearest roboport to their destination, it wouldn't help.

Why not treat the bots like ants. If x number of bots have to turn around then the next x don't. Instead they sacrifice themselves for the greater good and drop down transforming into temporary mini charge points. The next tranche of bots can then get further and maybe they too will have to sacrifice themselves at 2/3rds of the trip. But eventually they will get there, with their temporary charge point brothers and sisters charging and cheering them on.

[thoma5nator]

On QOL:

Warframe died due to lack of QOL (and polish). The Sentient Ship update was the final straw for me, I've never been back since.
FFXIV has been doing QoL here and there, and it's working damn well for them, although not to the point where the playerbase is totally happy with the speed.
QoL can absolutely be the death of a game due to 'death of a thousand cuts'. As was so rightly evidenced, QoL frees up mental capacity to focus on other problems. The alternative is a growing spiral of features that possess no simple way to flow from one to the other, the dreaded '**** this' zone.

[ickputzdirwech]

Very exciting news!

One question: When the closest available robot is searched, does it take into account for stacks of robots? For example if 10 robots are needed to fulfil a task would the search run 10 times or would it stop after the first time when the closest robot it found is part of a stack with at least 10 robots?

[niki_dev]

The timing of this update is actually insane (as - just this week - I realized that robots were dropping UPS, so I wanted to extract about 50k logistic bots from my main network). Fantastic improvements, thank you!

[kitt159]

You've already made so many improvements in the cleverness of the behavior of various entities that it might be worth considering adding a "better software" item to the research (Seriously, it would feel great to suddenly unlock such improvements after using dumb robots for a while.)

In terms of robot intelligence, the big issue is certainly performance. So I was wondering if you have any awareness of the planning algorithms that are used in robotics in practice. I'm thinking of algorithms like RRT/RRT* (and other variants) or PRM (https://www.youtube.com/watch?v=gP6MRe_IHFo). These are algorithms that can be very fast when used correctly. I think it could also speed up enemy pathfinding. (A*-like algorithms are quite slow in large grids.)

Finally, I was wondering if it would be possible to use the GPU for robot planning. After all, it's one program running on many data (robots), which is a well parallelizable task.

[DanGio]

Excellent ! The bot requesting roboports will certainly allow interesting new strategies.

[D0rus]

With the addition of both queue's, have deadlocks been resolved? I saw no mention of this in the FF, and it was the first thing that crossed my mind as an interesting topic to discus.

Imagine a task to cut down a tree, and another to build a building in that location. What if both tasks are assigned to the same bot, but the tree task is second? This would cause an deadlock.

Another more complicated scenario, bot 1 tries to build building A and then deconstruct tree B, and bot 2 tries to building building C and then deconstruct tree D, but tree D blocks building A and tree B blocks building C. etc.