Factorio Forums

See
https://mods.factorio.com/mod/GhostScanner

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

Same suggestion as this one: 39474

TL;DR

Roboport should have option to emit:

• Missing elements for the blueprint in the network's range.
• Logistic requests that can't be fulfilled from network inventory

What ?

We have mods like GhostScanner (scans ghosts, outputs parts of the ghosts) who fulfill it partially but it comes at hefty UPS cost and apparently any changes that would make it easier for mods to implement would be pretty save-corruption-prone:

viewtopic.php?f=221&t=74375
viewtopic.php?f=28&t=72794&p=439955#p440157

As for logistic requests we kinda already have half-working version of it when some of the logistic network summary will go to small negative value if one of the items have requests but no inventory to fill. Expanding it so it shows actual value (if something requests 1000 but there is 0 in the network it should signal -1000) would allow to build stations that "order what they need" automatically, without player having to set up much.

Why ?

Especially in modded playthrus the ghost info would reduce the tedium of packing every single needed thing on train or rocket as the "outpost" could just signal what it needs and then the player is left only with the interesting part of setting their train/rocket/whatever else network to deliver the goods. Currently available mod kinda get too slow once you get to the part where you could really use that functionality (multiple outposts/planets in case of SE)

@OP : This suggestion seems similar (in what it tries to achieve) to this one : viewtopic.php?f=6&t=55502
Do you agree, or did I misunderstand something ?

merged with existing topic

@Koub: The magic word to find this is “ghostscanner”.

Still needed. There is no way (that I know of) to read ghosts into a signal, without mods at least.

When you follow the thread you’ll see, that this will not very likely to be added, because it adds a bunch of extra cycles (*) to the cpu only for players like you and me, that eventually use this feature.

(*) the problem is, that the roboports overlap on construction range. So it is not just adding an extra list “roboport -> constructions within this roboport”. This would add constructions, that exists in two or more roboports, you would count them twice or more and need to filter out those doublettes afterwards. And the overlapping can change every tick (no power, (de)constructed roboport, etc.).

The game solves this problem currently by going through all chunks step by step and count the items within that chunk that needs construction. You can see that by making very big constructions.

IMHO this is a hard (mathematical) problem to solve this count in a way that is O(1) or lower. And I really don’t think it will be added before this basic problem is solved.

TL;DR:
placed, unconstructable ghosts can be read to the logistic network through roboports in range of that ghost

What?
I propose a new "ghost-[entity-name]" signal class for the circuit network. This signal class would be used by roboports to automatically report all ghosts within their range that cannot be constructed.

This means that if a player were to, say, place a rocket silo ghost, then run a wire from a roboport to any valid entity, that entity would recieve the signal "ghost-rocket silo" at a value of 1. These signals could be used by the circuit network in the normal way.

It might be useful to give players control (via entity setting once connected) over whether each roboport only reads its own range, or whether roboport networks can merge their signals together.

Why?
The example I gave is why I want it. I want to be able to have an assembler which produces rocket silos, but only when one is needed (a ghost is present with the "cannot be constructed" warning). I can easily restrict the input belts, inserters, or power (dealer's choice) until a desired signal arrives; but, currently, there is no possible way to signal that a rocket silo is needed, so I can't do this at all.

I have been keeping up with friday facts and as far as I'm aware, this functionality has not been added.
This has probably been suggested before, but I couldn't find it when searching. Hopefully that doesn't mean it's been moved to "won't do"; or if it has, hopefully the devs will reconsider in the light of other logistic, ghost, and circuit related changes planned for 2.0

000 wrote: ↑

Mon Feb 05, 2024 2:45 pm

I propose a new "ghost-[entity-name]" signal class for the circuit network.

Wrong.
We don't want that. That will just give a lot of duplicate signals that we have to manually translate, a massive pain to deal with.
Just send "ghost" signal (any signal type we select) with count and the actual regular entity signals for each ghost type and their counts.

ssilk wrote: ↑

Fri Jan 28, 2022 6:39 am

(*) the problem is, that the roboports overlap on construction range. So it is not just adding an extra list “roboport -> constructions within this roboport”. This would add constructions, that exists in two or more roboports, you would count them twice or more and need to filter out those doublettes afterwards. And the overlapping can change every tick (no power, (de)constructed roboport, etc.).

Why not just not worry about that and let player design ingenuity handle it?

Yes, if a ghost is in two robot networks and you merge the signals from those networks you'll double-count those ghosts. So what? There's no way to know which network the player wants the signal to be in anyway.

We just want ghost combinator as another option on roboports.

Illiander42 wrote: ↑

Tue Feb 06, 2024 8:54 am

Why not just not worry about that and let player design ingenuity handle it?

We just want ghost combinator as another option on roboports.

The scanner for Recursive Blueprints+ provides a solution I think is superior. It can do any area (up to a max size), anywhere. And it can be configured with signals in many different ways to filter the output. And it doesn't affect UPS when not in use, it only scans for one tick when you tell it to.

You still get the issue of overlapping areas if you want to query an area that is very large or not rectangular so that you have to do multiple scans and entities larger than 1x1 then may overlap several non-overlapping scan regions. But you get way more control over where the scan regions are so you can often work around this with ease.

Qon wrote: ↑

Tue Feb 06, 2024 1:13 pm

The scanner for Recursive Blueprints+ provides a solution I think is superior. It can do any area (up to a max size), anywhere. And it can be configured with signals in many different ways to filter the output. And it doesn't affect UPS when not in use, it only scans for one tick when you tell it to.

You still get the issue of overlapping areas if you want to query an area that is very large or not rectangular so that you have to do multiple scans and entities larger than 1x1 then may overlap several non-overlapping scan regions. But you get way more control over where the scan regions are so you can often work around this with ease.

I'd be really happy if we got recursive blueprints in vanilla.

While roboport networks can overlap amd join and split every tick this doesn't seem to be a problem for assigning construction bots or for displaying the "ghosts missing items" alert at the bottom of the screen. That alert is already generated and counts missing items, even doing so for multiple surfaces separately.

So the only thing that seems to be missing would be associating the missing items to specific roboport networks. It's true that those networks can overlap so a missing item might be missing in multiple networks. Should this be added to every roboport network that covers the item or just one of them? I don't really care but adding it to every network is probably the better solution. Better to over supply than to end up missing an items because the network the missing item gets reported to doesn't produce said item. But if the code only allows reporting an item to one network then so be it. Overlapping construction networks that supply different items and where you only produce missing items without any buffer will be very rare. I wouldn't consider that a game ending limitation.

Similary the missing items alert only shows items where a construction bots would be available and only shows the last 600 items searched. That is a llimitation but again does it matter? If you use the new "missing" signal and produce or ship in the 600 missing items then the next 600 missing items will pop up and everything will get build eventually. If you are producing items you probably can't produce them faster than the count refreshes anyway. I only see that as an inconvenience for trains, where more than the 600 missing items would fit in a single train. In such a case I would probably add some logic that if solar panels are missing then order a whole cargo wagon of solar panels, not just the reported count. Or some other useful multiplier or rounding up.

My use case for this signal would be more for repairs or small numbers of items. If the aliens destroy an accumulator at some outpost then I need to ship in a replacement via train. This shouldn't happen but sometimes things go wrong. Not often enough to keep a spare of everything on hand in every outpost. A missing items signal would be invaluable there. On the other hand if I blueprint a new mining outpost from scratch I know I need 300 miners and a ton of belts. So just bring a lot of those and then use the signal to order the 43 missing power poles or 5 rail signals or whatever small stuff.

TL;DR
Add a checkbox that enables a Roboport to output a circuit signal of either a list of needed entities to complete construction or as a boolean to simply indicate a roboport is missing entities for construction.

What?
I see one of two options to be added to the roboport's Circuit connection panel.
"Light Version" - Add a checkbox (e.g. "Output network needs entities for construction") that enables the roboport to output a boolean for if it has entity construction orders to fulfill (i.e. there are no entities available to replace ghosts). E.g. G=1 for when there are ghosts with no entities to fulfill the order or G=0 when there are sufficient entities to fulfill the order.

"Detailed Version" - The "Circuit connection" panel in the roboport currently has a checkbox to "Read logistic network contents." This outputs an exhaustive list of all the available items in the network's storage. This list is outputted to the RED channels. I propose that a "Read construction ghosts lacking entities" checkbox be added that outputs a list of needed entities to complete all construction orders in the roboport's network.

Why?
This provides the player with the ability to create detailed requests for certain activities, such as logistics train networks. For example, a train would only deliver items if there are ghosts without entities to fulfill orders.

The player already receives alerts for this as well, but has little capacity to automate these construction requests beyond directly feeding the network's storage with manual provisions. Therefore, the roboport seems to know exactly what it needs, yet also seems to have a capacity to alert a circuit network to this request but does not make these requests known (offloading the alert to the engineer).

This would not outright solve any issues, but it would provide players with needed tools to automate challenging problems that were previously not possible to automate.

Sounds a lot like this suggestion: viewtopic.php?f=6&t=39474&start=120

Yes, having roboports also be ghost combinator would be really nice.