Friday Facts #374 - Smarter robots

[SuperSandro2000]

Noise! Hype train!

[malderan]

Oh this announcement really does make me so happy! ... and not to sound ungrateful, but this basically just leaves one last pet peeve of robot logic I would love to mention (because hey ... if you don't ask?!) ...

It looks like potentially this is partially addressed by the new multiple tasks logic, but what really kills me is if I'm clearing a large area of trees, or laying a large area of concrete; the bots first job are all clustered to one strip but then all the remaining tasks seem to get allocated randomly. It's tedious as inefficient ...

What would be great to see is the personal bots grab the nearest task to them after delivering an item to your inventory. The large benefit to this would be allowing the player to move around the area of work reducing the average distance the bots have to travel through the overall task. Player and bots working together to efficiently clear or tile an area.

[gujarat6]

This is great!! Tbh qol changes are way more awaited than new content. Let the factories be HUGE! Do the same optimization for inserters and I will die happily playing this game for the rest of my life. Amazing work on the robots!

[Necronium]

Hi cool update,

2 questions:

1: will this update also come to F1.1?
2: will this also address the queing issue where robots basically do nothing for an extended period of time if the build queue is extremely large (ghosted items) and some items are not available?

kind regards,

Diablo

We are getting FFF with changes that will come for 2.0 update which is released with DLC so it wont be in 1.1 ver

[fusionfan]

I'm for one extremely happy to see QoL changes!

[BicycleEater]

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...

[EvanT]

Hi

The changes will certainly improve lots of situations.

It would be nice though to get the lits of items needed for build requests from the logistic network. Like you can get the list of all available items. Maybe just add that as negative values?

I supply outposts by train and every outpost has its own logistic network. I set a minimum of items which should be present at the outpost and trains wich have them. But there is no way to set a filter inserter to unload only what is needed for the build requests.

[maniak1349]

I wander why first four videos have fff-369 in their name. Did someone want to spoil cool things to early and got smacked on the wrist with a ruler? :D

[Brathahn]

If you make the robots themselves smarter, can you make roboports smarter too?
Like having a output to report missing construction materials to the circuit network. This would make outpost base construction so much easier.

[Gemma]

Everyone is probably most excited by the expansion, but this is the most exciting FFF for me in a long time. I have been praying for these changes for years. Thank you so much, my heart is filled with joy.

[Tyras]

YESSSS! This is some of what we've wanted for so long! Thanks, Devs, for your unwavering dedication to the finer nuances of this game!

Now, I can't recall, but did the robot carry capacity ever get fixed for construction robots to carry multiple of things when going to lay down fields of concrete or such? Last I knew the capacity worked fine for deconstructing, but not for building. Are we still waiting on that?

[dexteritas]

[...]
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. [...]

I had the same idea when reading the last section of the article. If the destination is to far away, to get there with one charge, the robot should plan find path over one or multiple roboborts that are within the maximum distance.

The result would be similar to this image on DBSCAN (but not to the procedure itself) (source: https://en.wikipedia.org/wiki/DBSCAN).

DBSCAN-Illustration.svg.png (37.82 KiB) Viewed 3612 times

For efficient computation, it should be enough to determine the graph of connected roboports (nodes) for each type of robot. The nodes would have a connection as long as they are within the maximum range of a robot. After that, a simple routing algorithm can be used.

[BicycleEater]

I've just thought for a while about the proposed update to drones, and there are situations where it performs pretty badly (though thanks to the choice of a 20% speed while crawling, it's still an improvement).
If you have a long line of roboports almost tangential to the destination, but with a slight angle, so they get very slightly closer with each roboport, then the system will crawl a really long way down the line, at some points going right past roboports while crawling. This seems... like an issue.
It feels like it would be better to have the drones:
A) go to any roboport closer to their destination than, like, their current location - half their travel distance, just to make it less bad in those cases.
B) (for some other side cases) use the distance from destination as part of their recharging heuristic.

[grandexar]

Excellent! I’m glad these changes were feasible without much reduction in performance! I’m very glad for these QOL features and I’m extremely happy about the logistic robot request! Now I can easily remove the 2 random builder robots from my network!!!

Everyone else in this thread is asking for more robot features. Maybe there needs to be a comprehensive mod (with toggleable options) that supports all these other features that might really reduce fps.

Like “more bot QOLs”
* fireproof bots
* no fly zones, or long-path-but-stay-in-network
* don’t try to place entities until the space has been cleared below it
* etc.

And I bet there are already mods for this!

Good work, and don’t feel like these people asking for more are mad with what you’ve done. I bet everyone who uses bots will truly appreciate the effort you’ve put in! (They’ll probably not even notice the changes, but they also won’t think “man these bots are dumb” so often. That’s the true victory!)

[BicycleEater]

...

Basically exactly this is what I've been arguing for. Look ahead, and pre-emptive recharge. It won't fix all cases, but defaulting to current behaviour should be fine.
Also note that by doing this but taking roboports that are closer to the destination by, say, 1/3 the robots range, rather than the full range, should mitigate the issue of long tangential lines. (though long lines sloped slightly away from the destination are still a problem, that is much harder).

[dexteritas]

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?

Exact delivery, however, would often lead to another problem. 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.

[BicycleEater]

Excellent! I’m glad these changes were feasible without much reduction in performance! I’m very glad for these QOL features and I’m extremely happy about the logistic robot request! Now I can easily remove the 2 random builder robots from my network!!!

Everyone else in this thread is asking for more robot features. Maybe there needs to be a comprehensive mod (with toggleable options) that supports all these other features that might really reduce fps.

Like “more bot QOLs”
* fireproof bots
* no fly zones, or long-path-but-stay-in-network
* don’t try to place entities until the space has been cleared below it
* etc.

And I bet there are already mods for this!

Good work, and don’t feel like these people asking for more are mad with what you’ve done. I bet everyone who uses bots will truly appreciate the effort you’ve put in! (They’ll probably not even notice the changes, but they also won’t think “man these bots are dumb” so often. That’s the true victory!)

Oh, yeah, it's a huge improvement, no doubt at all.
There is a mod for fireproof bots (I'm pretty sure, because it would be really easy).

Unfortunately no fly-zones/long-path-but-stay-in-network are impossible via modding without completely re-implementing robots (either using lua to hand implement motion, or some other entity, different path finding, etc. It's currently impossible to get that kind of control through the API, and honestly, having that control would be great anyway.
I'm not sure about not placing entitys until the space has been cleared, but I think it would involve writing your own blueprint system.
Etc.
One of the reasons these are very commonly requested QOL improvements is that they are nigh-impossible to mod in, so have to be done by the devs either implementing them, or adding support.

Anyway, I can see why that control isn't given. The robots are a very 'tense' bit of factorio, and have huge performance concerns attached. I understand the dev's choices, just think that there are improvements that can be made.

[BobBridges]

<rant>I've been playing, and reading the blogs, for a few years now, and enthusing to others about the game. After reading the latest news, I just had to register just to tell you how impressed I am:

It's always seemed to me that Factorio is a programmer's game. Maybe it seems so to me only because I'm a programmer, but it's obvious to me that I enjoy figuring out a new factory layout for the same reason, and in the same way, that I like coding.

And the latest news update is a programmer's update, too; you don't just tell us what's different but also how you made it different; I found it fascinating.

While I'm fulminating I'll add this: I'm a proofreader, too (which I guess is a little unusual for coders), and I keep expecting to see errors or at least awkwardnesses in the writing. You folk are from somewhere in Europe—Poland, I think?—so I thought I might volunteer to help you with these blogs. But no need; the writing is beautiful, not just fluent English but good writing (says the self-appointed expert).</rant>

Ok, I'm done. I just had to find a way to tell you how much I'm enjoying.

[KyleSpades]

I’ve been playing this beautiful game for years and I've literally waited for this single robot update every single minute. Thank you, guys, this is a massive update. It's not a simple QOL update, it changes everything. The way the factory is structured depends a lot on the bot mechanics. Congratulations and thank you very much!

[Jarin]

So to make things clear, the reason that we make and present these kind of changes is not because we don't want to make new flashy features, we just want the new stuff to be enjoyable without a burden of having too much to deal with.
But don't worry, we will show something new next week!

Proceeds to show massive foundational improvements in robot usage that we have been wishing for

yeah ok

Basically my thoughts as well. This is amazing, feel free to keep the great QOL stuff coming!