Logistics bot cargo should count as contents of network.

[ribsngibs]

It would be nice if cargo carried by a logistics bot was counted as belonging to the appropriate logistics network depending on bot delivery target.

Reason: A very common construction is an inserter hooked up to the logistics network (pulling from a train or assembler into a provider chest) which either activates or sets filters depending on the contents on the logistics network. e.g., "Pull repair packs out of cargo wagon if logistics network has repair pack < 200" or "pull express belt out of assembler if logistics network has express belt < 500". I personally like to insert these items into active providers such that the items are then relocated to a central storage location. Unfortunately, while items in the active provider count as being in the logistics network, items *after* they are picked up by the bot but *before* they are deposited in the storage chests do not count as being in the logistics network. This means that I always end up with more items than I want in the logistics network, depending on bot travel time.

e.g.: I want 50 turrets, but currently only have 40.

• Inserter activates
• Inserters pull turrets out of an assembler into an active provider, until the active provider has 10 (or 12) turrets in it, bringing the logistics network inventory to 50 or 52 turrets.
• Inserter deactivates.
• 3 logistics bots grab the 10 or 12 turrets out of active provider
• logistics network now reports only 40 turrets again, so inserter reactivates
• inserters deposit another 10 or 12 turrets into active providers, then turn off again
• more logistics bots grab the 10 or 12 new turrets out of active provider, which turns on inserter again
• cycle repeats until the first logistics bots finally deliver the turrets to the storage chests
• logistics network now reports 50 or 52 turrets, permanently deactivating inserters
• all logistics bots enroute finally arrive at storage chests
• storage chests now have 60, 70, 80, or more turrets, depending on bot travel distance, far more than the number I actually wanted.

It would be nice if the cargo of the logistics bots behaved thusly: if the destination of the logistics bot is in the logistics network (storage chest), then that cargo should count as belonging to logistics network inventory. If the destination of the bot is not (requester chest, personal inventory), then the cargo should not count as logistics network inventory. The same should also apply to construction bots - if the destination of the bot is in the logistics network (storage chest after deconstruction), the cargo should count as belonging to the network inventory.

[Optera]

Active providers are the devil. Unload into supply chests instead, they will get emptied before passive providers.
I use active provider only to unload unwanted items from supply trains e.g. wood,stone

[Deadly-Bagel]

Active providers are useful if you have a huge factory making items all over the place. Put a bunch of storage chests in the area closest to where you are likely to enter logistic range and you'll have a much faster response time in receiving the items.

But I agree, if the bots' inventory counted in the network it would make things a lot simpler and more accurate.

[Optera]

You can't decide which storage chest will be used. Unless you have a simple and reliable way to ensure at least 1 item remains in the storage chest, bots will happily take out the last item and then proceed to fill the closest storage chest with newly produced items.

I produce in passive provider (sometimes into storage chests with circuit network controlled inserters to ensure said minimum item level), have a centralized storage area and simply increased buffers of requester chests.
I toyed around with magazine loader from this thread viewtopic.php?f=8&t=28268&hilit=smart+loader, but it was to restrictive to be useful.

If you play with vanilla bot speed on a huge megabase, you may want to break up your logistic network into smaller parts and use something like this to connect them.
Top network is the one with storage. Bottom one may not have any other storage chests for it to work.

20160315102842_1.jpg (750.39 KiB) Viewed 7192 times

[ribsngibs]

This is all kind of unrelated to the actual suggestion, which was simply "the destination of a bot should dictate the logistics network's ownership of the bot cargo."

I am building large bases, and I do use those little inserter bridges between robo networks in a lot of areas. That being said, I prefer active providers at the ends of all my production chains, and a single large grid of storage chests in the "center" of my base. All items are produced and then immediately sent to the central storage location. This is nice because I can put all my train loading stations near the central storage cache, where very large spikes in requests can be handled with short travel distance (I don't mind if 5-10 rail per second need to go from the active provider at the end of some assemblers by bot a very long distance to the central storage chests, because that only eats up a few tens of bots, but when a construction train comes in and sucks up 1000 rail all at once, it's nice to have 250 bots blitz the stuff over all at once a very short distance instead of clogging up all the roboports' charging slots for 2 minutes).

Another nice thing about production->inserter->activeprovider->bot->storagechest is that it allows you to place little "logistics stashes" around your (large) logistics network. A "logistic stash" is just a requester->inserter->passiveprovider for things you may wish to have spread around your base, like, for instance, repair packs, replacement turrets, or maybe your want a bunch of belts/rail for construction. Normally, if you put requester->inserter->passive pairs, what happens in the requester gets a few repair packs, the inserter puts it into the passive provider, and then a bot immediately picks the repair pack up from that passive and dumps it right back in the requester, and the bots churn forever, rendering the setup completely useless. However, if you use active providers and storage chests for your production chains, the requester->inserter->provider pair actually works as designed, since *logistics bots* prioritize picking up from active and storage chests first, whereas construction bots do not. Therefore, logistics bots will travel a very long distance to fill up the requester chest, while the construction bots will happily take the closest available repair pack.

Anyway, as I said, this discussion isn't really relevant to the actual suggestion, which is that if a bot is in the process of delivering an item to a chest, then for the purposes of the "logistics network contents", that item should count as belonging to that logistics network.

[Optera]

Another nice thing about production->inserter->activeprovider->bot->storagechest is that it allows you to place little "logistics stashes" around your (large) logistics network. A "logistic stash" is just a requester->inserter->passiveprovider for things you may wish to have spread around your base, like, for instance, repair packs, replacement turrets, or maybe your want a bunch of belts/rail for construction. Normally, if you put requester->inserter->passive pairs, what happens in the requester gets a few repair packs, the inserter puts it into the passive provider, and then a bot immediately picks the repair pack up from that passive and dumps it right back in the requester, and the bots churn forever, rendering the setup completely useless. However, if you use active providers and storage chests for your production chains, the requester->inserter->provider pair actually works as designed, since *logistics bots* prioritize picking up from active and storage chests first, whereas construction bots do not. Therefore, logistics bots will travel a very long distance to fill up the requester chest, while the construction bots will happily take the closest available repair pack.

That's simply wrong. Logistics and construction bots use the same priorities which are active provider > storage chest > passive provider.
If you want repair packs taken from anywhere else than storage chests you have to use requester->roboport. They will use repair packs from those before storage.

[Deadly-Bagel]

If you want repair packs taken from anywhere else than storage chests you have to use requester->roboport. They will use repair packs from those before storage.

You might run into your own issues if a robot takes a pack out of the roboport, the stock is refilled, then the robot finishes its task and goes to drop the packs off again. No room in the roboport so it either has to drop them in another one or take it to storage.

A simple solution that takes a bit of setup but should work:

Put storage chests everywhere you want to distribute, limit to 2 stacks. Put one repair pack in each one initially. On your repair pack production limit to (# of chests) * 200 - 20 on the logistic system.

Rules:

• Ensure no logistic request is equal to or greater than 200 (or as many as you put in one chest)
• Production must be faster than consumption
• Ideally have spare general storage at all times

What should happen is your logistics bots will prefer the storage chests with repair packs already in them, when a chest reaches two stacks it is considered full so additional packs will be distributed elsewhere. You need to ensure it doesn't completely fill up because I often find I limit items to 200 in the logistic network and I get 204, meaning these extra packs would be moved to your general storage and it would fill up there instead. This is why you subtract 20 from number in network.

This means no chest should be less than 180 repair packs (or 18,000 hp). If you've got an area that could possibly go through this number before being restocked (doubtful) you may want to put another stack in there (add 100 to production limit) or add a closer production of repair packs.

[ribsngibs]

Another nice thing about production->inserter->activeprovider->bot->storagechest is that it allows you to place little "logistics stashes" around your (large) logistics network. A "logistic stash" is just a requester->inserter->passiveprovider for things you may wish to have spread around your base, like, for instance, repair packs, replacement turrets, or maybe your want a bunch of belts/rail for construction. Normally, if you put requester->inserter->passive pairs, what happens in the requester gets a few repair packs, the inserter puts it into the passive provider, and then a bot immediately picks the repair pack up from that passive and dumps it right back in the requester, and the bots churn forever, rendering the setup completely useless. However, if you use active providers and storage chests for your production chains, the requester->inserter->provider pair actually works as designed, since *logistics bots* prioritize picking up from active and storage chests first, whereas construction bots do not. Therefore, logistics bots will travel a very long distance to fill up the requester chest, while the construction bots will happily take the closest available repair pack.

That's simply wrong. Logistics and construction bots use the same priorities which are active provider > storage chest > passive provider.
If you want repair packs taken from anywhere else than storage chests you have to use requester->roboport. They will use repair packs from those before storage.

My experience has been different. Actually, I will retract the thing about repair packs in particular - I haven't tested that very thoroughly. However, I have often used requester->inserters->passive stashes to bringf very large quantities of belts and splitters and pipes and assemblers and other building materials, far, far from my central storage chest array, close to where I will build a big thing, and when I tell construction bots to build a giant blueprint, they will indeed grab the belts and assemblers and poles and inserters from the very close passive provider stash, while the logistics bots go back to the main storage chest array and refill the stash. This is with all chests in the same robonetwork, not a separate network with inserter bridges.

[ddidderr]

TL;DR

The contents of what bots are currently carrying are missing in the logistic network contents (i.e. when you add a Roboport to circuit network). Please add that.

Why?

Currently the logistic network content signals contain only the amounts of items residing in logisitc chests. Once a logistic robot takes that item it is already missing from the total amounts. Which is in my opinion not correct since a logistic robot belongs to the logistic network and hence the item should still count as "within" the network. This has some implications when you try to achieve specific item transfers with circuitry. The missing items (while bots carry them from chest to chest) impact the total amounts.

[Koub]

[Koub] Merged into older same suggestion

[impetus maximus]

Active providers are the devil. Unload into supply chests instead, they will get emptied before passive providers.

then you have to wait for the bots to fly all over to re-supply you. having active providers, then storage in one place makes re-supplying SO much faster.

+1 for bots doing work to count toward the logistic count.

[gGeorg]

[0.17.63] Logi-bot loaded item is substracted from the logi network

When logi bot load an item, it is temporary removed from the logistic network. When bot land, item is added back to the network.
It causes issues when you try setup precise logistic chain, or demand based chains, or any supply model where you count items.

Example:
Outpost station supplyed by train.
10 ammo is delivered as reqested.
3 logibots start to move ammo from train unload area storage chest to a buffer chest
10 ammo dissapear from the outpost logistic network (logi-bot wrong mechanic)
new reqest is sent
10 ammo is deliverd to buffer chest (ammo is added back to the system,logi-bot wrong mechanic )
10 new ammo is deliverd to outpost by train
Total Outpost ammo is 20pcs.

It is just example. In case of dozens of bots, unpredictable fluctuation of items basicaly prevents any smart supply chain system. I have in mind a discrete isles of logi networks sending requests. Like outposts, atomic power plant, and so on.

Recomendation:
Items in the logistic robots should be considered as part of the network. Same as items on belts.
Items in the construction robots should be considered same as requester chest, or machine's inside incoming chest - e.g. consumed, out of system.
Current status is Ok for construction bot, and is not OK for logi bot.

[Bilka]

None of what you describe is a bug. You don't even use that word so you also seem to be aware of that. Moving to ideas and suggestions.

[gGeorg]

Thank you for quick response.

Edge between bug, intentional behaviour, and accident behaviour is questionable.

Personaly dont care classification, just make it work, ok ?

[Koub]

[Koub] Merged topic into older one with the same suggestion.

[User_Name2]

Any workarounds?

[robot256]

The workaround is to build a realistic logistic system with buffers in place to achieve a goal. If the outpost has 10 ammo left, send the train to deliver 200. It will not request another train for a while, even if some are in logi bots. Use active/passive/storage/buffer chests to control the priority of which items get used first.

[Skjolbir]

The workaround is to build a realistic logistic system with buffers in place to achieve a goal. If the outpost has 10 ammo left, send the train to deliver 200. It will not request another train for a while, even if some are in logi bots. Use active/passive/storage/buffer chests to control the priority of which items get used first.

Big eh solution. I wish roboports output signals for expected items en-route as well as items immediately available in the network. That way, if you want to include items carried by bots, you can just add the two signals together to get an accurate expectation of available items once the bots have done their job. Making guesswork of it seems very anti-factorio to me, where I can calculate exact production requirements if I want X number of items produced a second (Science Per Minute for example).

[ssilk]

I don’t think that it makes sense to change this. Because it makes a lot of sense how it works now and is also the way, how it works in reality.

To explain that: Imagine I’m in a storage and my job is to bring articles from a to b. There is also a computer with a printer, which prints out a sheet of paper which tells me what to do.

The problem is now: there are these two systems: the storage with the real number of articles in it and the computer with the number that might be correct, if everything is done, as he orders. One of the systems lies to you.

It’s the computer of course, because reality cannot lie.

The same in Factorio: if a robot is ordered to pickup an item many things can happen. The simplest case would be: he runs into a biter nest or into a burning forest and is killed. Item lost.
Or think to the personal roboport: you order items and the robots bring it. With the proposed logic, the items disappear, when the robots put it into inventory. Feels totally wrong. Much more logic behavior is to count, when the robot is ordered to bring it, because that saves much time.

All in all I think this would slow down many processes in Factorio, because you begin producing after the order is fulfilled. To prevent these cases we could use circuits to calculate need by a threshold or with a timer.

But all of that points to some lacks in the logistic network:

Ability to read more than the current contents of the logistic network

There is the roboport which can provide us with the network content numbers. But that seems to be not enough.

Edit: there is this thread where we we discussed things like that:

I think it is important to have different outputs:
- Items in providers (storage, active, passive) are already supported...
- Missing in logistic network requester chests.
- Missing for construction (ghosts). Deconstructed items count negative.
- Missing for personal request slots. Items in trash slot count negative.
- Items loaded into logistic robots/"on the way"
- Items loaded into construction robots/"on the way"
- Items on belts.
- Items in inserter hands.
- Items in devices input.
- Items in devices output.
- Items on ground.
- Immoveable entities on ground (devices, trees).
- Moveable entities (Player, Enemies, Vehicles).
- Resources on ground.
…

Of course not all are useful at any time and needs to be calculated every tick. But there are more ideas in that thread.

But I cannot explain how important this is, because it would enable so many useful new ways to play! Especially if we would know the current needs of a network (logistic and construction), we could use trains to bring the items to the network. We would not need to make one gigantic network.

Instead we could sum up all needs and produce exactly as much, as is needed.

There are some threads about that subjects:

First the already quoted
viewtopic.php?f=6&t=39474 Roboports should output missing materials to circuit network / Roboports emit signals with missing blueprint items

It seems there had already been made some attempts to implement this, but seems to be harder than thought: viewtopic.php?p=179723#p179723
Taken from viewtopic.php?f=6&t=28325 Roboport option to output construction needs

Somehow related, because the logistic is dependent on these two factors: how much to transport and how many robots do I have to do this.
viewtopic.php?f=6&t=95894 Additional data point for Roboport
viewtopic.php?f=6&t=93355 Output more bot stats from roboport circuit network: charging bots and waiting to charge bots


There is also a mod that need to be mentioned https://mods.factorio.com/mod/GhostScanner

Read directly from the logistic network

Inserter already can do this: read the contents of one item in the network. Why can we not use that in the circuit network? Yes, we can use the roboport, but what we need is just one single signal out of some dozens.

We should be able to use that one number in the circuit network to do some more calculations. For example to calculate some threshold. Production begins when there is less than 20 and stops above 50. Or begin producing, if the number is too low for 2 minutes…

Roboports could order robots

There are already some suggestions around that:
viewtopic.php?f=6&t=6981 Ordering docked bots
viewtopic.php?f=6&t=67650 Roboport like a Provider/Requester chest for bots/tools

The basic idea is simple: you can set the number of bots, that should park in that roboport. So it works like a supplier chest for bots.

This can be very handy. You can for example order construction bots back from the front, so that they don’t get hurt, because you made their path to that fight longer, and so the fight/fire might be over, when they arrive, see
viewtopic.php?f=6&t=99838 Can we please make constructions bots avoid fire?
This would be a valid solution to that.


These three things would enable a lot of new gameplay without disabling the current.