Friday Facts #374 - Smarter robots

[kirkbauer]

Regarding the logistic requests, I'm wondering:

Let's say you are in steady state, 100 logistics bots requested, 100 present. Then 50 robots leave to do something. Does the system immediately send 50 new robots? When the original are done, if they go back to the same place, do you have 150 now?

[jamuspsi]

I never post on these forums, but this is SO AMAZING that I have to! This is an absolute gamechanger and will make prototyping and expanding and EVERYTHING just so, so much better. These are all things I just shrugged off as too complicated/computationally expensive, and now here they are!

I'm excited for a fresh playthrough for these changes ALONE.

99/10 best FFF ever ever ever

[Justderpingalong]

Regarding the logistic requests, I'm wondering:

Let's say you are in steady state, 100 logistics bots requested, 100 present. Then 50 robots leave to do something. Does the system immediately send 50 new robots? When the original are done, if they go back to the same place, do you have 150 now?

Presumably, with bots having a list of tasks now, 'fill up roboport X' would be a task which a bot can be assigned to. So it'd work as follows:

Bot A is sitting in a roboport R which has a request to keep an unspecified number of bots idling around. Bot A is sent off to perform a request. Roboport R now generates a request of 1 bot to be dispatched to fill the spot Bot A left. If bot A can do its' job and return to the roboport the fastest, then Bot A will have 'fill up roboport R' be added to the queue of tasks it should be doing. If another bot can do it faster, then that bot will take bot A's place. Bot A might still go to that roboport as it is most convenient, but that shouldn't matter. As the request is simply a lower limit, not a limit and treshhold at the same time.

However, this did get me thinking: What if we had a way to set certain roboports to be 'private' roboports? These roboports would still extend the logistic network, but the robots inside of the roboport would ONLY look for requests and deliveries generated by the player's logistics requests and trash slots. Likewise, we could have roboports that only dispatch bots for requests inside of their own logistic network (Either having both origin AND destination in the same roboport's network or having either the origin OR the destination within the network) whilst still allowing other bots to pass through. I could certainly see cases where the latter option would be desired (cityblocks) because you can still have proper logistic network covering, but the bots won't go fill jobs in the middle of nowhere. Then again might not be needed anymore, just wanted to throw that out there.

As for the actual FFF: Holy crap setting bot requests is gonna be so useful but like other people pointed out: Can we add repair packs to the roboport's requests, or are we still going to need a requester next to our roboport requesting repair packs?

[tempstuff]

Amazing news!

[mmmPI]

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

That seem a popular request even a dev made a mod for it which reallys makes bot feels stronger :

https://mods.factorio.com/mod/Robot_Battery_Research

[Mskvaer]

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?

"One does not exclude other" - I use both. High, continous volume transfer I use belts, Occasional burst supply needs usually done via robots. Eg. the rocket producing line uses belt, and the Shield producing (for a new Spiderbot) uses bots,as it only occasionally has to produce.

[Mskvaer]

Wow, great super. What a FFF! I like the improvements (who wouldn't ?) The amount of nice "demos" showing the before and after, especially.

[smoroz28]

Do you know about ETOPS?

https://en.wikipedia.org/wiki/ETOPS

[FuryoftheStars]

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?

I think later acording to Kovarex https://www.reddit.com/r/factorio/comme ... s/jyng4bh/

This all is core engine performance, which means it'll come as a part of 1.2 with the expansion, but does not require the expansion to get.

(Features which would be used exclusively by the expansion, of course, would require the purchase of the expansion, but bot behavior does not strike me as being this.)

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

I believe it's the fact that for some bases you could potentially have these extra calculations being performed for thousands, if not 10s or 100s of thousands of bots that makes it UPS intensifying. And yes, I know the calculations you're talking about are not done every tick, but when you have several 100s of thousands of bots all flying around, you're going to get a large count of them per tick that'll need it.

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.

I'm having a hard time visualizing such a scenario. The work zone must be in range of a roboport somewhere, so if it's out of range of the origin, then there will be another closer.

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!

It's not static, though. Any roboport at any given moment could be destroyed or deconstructed.

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?

I use primarily construction bots for automated repairs to defenses and (de)construction. For actual logistics, I prefer using belts and trains, myself.

[ryanalpasta]

I read through this post literally going "THANK THE FACTORY" after every update, y'all are very in-tune with what the community would want done. These fixes don't even seem hugely time-consuming to code, but they are Exactly what we'd want in every way, especially while conserving UPS. I'm having visions of actually not disabling my personal roboport after I get a network set up, which sounds lovely. Thanks for still putting so much work into all this, time to annoy more friends until they buy it to play with me )) Very much looking forward to the space update!!

[BicycleEater]

...

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

I believe it's the fact that for some bases you could potentially have these extra calculations being performed for thousands, if not 10s or 100s of thousands of bots that makes it UPS intensifying. And yes, I know the calculations you're talking about are not done every tick, but when you have several 100s of thousands of bots all flying around, you're going to get a large count of them per tick that'll need it.

Well, kind of. Those kinds of operations, done on numbers which must be in cache anyway (as the drone has to move anyway), would be blisteringly quick on a modern CPU - particularly since if Factorio really is memory bandwidth limited, since it doesn't involve any memory accesses.
Also, it would improve bot transfer rates by at least ~1/60th (ignoring recharge times, which are a major factor ofc, but it doesn't add any costs to bots which are recharging, so for the performance considerations we would only need to consider bots which are transporting stuff), simply due to pathing straight to the charging port, rather than starting midway through a now-pointless journey.
This is in the worst case for the change - that of a bot bouncing between two chests repeatedly. In cases of longer range flight (which require bots proportional to their range, so we would naturally expect long range bots out of proportion to the level of materials transferred).
And, as I said the change is deeply unlikely to take any substantial calculation power, as those are operations modern 64 bit CPUs take in stride, and even older CPUs are deeply optimised for. I don't know how many clock cycles the calculation would take, but that would be an appropriate measure for it - so the computer could cope with bot set-off counts like a million a second, or suchlike...

The reason I dislike the "it will impact UPS" argument so much is that it's a perfectly good argument against e.g. pathfinding, and I feel people often dismiss bot improvement suggestions which hope to improve pathing by assuming they're all pathfinding, and knowing the developers have (quite reasonably) dismissed pathfinding the robots, they dismiss an improvement on that basis without assessing how much UPS impact the change would have.

[SoShootMe]

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

I believe it's the fact that for some bases you could potentially have these extra calculations being performed for thousands, if not 10s or 100s of thousands of bots that makes it UPS intensifying. And yes, I know the calculations you're talking about are not done every tick, but when you have several 100s of thousands of bots all flying around, you're going to get a large count of them per tick that'll need it.

The extra calculation that BicycleEater didn't mention above is determining whether a charge will be necessary. I think this is the part that is actually relevant, because it isn't done now (or with the new behaviour) and I think a bit more than "like 4 multiply operations" (which are only necessary when the plan is to charge en route, and in any case minute compared to finding somewhere to charge). This calculation is not needed every tick so "several 100s of thousands of bots all flying around" perhaps means something like several thousand calculations per tick. That is not nothing and every little helps, but given the calculation uses data already "at hand" it doesn't sound significant compared to updating other entities (crafting machines, inserters, ...) for a factory with so many active robots.

There are many reasons that conclusion could be wrong, but I'm still not seeing one that leads me to think it probably is, except that it seems a relatively obvious improvement and therefore, if it were viable, would likely have been tried and judged to be too detrimental to performance.

[SteelWolf300]

I appreciate the possibility for requesting a minimum number of robots. May I suggest also adding the possibility for requesting a maximum number of robots, as for personal logistic? If more bots are stored in the roboport, they would be evicted and seek for an other roboport that have enough space.

personal-logistic-request.png (91.77 KiB) Viewed 3158 times

There are situations where I place roboports only for extending the reach of the bots, or for providing more charging points, and I wish I could prevent bots to settle into them. Setting the maximum number of robots to zero in these roboports would be a nice solution.

Typical situation is building a large solar array on the edge of my base, with multiple roboports ensuring that the array is easily expandable remotely. And when I expand the array, bots grab building materials from the base, build the blueprint, then just stay in the closest roboports, i.e. at the outer edge of my base. I just wish I could force those robots to come back to base, or any other location where there would be more useful being stored there.

Will the roboport robot requests be configurable with circuits?

As a fan of circuit networks, I like this other idea very much. I can't think of an easy way to have a min+max config that could be configured with circuits.
Maybe the green wire could configure the min, and the red wire could configure the max... but this might be too convoluted for factorio vanilla, where circuit networks components are usually color agnostic.

The "logistic request" on the roboport for robots is a godsend, will it work for repair packs too?

Nice thoughts by the way!

[pointa2b]

The "logistic request" on the roboport for robots is a godsend, will it work for repair packs too?

+1 for this. I get there are buffer chests and the value of strategically placing them, but repair backs go hand in hand with bots. After all, roboports natively hold them.

[Winnkys]

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?

Same, my first few playthroughs didnt use bots either as I felt it was kinda of cheating. But now I rush them. They are so handy for construction, repair and supply of the player. I still try and limit their use on supplying items to the network. That I still use belts and trains.

I suggest trying bots for construction and logic supply to the player. That way you keep the factory with belts and trains, but you get the oh so handy bots re-supplying you, saving you time, and building is so much quicker.

[nilsherzig]

wow very nice is this going to be available in the current game or only in combination with the big content update?

[BicycleEater]

...

I believe it's the fact that for some bases you could potentially have these extra calculations being performed for thousands, if not 10s or 100s of thousands of bots that makes it UPS intensifying. And yes, I know the calculations you're talking about are not done every tick, but when you have several 100s of thousands of bots all flying around, you're going to get a large count of them per tick that'll need it.

The extra calculation that BicycleEater didn't mention above is determining whether a charge will be necessary. I think this is the part that is actually relevant, because it isn't done now (or with the new behaviour) and I think a bit more than "like 4 multiply operations" (which are only necessary when the plan is to charge en route, and in any case minute compared to finding somewhere to charge). This calculation is not needed every tick so "several 100s of thousands of bots all flying around" perhaps means something like several thousand calculations per tick. That is not nothing and every little helps, but given the calculation uses data already "at hand" it doesn't sound significant compared to updating other entities (crafting machines, inserters, ...) for a factory with so many active robots.

There are many reasons that conclusion could be wrong, but I'm still not seeing one that leads me to think it probably is, except that it seems a relatively obvious improvement and therefore, if it were viable, would likely have been tried and judged to be too detrimental to performance.

The operations to find whether the charge distance is required only need:
The bot's location.
The target's location.
The bot's charge level.
The bot's energy usage per second (/frame).
The bot's energy usage per tile travelled.
The bot's speed (per second/frame?).
(I'm not sure that it doesn't already have energy per second, per meter, and speed combined into the net energy per second while moving, but it must calculate that to move the bot every frame, so we could just assume they're already combined).
It then takes:

Code: Select all

tileRange = charge / ((energyPerFrame)/(tilePerFrame)+energyPerTile)
tileRangeSquared = tileRange * tileRange
distanceToTravelSquared = (botLocation.x - targetLocation.x)^2 + (botLocation.y - targetLocation.y)^2

Then compare "distanceToTravelSquared" with "tileRangeSquared".
That's 2 divisions, 3 multplications, 4 additions/subtraction, no extra conditionals.

If you want to optimise it (depending on system and how well optimised reciprocal is), and were doing this alongside the normal movement code, you could do the following:

Code: Select all

deltaX = botLocation.x - targetLocation.x
deltaY = botLocation.y - targetLocation.y

(both of these would be needed in normal movement code anyway, presuming the robot doesn't then recharge, so this has near-zero cost)

Code: Select all

speedInv = 1/tilePerFrame
energyPerTileTotalInv = 1/(energyPerFrame*speedInv+energyPerTile)
tileRange = charge * energyPerTileTotalInv
tileRangeSquared = tileRange * tileRange
distanceToTravelSquared = deltaX * deltaX + deltaY * deltaY

Which is now 2 non-shared additions, 2 reciprocals (relatively quick, though I can't find any direct sources for cycle counts), and 5 multiplications.
I think my estimate was close enough, particularly since I'm working off the two types of energy usage individually, even though the game may cache a more useful form, which would either save a multiplication and an addition, or just an addition.

Counting approximate cycles, on double precision, this algorithm gives a count of ~72 cycles for the divisions, ~24 cycles for the multiplications, and ~20 cycles for the additions.
Rounding this to 120 cycles, it will take, at 4GHz, 30ns to complete these computations.
Now, if something to do with reciprocals was used instead, like my second example, the numbers would look more like:
40 cycles for the reciprocals, 40 cycles for multiplications, 10 cycles for the additions, rounding to 100 cycles. At 4GHz, this looks like 25ns per frame.
A drone seems to use ~140-190 ns/frame in the air anyway, so this adds about 1/8-1/4 of a frame's of computation to the cost of the drones. That's honestly more than I expected, but still isn't much overall. If each drone flies for at least 10 frames, (5 tiles at level 15 drone speed), this would be a 1/60 drop in performance.
At ranges of 10 tiles, even across speed, the savings to recharge time amount (depending on setup, but generally) to ~1/60th, by which point the drop in performance is down to 1/120th (that is, if your drones travel more than ~7 tiles on average, you'll gain more throughput than you lose UPS).

To more specifically address the 100s of thousands of bots. If they take ~200ns per bot per frame, that's like 20ms/frame, so maybe my numbers are off. Alternatively, if that's your limit on performance, and it's like 150ns, then that's 15ms/frame, so maybe?
Anyway, if your bots travel at least 7 tiles on average, the savings on recharge will be greater than the losses

Note that my throughput improvement figure I quoted previously does depend (linearly) on distance. At 10 tiles, its a 1/60th improvement, at 5 its a 1/120th.

For bot expenses I'm using viewtopic.php?f=204&t=108144
and for cycle counts I'm using http://www.phys.ufl.edu/~coldwell/Multi ... ntmult.htm

EDIT: I also realised that speed is a float, not a double, so one of the divisions could be way shorter - like 23 cycles, not 36, making a reasonable optimisation (not including the reciprocals) take ~100 cycles. Faster with some careful float usage, as precision isn't 100% necessary - if the drones slightly underestimate how far they can go (by less than a tile), it really doesn't matter, provided it is deterministic, which the errors would be.

[KaiserTom]

These are some nice changes. I'm curious though, how much these extra calculations (Flight time, etc) are going to effect UPS. Bots are cornerstones of megabases, and I can see this potentially really affecting UPS.

With the optimisation mentioned, it is basically the same as before.

Assuming you took a bot heavy megabase and compared the two UPS's to be equal after the optimization, that kinda implies the new code is performing marginally worse but the sheer improvement in bot network efficiency makes up for it, equalizing UPS in both. And probably improving it in some edge cases. Because I would, naively, expect a lot of these bot logic improvements to improve UPS just through less bots in flight overall. Especially the charging change is huge.

And don't knock the power of heuristics. It's not always perfect but it doesn't need to be, just better. Don't let perfect get in the way of better. Especially when performance is also critical if not more so.

Also I have to ask for an experimental release of vanilla just with these bot changes. I'm not holding my breath, but I have to ask for it anyways.

[KaiserTom]

...

Wouldn't it overall be easier to define the failure mode earlier like at 25% charge? Then robots caught over no coverage would pick a port, still towards the destination and maybe even at the destination, and fly quickly towards it with charge for at least most of the way. Rather than only triggering at 0% charge and slowly flying to the nearest. You could even have an extra check so it only triggers that failure at 25% when the robot is currently out of coverage. But I feel like this doesn't noticeable impact on in coverage bots as they would just path basically as normal anyways because the new charging algorithm puts them at or close to their destination as is.

Define it as a "reserve energy" variable that we can set, in or out of network. This would also help certain mods that provide logistics coverage without charging ports, as they face similar issues to the bots over lakes problem.

[widders]

Given the new 'goto roboport" task to restock, in the travel routing could you...
if travel distance > remaining charge
calculate a roboport on route but within range
insert charge at x roboport at the top of the queue

Then robots would jump charge to charge rather than having to work that out repeatedly after running out of charge and holding up charging slots while flying on low power

It puts the UPS cost up front and the distance vs charge calculation would be needed pretty often but you would also see less flying out into void and having to fly back over and over that might justify it if they reduce number of times flying back from the void