Roboports should output missing materials to circuit network / Roboports emit signals with missing blueprint items

[MeduSalem]

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

Just add another radio button and be done with it.

roboport1.png (338.33 KiB) Viewed 7139 times

[steinio]

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

Just add another radio button and be done with it.

roboport1.png

Why only for construction? What's with logistic requests?

[mrvn]

I'll jump on this one and say this is a feature I would love too. It would make it possible to do on-demand production without excessive buffering everywhere (buffering in chests, buffering in cargo wagons, etc...)

I don't see why this is a good idea. It's not that hard to keep a small buffer on hand, have a resupply train that visits periodically, etc. Yes there will be buffering but it's easy enough to make the buffers small enough that that won't meaningfully affect the performance of a midgame factory. Perhaps if you supplied an example?

Why should I for example buffer storage tanks at every outpost I build? That would be just wasteful. Instead for those outposts that include a pumpjack I want the train network to deliver the right amount of storage tanks to build the train station and no more. And later, in case aliens attack and destroy a tank, I want to ship in a replacement as needed.

Everywhere where you have separate logistic networks it would be helpful to know what is missing so you can transfer it from where it is produced.

[MeduSalem]

Why only for construction? What's with logistic requests?

With "logistic requests"... do you mean the requests by the player?

Might be considerable.

[murderless]

it would be nice to have ability to read circuit signal for extimation of missing for construction items.

there are several dummy options:
1. signal for all requested construction items in construciton area for robonet (including items that are available)
2. signal for missing requested construction items for robonet (excluding items that are available)

such signal makes you able to build universal requester train station for building entities. that works for vanilla using wiring along rails or for modded run using LTN

[<NO_NAME>]

[Sad_Brother]

I would like it even if the signal would not full.

I mean if you marked to build a million of solar panels and get signal of one hundred missing... it's not a problem.

[Mike5000]

There's a great little mod for this: Missing Items Circuit

[mrzorn]

After two years or so and the release of 0.17 i would like to re-express my desire for a way to output the missing items within a Roboport-Network, with emphasis on the construction requests or more likely the not available items within the construction requests.

Be it a modifed Constant Combinator or an wired output directly out of the roboport

<3

[mrvn]

A problem might be that there is only a global list of ghosts and every tick one ghost is checked for buildability and a bot dispatched if possible. That's the reason why you have at most ~600 missing bots or construction material from the roboports (personal roboports add to that).

Given that implementation the circuit network would only show missing items if the ghost was probed in the last 10s (those 600 items).

Personally I think that would be better than no signal but the devs might not want to implement that.

[SyncViews]

A problem might be that there is only a global list of ghosts and every tick one ghost is checked for buildability and a bot dispatched if possible. That's the reason why you have at most ~600 missing bots or construction material from the roboports (personal roboports add to that).

Yeah, it definitely needs some thought. But I don't think any circuit output needs to be as complex as what the logistics manager does for routing bots.

The modding API does already have events for ghosts being placed/completed/removed, so something could maybe be mocked up to easily output the total ghost items, but I think there are some practical things on making a fully useful system given that information.

I had a concept, but it will almost certainly "over order" everything, because of some things I did not solve. The two basic things possible is a constant output of all ghosts, or a pulse when the ghost is first created. The constant output is fairly straight forward, a pulse could be more useful with cirucit memory/counters to avoid duplicates but has a lot more complexities I didn't think through.

Maybe that will be enough? You could certainly set it up to "trash" items back to the main base later, but it wastes potentially a huge amount of logistics capacity.

• While logistics chests are always in just one network, ghosts may be in multiple networks. Which network should the output be sent to? All of them? If all, then how does the player detect this, so as to not send a copy of everything to each? I don't think the games current "missing item" alerts deal with this either, as it is a global counter. I think this is also why the game doesn't update the alerts in realtime, but instead rate limits.
• What about personal or vehicle mobile roboports? Should these just be ignored entirely?
• Does anyone have a system that can reliably transfer N items from one network to another?
  
  Mostly I just use buffers, so not a problem I ever solved. On a quick look, there are some details like logistics bots taking items to a requester not being included in "Read logistic network contents"
  
  • "Read logistics network contents" doesn't include items construction bots are carrying or plan to pick up (still in provider chest). This means given that output of all the ghosts, and this roboport output, I couldn't account for what was already in progress.
  • On a similar note, the "Read logistics network contents" subtracts items logistics bots are planning to take to a requester chest.
  This made it difficult for me to work out how many extra items the network needed, and each network I needed to cross with a provider->requester circuit got several times more extra items due to inflight bots.
• Account for roboports/networks being built, destroyed, etc. This should effect the outputs, I think perfectly doable but makes the coding a lot less trivial. If using a "pulse" output, should it re-send the pulse?

[ssilk]

There is already a mod for that:
https://mods.factorio.com/mod/GhostScanner
and I also used this a long time
https://mods.factorio.com/mod/ConstructionSignaler
(but that made big lags when placing more than 1000 items)

But in my opinion both have the disadvantage, that they actively scan the areas. I also thought a lot about this and the "right" concept would be to have a list of construction for every construction network. If a ghost is placed it adds an item to that list. If placed it is removed. That's basically all, that's needed. A full scan of the area is never needed - and if then it should scan only one chunk per tick or so.

I point also to that older post of me, that it makes a lot of sense to introduce not only the number of constructions but
- 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.
.... and so on, see viewtopic.php?f=6&t=39474#p251107

The question if that should be done by separate device or only one is for me meanwhile:
- Everything connected to the logistic network should be done with the roboports.
- Number of items on ground for example should be returned from radar and only within scan-range.

[Optera]

But in my opinion both have the disadvantage, that they actively scan the areas. I also thought a lot about this and the "right" concept would be to have a list of construction for every construction network. If a ghost is placed it adds an item to that list. If placed it is removed. That's basically all, that's needed. A full scan of the area is never needed - and if then it should scan only one chunk per tick or so.

Sadly full scans ARE needed. Currently all mods can do is iterate through each logistics cell to get that cells construction area use that to find ghosts and merge the ghosts into one list.
As you guessed this is excruciatingly slow, but there is no other way since we lack any form of data and event to handle states of ghosts.
1) logistic networks can split and merge when roboports loose/regain power without ever firing an event
2) reviving a ghost or simply cancelling it does not fire events
3) caching lists of ghosts per cell is impossible due to 1 and 2, even spreading ghost scanning over multiple ticks is problematic since between ticks 1 or 2 might happen

The game should have a list of ghosts per logistic cell and expose those to the API or at least fire events for logistics and ghost changes.

[dood]

That functionality already exists, you can connect inserters to the network and have them deactivate if an item is above X, if you build something that number is subtracted so they shovel more of it into the network and there you go, what more do you want?
If you want a train to go to an outpost if item X is "missing", you can already do that with a decider combinator hooked up to a roboport that checks if item X is smaller than whatever value you want and then outputs the "come hither" signal to the train if it is.
Repeat for item Y, Z, etc and there you go, what more do you want?

I don't see what this would bring to the table other than overcomplication.

[mrvn]

That functionality already exists, you can connect inserters to the network and have them deactivate if an item is above X, if you build something that number is subtracted so they shovel more of it into the network and there you go, what more do you want?
If you want a train to go to an outpost if item X is "missing", you can already do that with a decider combinator hooked up to a roboport that checks if item X is smaller than whatever value you want and then outputs the "come hither" signal to the train if it is.
Repeat for item Y, Z, etc and there you go, what more do you want?

I don't see what this would bring to the table other than overcomplication.

The point is to ship a radar when the roboport has a ghosted radar in range. Not to always have one radar in store.

[dood]

The point is to ship a radar when the roboport has a ghosted radar in range. Not to always have one radar in store.

What's the point of that?

[mrvn]

The point is to ship a radar when the roboport has a ghosted radar in range. Not to always have one radar in store.

What's the point of that?

Say you build a new mining outpost. You build the train line, add the train stop, add the roboport and release some construction bots. Now you blueprint the electric miners, power poles, belts, walls, gates, flame turrets, laser turrets as suitable for the ore deposit in question. Every deposit will be different.

Assuming the roboport would output the number of ghosts the LTN train stop would then be wired to automatically request the right amount of electric miners, transport belts, power poles, walls, turrets and whatever else is ghosted. The train delivers it and the construction bots build it.

And when aliens attack and destroy something replacements are requested and build.

[dood]

Say you build a new mining outpost. You build the train line, add the train stop, add the roboport and release some construction bots. Now you blueprint the electric miners, power poles, belts, walls, gates, flame turrets, laser turrets as suitable for the ore deposit in question. Every deposit will be different.

Assuming the roboport would output the number of ghosts the LTN train stop would then be wired to automatically request the right amount of electric miners, transport belts, power poles, walls, turrets and whatever else is ghosted. The train delivers it and the construction bots build it.

Okay.
Why do that?
I don't know about you but anything other than turrets or walls being destroyed is the exception, not the rule so in that regard, everything is the same. If you need something other than repair packs, turrets, walls and poles, that's an extremely rare emergency in which case your bot network is probably already destroyed anyway.

Why would you build a complex system that somehow keeps track of each individual outpost and somehow sends a train loaded with just what is needed there if construction is just a one time job? Like, what is there to maintain once the outpost is built?
Seems like you want to do something that just doesn't make sense.

Also if your outpost doesn't have the thing it needs on stock right where it is needed right now and it takes 10 minutes for a train to meander there, that's 10 minutes your outpost is vulnerable and once the train arrives, you'll probably no longer need precisely 2 turrets now but 10.

[Optera]

Why would you build a complex system

Welcome to Factorio, where we always need more production, more pollution and more complexity.

Honestly, why would we NOT want to fully automate base expansion? Factorio is all about automating everything.

[mrvn]

Say you build a new mining outpost. You build the train line, add the train stop, add the roboport and release some construction bots. Now you blueprint the electric miners, power poles, belts, walls, gates, flame turrets, laser turrets as suitable for the ore deposit in question. Every deposit will be different.

Assuming the roboport would output the number of ghosts the LTN train stop would then be wired to automatically request the right amount of electric miners, transport belts, power poles, walls, turrets and whatever else is ghosted. The train delivers it and the construction bots build it.

Okay.
Why do that?
I don't know about you but anything other than turrets or walls being destroyed is the exception, not the rule so in that regard, everything is the same. If you need something other than repair packs, turrets, walls and poles, that's an extremely rare emergency in which case your bot network is probably already destroyed anyway.

Why would you build a complex system that somehow keeps track of each individual outpost and somehow sends a train loaded with just what is needed there if construction is just a one time job? Like, what is there to maintain once the outpost is built?
Seems like you want to do something that just doesn't make sense.

Also if your outpost doesn't have the thing it needs on stock right where it is needed right now and it takes 10 minutes for a train to meander there, that's 10 minutes your outpost is vulnerable and once the train arrives, you'll probably no longer need precisely 2 turrets now but 10.

Keeping a few turrets in reserve at every outpost might be a good idea. But that's beside the point. You are free to stockpile.

The point was that the outpost requests the right amount of stuff to build itself without ending up with 50 extra electric miners or 1000 transport belts without the user having to specify the numbers. automation. And in case the outpost is partially overrun it will request new miners to repair itself. No need to keep a stock of 20 electric miner at every outpost just for the unlikely case the aliens break through in one place.