Factorio Forums

ssilk wrote: ↑

Fri Mar 08, 2019 4:48 pm

Including items, that roboports are already carrying: I think that should be optional. In most cases this is useful, but think of items carried by construction robots could also mean, that they currently destruct something.

See this post: viewtopic.php?f=6&t=39474#p251107

Well yes, I meant explicitly only robots carrying something, or planning to carry something, to a ghost, item proxy, or upgrade in that construction zone, and it seems essential for practical use.


Lets take for example:

1. There is a logistics network with passive provider chest at the edge of the network. Next to it in another network is a requester chest, and an inserter in between. There are no construction bots yet.
2. The inserter is wired to read its contents, and connected with a roboport in the first network set to "Read logistics network contents".
3. This then goes into an arithmetic combinator set to "each = each * -1".
4. The combinator output and a "construction materials" output is connected to the requester chest to set the request.
5. The player places a blueprint for 50 transport belts.
6. The construction materials signals get set to 50 transport belts, as does the requester chest (50 + 0*-1).
7. The transport belts get delivered, and as they are the "Read logistics network contents" increases and the requester chest reaches 0 (50 + 50*-1). All good so far.
8. 50 construction bots are placed in the roboport.
9. These construction bots immediately start heading to the passive provider to construct the blueprint.
10. The "Read logistics network contents" immediately outputs 0, while the "construction materials" remains at 50.
11. Another 50 extra, unneeded, unwanted items are added to the requester chest.

So without a way to account for those construction bots, you will end up requesting approximately double of what was needed.

So what you really want is not the number of ghosts, but the number of unfulfilled construction requests.

ssilk wrote: ↑

Sat Mar 09, 2019 3:17 pm

So what you really want is not the number of ghosts, but the number of unfulfilled construction requests.

That sounds like it would just be an integer number.
While that would at least allow skipping over cells without ghosts I would like for LogisticCell to contain lists for ghosts, tile-ghosts and item-request-proxies

MeduSalem wrote: ↑

Mon Mar 05, 2018 11:54 pm

Gah... so many overcomplicated proposed solutions in this thread.

Just add another radio button and be done with it.

roboport1.png

This please. It would be nice to wire up a roboport this way and add the signal where needed.

Btw i came up with a solution, almost. But you still have to prefetch mats

viewtopic.php?f=193&t=66884

+1. Intricacies of internal implementation aside, it feels like a gross oversight that logistics networks can fulfill construction requests, but somehow cannot report how many remain unfulfilled within their range.

As for the "why bother", I'd like to add that an important distinction between stockpiling and requesting on demand is the ability to deny said requests. If, as is currently the case, a stockpile is necessary, there is no way to detect a need for something without having supplied it. However, for defense-related applications especially, I'd like to be able to have circuits keep track of unfulfilled requests while bots are grounded due to suspended supply.

Everyone's talking about ghosts and construction. What about logistics requests? That's what I'm interested in. I want my fluids plant to be able to request iron plates from my forge as needed and use LTN to automatically fill the demand.

JadedDragoon wrote: ↑

Wed May 22, 2019 10:08 pm

Everyone's talking about ghosts and construction. What about logistics requests? That's what I'm interested in. I want my fluids plant to be able to request iron plates from my forge as needed and use LTN to automatically fill the demand.

It has been mentioned. And we do want it. But typically the logistics demand from a station is constant in what is needed and constant at the rate it is needed. And there's also typically just a handfull of items that are needed (if you have dedicated production outposts and similar) so you can even have 1 station/item type. It's often easy to set up because of this and you can't get too much of things because everything is going to be used up eventually if the factory outposts keeps running.

Construction is different because what you want requested depends on what blueprints you place so any entity in the game might be requested and each outpost needs a large subset of all the item types, but you then want to avoid storing all non-used item types at an outpost that will never use them and send materials to another outpost instead. And setting up constant combinators for each blueprint is a lot of boring work.

I might be late to the discussion here, but doesnt the game already have a concept of a list of missing construction items?
The alert you get when there are missing items for construction shows which items are missing. Granted, this list varies and is limited by the number of active build requests, but being able to get that signal on a wire would be a basic start.

Qon wrote: ↑

Wed May 22, 2019 10:48 pm

JadedDragoon wrote: ↑

Wed May 22, 2019 10:08 pm

Everyone's talking about ghosts and construction. What about logistics requests? That's what I'm interested in. I want my fluids plant to be able to request iron plates from my forge as needed and use LTN to automatically fill the demand.

It has been mentioned. And we do want it. But typically the logistics demand from a station is constant in what is needed and constant at the rate it is needed. And there's also typically just a handfull of items that are needed (if you have dedicated production outposts and similar) so you can even have 1 station/item type. It's often easy to set up because of this and you can't get too much of things because everything is going to be used up eventually if the factory outposts keeps running.

Construction is different because what you want requested depends on what blueprints you place so any entity in the game might be requested and each outpost needs a large subset of all the item types, but you then want to avoid storing all non-used item types at an outpost that will never use them and send materials to another outpost instead. And setting up constant combinators for each blueprint is a lot of boring work.

The numbers for construction change with every entity build. When you ghost a nuclear reactor you want to request one. You don't want to request a second when the first one is placed (or in transit by bot). Not so with logistic requests. You need iron plates, you estimate requesting 1000 plates at a time will keep up with demand so you place your LTN station to request 2000 plates in 1000 plate lots and dump them into a provider chest. Done.

Also, correct me if I'm mistaken, but the roboport already outputs the logistic counts. Place one next to your LTN station and connect the roboport with the lamp of the LTN station. Adjust the requester limit and you should be done for a fully dynamic setup.

mrvn wrote: ↑

Thu May 23, 2019 9:39 am

Also, correct me if I'm mistaken, but the roboport already outputs the logistic counts. Place one next to your LTN station and connect the roboport with the lamp of the LTN station. Adjust the requester limit and you should be done for a fully dynamic setup.

The point was that roboports can give us the logistics networks available contents but not the requests. The suggestion was to be able to read the requests too so you wouldn't have to manually "adjust the requester limit" on a constant combinator.

And the first part is just you restating what I wrote so I won't respond to that.

Qon wrote: ↑

Thu May 23, 2019 11:02 am

mrvn wrote: ↑

Thu May 23, 2019 9:39 am

Also, correct me if I'm mistaken, but the roboport already outputs the logistic counts. Place one next to your LTN station and connect the roboport with the lamp of the LTN station. Adjust the requester limit and you should be done for a fully dynamic setup.

The point was that roboports can give us the logistics networks available contents but not the requests. The suggestion was to be able to read the requests too so you wouldn't have to manually "adjust the requester limit" on a constant combinator.

And the first part is just you restating what I wrote so I won't respond to that.

Iirc the signals output by the roboport are inventory minus requests. So if you request more than available the number becomes negative. Haven't use that in ages but that is what I remember. Am I wrong?

mrvn wrote: ↑

Thu May 23, 2019 11:20 am

Iirc the signals output by the roboport are inventory minus requests. So if you request more than available the number becomes negative. Haven't use that in ages but that is what I remember. Am I wrong?

Yes, you are wrong.

It's possible for logistics statistics to be negative, but that does not reflect the total outstanding requests. I tried requesting 5 pistols (of which there was unsurprisingly only 1 in my system), and saw a pistol signal of -1 while the assigned logibot floated to the one available. As soon as the bot grabbed it, the pistol signal went to 0. My bot carrying capacity at the time was 2.

Theikkru wrote: ↑

Thu May 23, 2019 5:39 pm

It's possible for logistics statistics to be negative, but that does not reflect the total outstanding requests. I tried requesting 5 pistols (of which there was unsurprisingly only 1 in my system), and saw a pistol signal of -1 while the assigned logibot floated to the one available. As soon as the bot grabbed it, the pistol signal went to 0. My bot carrying capacity at the time was 2.

yeah but the negative number has nothing to do eith the amount requested in chests. Only shows negative because bots are trying to pick up morethan exists.

mrvn wrote: ↑

Thu May 23, 2019 9:39 am

Qon wrote: ↑

Wed May 22, 2019 10:48 pm

JadedDragoon wrote: ↑

Wed May 22, 2019 10:08 pm

Everyone's talking about ghosts and construction. What about logistics requests? That's what I'm interested in. I want my fluids plant to be able to request iron plates from my forge as needed and use LTN to automatically fill the demand.

It has been mentioned. And we do want it. But typically the logistics demand from a station is constant in what is needed and constant at the rate it is needed. And there's also typically just a handfull of items that are needed (if you have dedicated production outposts and similar) so you can even have 1 station/item type. It's often easy to set up because of this and you can't get too much of things because everything is going to be used up eventually if the factory outposts keeps running.

Construction is different because what you want requested depends on what blueprints you place so any entity in the game might be requested and each outpost needs a large subset of all the item types, but you then want to avoid storing all non-used item types at an outpost that will never use them and send materials to another outpost instead. And setting up constant combinators for each blueprint is a lot of boring work.

The numbers for construction change with every entity build. When you ghost a nuclear reactor you want to request one. You don't want to request a second when the first one is placed (or in transit by bot). Not so with logistic requests. You need iron plates, you estimate requesting 1000 plates at a time will keep up with demand so you place your LTN station to request 2000 plates in 1000 plate lots and dump them into a provider chest. Done.

Also, correct me if I'm mistaken, but the roboport already outputs the logistic counts. Place one next to your LTN station and connect the roboport with the lamp of the LTN station. Adjust the requester limit and you should be done for a fully dynamic setup.

@Qon

My personal logistics requests are _not_ constant. And when I set down a new set of assemblers both the items needed for construction and the rate at which that section of the factory consumes materials changes. Even the number of bots needed to service requests increases slightly. Setting up and updating the constant combinators each and every time is also a lot of boring work. And simply setting the innitial request to way more than you will ever need is wasteful and overloads the train network while building the initial buffer (unless you also build a train network with higher throughput than you actually need... again, a lot of extra work). An efficient design would dynamically adjust to the ~exact needs as they change.

Not being able to do this is why I've typically ignored trains and simply built a ridiculously over-engineered bot network (100k+ logistics bots, hundreds of roboports along major routes around my base). I also tend to claim a large area of the map and spread my base out simply so i'm not constantly tearing down and moving segments of my base to make room for new stuff... so that's a LOT of ground for a bot network to cover. Ideally trains would handle transport between sections of my base and the bots would handle transport within those sections.

LTN plugs itself by saying it reduces rolling inventory by XX%. Neato. Now that inventory is sitting around in buffers instead. For want of a nail, perfection denied.

@mrvn

Unfortunately, the roboports do not output requests. The negative numbers shown on circuits connected to roboports are an artifact of the way Factorio does math for bots capable of carrying more than a single item (presumably to reduce processing overhead). Angel's cargo bots are a good example since they can carry 100-500 items each. If you put down a chest requesting 110 rocket fuel, the minimum the Angel's cargo bots will try to deliver is 200... since each bot carries 100 and it will take two bots to fill the request. And if there are only 102 rocket fuels on the local bot network the roboport will show -98 rocketfuel (not -200) when you put the chest down (and the two needed bots are launched). It arrives at the -98 value because it needs two bots to fill the request and the second bot can carry 98 more than is available for that specific bot to pick up (after all other bots have "designated" what they are going to pickup as well). The -98 will also disappear from the roboport when the last bot picks up two rocket fuels. Vanilla bots do the same thing once they are upgraded with a cargo capacity greater than one... just the values of the negatives are smaller (ie -2 vs -98).

Needless to say, this particular value is nearly useless from an automation perspective. Most significantly because I wanted 110 items... not 200. And because it's not 200 minus 110 but 200 minus 102 (the hypothetical "amount available"). Thus it tells me nothing about the actual requested values or the values of unfulfilled requests... not even indirectly. Not even if I worked some circuit magic on the available numbers. Which is why I assume the presence of these negative numbers are artifacts of "close enough" math meant to keep the bots from being any more brutal to the computer the game is running on than they already are.

Right, I got those negative numbers confused.

What you can do it wire up big electric poles connected to the LTN station. Then when you place a new assembler you place a requester chest connected to a constant combinator and set it to "set request". Add an arithmetic combinator "each * -1 = each" connecting the constant combinator to the nearest big power pole. That way the programming of the chest also programs the LTN stop.

You could also set up the LTN stop telling it only what to request and have some circuit logic monitoring the rate of consumption to adjust the amount.

Personally I think such tight control of the amounts will be inefficient. You want a large requester limit so you don't have trains driving around with just 50 plates of iron. Anything below a full train is wasteful in the long run. And the size of train and how many to request in parallel is determined by the train station and not the logistic network demands. So basically the only thing you can tune is how low you let the buffer get before requesting another 8000 iron plates. E.g. my nuclear fuel cell setup requests -8200 iron plates with a requester limit of 8000. So At 200 iron plates a new train is started. For anything with throughput I use request = N * limit depending on buffer and stacker space.

While I think roboports reporting missing materials would be good I don't think it would be for requester/buffer chests programing LTN stops. It's more for one-time or very low throughput situations. E.g. building a blueprint.

As for personal logistic requests: Do I want LTN to send trains with random materials I request ever time I walk/drive through an area covered by a roboport connected to an TN stop? Certainly not. That would leave random items all over my base. That feels more like something where you have a blueprint for that you place when you need something and then remove again. Still, it would be cool if you could put down a LTN station blueprint and it would be pre-programed to request everything from your personal logistic requests. Something that a mod could do.

Would love to have support for this in the vanilla game! Are there any news on this since the last reply?

I'd love to see it in base game.
Until then my Ghost Scanner fixes all the problems of above mentioned ConstructionCombinator

There's multiple threads for this request which should probably be consolidated:
viewtopic.php?t=39474
viewtopic.php?t=48890
viewtopic.php?t=63238

Optera wrote: ↑

Sun Sep 08, 2019 7:33 pm

There's multiple threads for this request which should probably be consolidated

[Koub] Indeed, thank you for doing the search, never noticed this suggestion had so many separate threads.
Merged topics with the same suggestion.

Hi. It would be helpful if a roboport can send a signal to the circuit network stating missing items for construction. It already reports all missing items to you visually next to your hotbar.
You could use this signal to call a supply train to an defense outpost that has missing repair packs, construction bots, replacements for destroyed turrets, etc. The same example applies to outpost building trains where you place a blueprint and the train brings the items/bots to build that blueprint.

This idea came to me from my thread over here: viewtopic.php?f=18&t=83511&p=489083 where I asked if it is possible to combine logistics and circuitry.