Friday Facts #374 - Smarter robots

[Sopenas]

Nice changes. Cant wait for train improvements

[MrGrim]

Who cares?

Not you, clearly.

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.

Multiple people have tried to demonstrate how there are possible ways to do it that won't impact performance of _bots in flight_, which has always been the main concern. You clearly have your own axe to grind, and the ironic part is yours requires continuous sorting which would add just as much complexity to job assignment as a graph traversal would.

Bot job assignment happens at a fixed rate, and a relatively slow rate at that. Performance hits for both of our pet features does not depend on number of bots in a network or number of bots in flight and would be relatively constant. That's why methods that only need extra work there are ideal.

If we're both super nice, maybe we can both get what we want. Although, probably not. There's no need for the defensiveness. We're just talking here. There's nothing to win or lose.

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

I guess sorted assignments would make it a bit faster especially before speed upgrades, but it's not so bad. "NOT WORK" is a bit extreme. I've built 100's of km of rail with personal roboports.

[Geiun]

I've got a power-gamer feature request related to bot efficiency. As we know, robots have a cargo size and they always take a full payload if possible. This is great for reducing total bot traffic, but in many cases it's difficult to take advantage of this feature if provider chests are trickling resources in. Sometimes I solve this problem by using extra inserters and logic to guarantee that bots always take a full payload. It's tedious, but it improves the efficiency of my factory enormously.

Example. Say I have a factory (P - producer) producing U238 in one location and using an inserter to store them in a passive provider chest, and I have another factory a long distance away consuming these products via requester chests (C - consumer) to make fuel cells and ammunition. Factory P doesn't make enough to keep up demand. It's only making 1 U238 per second. But I emptied all my buffers by grabbing lots of ammo from Factory C.

Now, until my buffers refill, every second the provider chest will get 1 new U238, and another bot will be dispatched to grab it. Chances are, the bot will get there quickly enough to grab the one U238 there, and it will go on its way. Depending how far the distance between Factory P and Factory C is, we could have a LOT of bots travelling this journey at a time. And we should be able to cut it by 75% just by being smarter about it.

When I need to solve this problem I use the following design at my producer factory.

Inserter-A.png (209.51 KiB) Viewed 3604 times

And here's the settings on the stack inserter:

Inserter-B.png (66.96 KiB) Viewed 3604 times

This pretty much ensures that every delivery from this factory fills the full cargo capacity of a bot.

The problem is the tediousness. You can't just use a stack inserter without limiting the stack size because if the chest on the left somehow ends up with 5 U238 now you have a bad number for the bots. But the more tedious problem is that bot cargo size goes up as you unlock research and every time it changes you have to go back and update all of your settings. And I use this design a lot because it makes such a huge difference to my game.

This problem is far more obvious with mods that allow for much higher bot cargo capacity.

There may be a number of ways to solve this problem. If we could have a checkbox on inserters that only allows them to grab a full stack that would let my cut this design down to a single inserter and a single chest. Better yet would be a checkbox on the provider chest that, when enabled, only reveals its contents to the network in multiples of the current bot cargo size. So if my passive provider chest has 3 U238 and the cargo size is currently 4, the chest contributes nothing to the network. And if the chest has 25 U238 and the cargo size is currently 4, the chest contributes 24 U238 to the network.

[Locane]

Oh my god YES! THANK YOU for making these improvements! This has honestly been one of my biggest complaints about Factorio for the thousands of hours I've been playing it, I had to use a mod to re-assign work orders to make it playable in large bases.

THIS is the kind of content *I'm* excited about for the release - can we patch this in to the game sooner than "next year"? Pretty please? I am going through a Space Exploration run for the first time that this would be a HUGE improvement for.

Also, I feel vindicated that I'm not "playing wrong" as some of the forum goers here seemed to feel when I posted about this originally:
viewtopic.php?t=82403

[picklock]

Very nice improvement.

Will this also be implemented to the base game?

[SLB]

That's what I need.
As you can see, when you have a city block of this size, drone distribution issues can cause significant delays for certain needs.

[Foreststrike]

FINALLY.

One improvement I would make:
I think Construction robots should fill up on their inventory from multiple construction or deconstruction tasks, having them bounce/queue up tasks for even more versatility in actually *not* placing one structure at a time or removing one structure at a time.

Based on bonuses, construction robots have it rough when they have all this inventory space, and only place or remove one structure at a time, leading to the "Ride of the Valkyries" every time you need a blueprint placed down.

Bouncing like the newer system of a logistic robot's queued tasks, but with construction, would really help with UPS, I think.

[Arphox]

I love Factorio mostly for how amazingly high quality it is.
In my opinion, for Factorio, QoL has higher priority than new features, so please keep QoL improvements coming! <3

[FritzHugo3]

Why no way to route bots like player want? a option to fly only line of roboports. ("Streets in the sky")
why not realy new ways like under water, in the ground, 3d map with different high level.

the realy most thinks what i see and read are long time there with mods.
Have you integrated the tool for straighter energy cable? it should be in vanila.

From Mods we have planets, orbits, better robots (personal helpes the network).
I know vanila must be easy for all casual gamer but why not new settings/mechanic and not what we have as mod in a easier way.
(And yes i love Space Exploration, K2, 248k ...., but we have it. And for a easier Space Exploration paying many money? Sorry)


For now i cant see anything new for what i should pay 30€. Iwait and hoped so long time for great new thinks. I love the game, have over 3k play houres.

I hope there are really many more new thinks as here communicated now.


But this is allways the big risk if dev's dont comunicate what they planned. So the player cant say what they realy want to have. I hope you will make your money with the vanila players.

[TheKillerChicken]

Looks interesting. My 90 trillion+ bots are going to be happy. (Well, my ~2 million bots, actually) You are the best, Wube.

[seePyou]

This was wonderful to read! I love robots and I use them A LOT and I loved reading all those improvements!!!

[BicycleEater]

FINALLY.

One improvement I would make:
I think Construction robots should fill up on their inventory from multiple construction or deconstruction tasks, having them bounce/queue up tasks for even more versatility in actually *not* placing one structure at a time or removing one structure at a time.

Based on bonuses, construction robots have it rough when they have all this inventory space, and only place or remove one structure at a time, leading to the "Ride of the Valkyries" every time you need a blueprint placed down.

Bouncing like the newer system of a logistic robot's queued tasks, but with construction, would really help with UPS, I think.

Ooh, it does seem possible that the task queuing could allow bots to fill multiple construction orders, and make carry capacity matter more for construction, as well as logistics... That could be really cool.

[KatherineOfSky]

Wow, these changes are AWESOME! Thank you so much for improving the QoL items. While all of us are looking forward to new features, I DEFINITELY appreciate the quality of life stuff because I play the game so much, and all improvements lead to a smoother gameplay experience. Thank you! <3

[makpia]

this is awesome, all my bad experience using robots have been improved. can't wait to play the new version

[dongeddis]

One thing I'd love to see tackled is the classic problem of logistic robots delivering to player, but player leaves logistic area and all robots go back. Would it be possible that if the player goes back to the area, the robots turn around again with the item in them and deliver it to the player? Instead of new batch of robots taking new items?

I made a forum account just to echo this comment. When building on the outskirts of the base, adding new roboports to the frontier ... I find myself walking into and out of the logistics network all the time. The bots deal very badly with that, in terms of personal resupply. Constantly heading towards me, then abandoning me to dump their cargo as I step out of the network, then a whole new fleet heading towards me when I step back into the network. Would be nice to have a close bot, that already has the item I need, that is trying to dump it into some storage chest, instead get retasked to return to me after all when I re-enter the logistics network.

[5thHorseman]

I know that you are mainly looking forward to the new content, and that just quality of life improvements aren't the kind of things that make people buy the game and get excited for.

Couldn't disagree more. This title got me the most excited to play the game than any I've read in the FFFs in years.

Yes, including last week's announcement of the upcoming space update.

(now to read the content!)

[kitters]

O my god.
Thank u very much.
I had a such annoying problem with bots, that had forced me to find other ways.
I had a task to transfer huge amount of things per sec from one line if chests to another line of chests few squares away (equally distributed) Specifically, 4 blue lines per 10 squares of length, gap was about 10 squares (4 of them for a line of roboports).
Stupid bots used to fly diagonally. One bot flied from bottom provider chest to top accepting chest while another at the same time was flying from top provider to bottom acceptor.
And they could work like this for 5 min and then would collapsed randomly. Spending all energy waiting in line to charge. Or u could collapse it manually just by adding another 50 bots in the system. Had to come up with some shit with logic to automatically restart the system and carefully measure the perfect amount of bots for the most (pseudo)stable configuration.
Later turned to a line of belt full of cars. Sacrificed even distribution, but realised, it was not needed. And let me to disable not working lines to not passively drain energy. But unfortunately that loops of belts can't cross rails, so only one line of train stations. Unfortunate downgrade.

I was so frustrated understanding bots can work so much more efficient with better task destribution and here are such great news!!! Hurray!

By the way, this would be only in expansion, at least one year lately, or uploaded earlier?

[VampireSilence]

Re: Mitigation for robot pathing over lakes

Over the past few years, I have had some thoughts of my own about this, which I would like to share:

Initially:
- The robot should anticipate, if it is able to fly to its target with full speed.
-> if it is not able to do so, go for strategy A.
-> If it is able to, just do it.

Strategy A:
- Cache the robot's internal pointer/id/whatever you use.
- Release the task from the robot and re-assign it to another nearest robot.
- Check, if the new robot is as near as the cached one (or even further away).
-> If so, go for strategy B, using the cached robot again.

Strategy B:
- The robot should anticipate, which roboport it will fly to when entering low energy fly mode.
-> Fly to that roboport directly.
-> Check if that roboport is nearer to the target than the roboport the robot started from.
-> If not, fall back to strategy C.

Strategy C:
The strategy you described in the FF #374.

--------------------------------------------------------------------------------

Another annoying situation you didn't cover already:

When you build something big for which you already have materials (for example, in storage chests nearby), sometimes the robots choose a chest near them but far from the target. So it might be more efficient to search for the nearest chest first, and then find a robot near that chest to assign the task to.

[Sander_Bouwhuis]

I have played this game for hundreds of hours (in early Early Access), but never used robots. I think they are a cheat.
I only build my factories with belts because I like the difficulty of getting the logistics done sort of like in a real world city.

Are there many people like me, or does just about everyone just use robots to make it easy for themselves?

[blazespinnaker]

If you use a controller (say switch version), bots are kinda awkward, so I find I use them less. It's a lot of fun, but lots of things about factorio are fun, all in different ways.