Friday Facts #374 - Smarter robots

[Illiou]

Very exciting to hear about these robot improvements! Quality of life improvements often excite me more than new content actually.

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

1. Bots returning to recharge

• Construction robot has a task that's near the edge of the construction area
• Bot flies from afar, losing its charge when near the destination
• Bot slowly returns to the dock station, then proceeds to complete and finish the task

Possible solution: When the robot flies near the roboport, it stops to recharge even on medium-level energy OR the robot plans its route to pass through the roboports.

[mmmPI]

Nice !

[wekkka]

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

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

[JustSmileMan]

I registered specifically to say I unironically am more excited by this FFF than the last week's. By all that is unholy, i want this in right now.

[Giacint]

I love this FFF

[mmmPI]

like is it part of a Wube mod in expansion, or applies to everyone with vanilla (no exp), or just SA mod, or enabled with settings etc?

i thought it is a "engine change" that will apply to everyone for game created with the vanilla game version that is released alongside the expansion and further on

[aka13]

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.

[jodokus31]

Overall, good stuff!

[SnowZyDe]

Please add the ability to increase the amount of battery charge for the drone

[gGeorg]

Nice things.
Espeecially I likee the option to set base amount of robots per roboport. It makes servicing (repairing) long automatic defence walls a bit more interesting, lower average "repair lag".

I have a question:
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?

2. Can robots avoid fire ?
I loose a lot of robots on my own remnants of fire. Repair bots are released to repair walls, while pond of fire are active, so my own robots are killed by my own flames.

3. When we can set base amount of robots per roboport, is it possible to control release of robots by a combinator ? It could be nice feature control releasing or not-releasing by a logic state build-in switch.

[Hares]

the bot improvements really look nice, that is nice work there.

I have a question/request to devs though. do not get me wrong, I like the ideas but also I am thinking about my future play because some new features/improvements might require restarting maps (I guess) I have been investing for hundreds of hours. I would like to know how these new features or improvements apply and when. like is it part of a Wube mod in expansion, or applies to everyone with vanilla (no exp), or just SA mod, or enabled with settings etc?

it might be good to mention how these are organized/enabled. since this is a QoL change, I would make a guess here and say the entire today's FFF topic applies to all expansion games (regardless of SA) but to vanilla (no exp) as well? would this be wrong?

maybe in the future you might introduce something like "this new fancy thing is new but only in SA enabled maps" kind of stuff and then it will make more sense about my request.

They said that these changes would be part of 2.0 game, regardless of having DLC

[kajacx]

Very cool to see these improvements. The "logistic request" on the roboport for robots is a godsend, will it work for repair packs too?

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.

[Cordylus]

I would absolutely embrace the charging pole for the robots.
Something that would require way less space than roboport and is used solely for charging them.

[gGeorg]

flame throwers put biters and the walls on fire, bots come in to repair / rebuild walls immediately and die in the fire

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

Make it so:
if an_entity has a (flame/acid/bug/anything_dangerous_to_bot) in the range of 2 tiles
then it wont create repair call.

[greenyaptec]

Great improvements!

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?

[Hares]

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?

I solved this issue by using a requester chest with circuit-controlled requests, and two filter inserters on the opposite sides with the same filter signal, but different filter settings. One, whitelisted, puts all items that are requested in the very specific amount to the wagon, and the other (blacklisted) removes anything that is no longer required.

2. Can robots avoid fire ?
I loose a lot of robots on my own remnants of fire. Repair bots are released to repair walls, while pond of fire are active, so my own robots are killed by my own flames.

I've seen Michael Hendriks solving this issue by completely removing repair packs from the wall network. Robots were free to replace destroyed walls or turrets, but not to repair them. Cons: constant beep alarms and notifications about missing repair packs.

A note to say, that the circle of death is the situation when one bot repairs the wall in the fire, and the other bot is sent to repair the fitst bot, then the other bot is sent to repair the second bot, etc. Eventually, they all die.

3. When we can set base amount of robots per roboport, is it possible to control release of robots by a combinator ? It could be nice feature control releasing or not-releasing by a logic state build-in switch.

I can see the following:

1. You have the roboport in the center of your base that always requests 100 bots of each kind
2. You have four chests and four controlled by circuits inseters near that roboport.
3. Two inserters add robots from the blue requester chests when the amount of free robots is below a certain threshold
4. Two other inserters do the opposite -- remove the excess robots from the network and put them in the purple active provider chests

Basically, this works pretty well in Vanilla, as long as there are robots in that roboport. With the roboports recalling robots automatically, this will work every time as long as you've set the limits correctly. See blueprint for details.

0eNq9ltFuozAQRf/Fz6TCNA4JWvVHqggZcNqRHJu1B7RRxL+vDW2WJU5C0t0+IZvxnZlzPYgjKWQjagMKSXYkUGplSfZ6JBbeFJd+Dw+1IBkBFHsSEcX3fmV0oWttkHQRAVWJXySj3TYiQiEgiEGjXxxy1ewLYVzA+emI1Nq6A1r5TF6ExhE5kCxJnLArBo2WeSHeeQva+BgjeJVL/QYWoXRpdlxaEQ3bXhZzixzdCzSN2+ctB8kLKU5nct1g3biw6w1+hi96Ud8mauRypkw3zuyZumpK3+bM7OMj0wrmy3UDQyX6WOtf04FhNfYH3GrVbTsXfuZZcg6kfBcWF9xptmJRG91C5SLPnYzXT2zwkj2xkPbzSXsHEoVZgLLC4A2xpRMLX40STNkAekDV6fAOjH3A7B4y90NB4zj2633NDUefibzcQ5Z5stFHi8NcfA7MxfzbAK3lF5zY3HCC3ePE5n86Eb74/86N51H3fp3OcCdUU8ih1R+K3PlyhSGlfzOswAy19zZ/L9GETYH+uAcoDQENwEnnw4m/D861wf8iGDYBc+kLu74010b8bNzzxgViPaOP2Pzee+y7afq5YnHwTm8eqi5+oLqJFZPK3K9F71w2+l+JSOvU+rzJmi7TTZKmjMYrtuq633doDHg=

Copy blueprint

[Miroro]

Hi WUBE team,
I like the first announcment a lot.
Just a quick question. Is there a chance to get this updates for bots as in today's FFF before the main extension? Still into current vanilla version (current engine)?
Are there any extension modification planned to be implemented prior the main extension to the regular version and most important earlier then in 1 year time?

Anyway thanks for the FFF. They keep our minds busy waiting for the big thing.

regards

[Diablo]

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

[LoSboccacc]

Oof I imagine it's going to be super annoying to code all the corner cases due research changing the robot parameter.

[Pompeij]

I like this change and can't wait for it to get live!
While reading I had one concern, what happens if a bot with some tasks in queue can't fullfill one, like no chest to drop of the tree. Will all tasks after that wait till there is space in the network again?

keep it going
Pompeij