[2.1] Roboports should report ghost entities

[worph]

TL;DR

There should be a way to read unbuilt entities/ghosts from the roboports.

What

Currently, I don't know of a way to get which items are scheduled to be build but missing the actual item.
The ghost entity in the following example image, does not show up anywhere in the circuit output of the roboport.

grafik.png (721.32 KiB) Viewed 1318 times

I would expect some way to show these like pictured below.
Now that we can separate outputs to red/green wires this is a prime implementation to use this feature with.

grafik.png (211.96 KiB) Viewed 1318 times

Why

First of all, it's cool to tell your automall which items need to be built on demand.
But the more likely and better application is Aquilo (or any other planet that should be supplied by a mall in orbit).
Currently, especially on Aquilo, one has to keep at least one of every item on the planet surface and resupply that item once it's used, if you don't want to handle this stuff manually.

With this change, and some circuitry magic, I can cue up a large batch of buildings and the Cargo Landing Pad should eventually, if I programmed it correctly, request and fulfill all the projected items eventually.


(*edit: In case you are wondering: Changing the settings from "Read ... contents" to "Read ... requests" on the roboport changes nothing. I knew that before taking the screenshots, but I should have selected that option)

[robot256]

Previously:
viewtopic.php?t=133812 (in Outdated/not implemented)
viewtopic.php?t=39474 (very long thread where all the suggestions of the same kind were merged, except the one that was moved to outdated/not implemented)

[worph]

Missed those, mea culpa. The one from 2017 is a bit old anyway. But the one from last month is not only recent but pretty clear.
It begs the question though, how the game cannot know these things, but I digress.

[eugenekay]

It begs the question though, how the game cannot know these things

The Number of Ghosts in range of a given Construction RoboNetwork can be counted, but this is a potentially expensive operation as it requires searching through all Entities on a surface; potentially each Tick if you want to have an accurate Circuit output. More complexity comes from the fact that Construction RoboNetworks can overlap where there is not an overlap of Logistics Networks (which are merged into a single Network) - leading to inaccurate/duplicated Ghost Counts on both Circuits. Trying to add/remove a "running Total" each time a Ghost is placed/cancelled/Revived would require careful logic handling everywhere that Ghosts are interacted-with (Robots, Planners, Scripts, Events...) to ensure it stays accurate; or set you back to performing a potentially-slow "sweep" as above.

The current implementation scans "a few" Ghosts each Tick, and then creates a timed Notification. It performs well with tens-of-thousands of Entities pending.

[worph]

I don't think implementing an accurate list of those entities is in and of itself a hugely complicated problem. Sure you need to find all the edge cases and test it thoroughly. It's probably just too much work for relatively little benefit. I can totally see that.

[Ruuttu]

I understand providing an accurate list in real time would be expensive, but I also don't think it would be necessary. The robots take their time to work through the list of ghosts, and it makes intuitive sense that those with missing materials would be "discovered" at some point. A list which tracks and cross-references all the items and requests across the entire network in real time would seem like magic.

The roboport could provide a list which updates infrequently, and which isn't perfectly accurate even when it does, and I would still be perfectly happy. I can't imagine a legitimate use case where the signals for the ghosts would have to reflect changes immediately.

[macdjord]

+1

[JackTheSpades]

+1

For performance consideration, it doesn't have to be on the same tick as the ghost is placed just output the signal eventually.
Plus the missing construction materials literally show up on my HUD so it's not like the game isn't already scanning for them.

Personally, I tried to build a system that would craft Captive Biter Spawner on demand when I build ghosts (since they spoil and can't be pre-build) only to later realize with disappointment that ghosts don't actually show up on signals. Still useful since I can toggle it with a requester chest but just requires those few extra steps.

07-07-2026, 09-12-22.png (816.2 KiB) Viewed 1024 times

[aaron311]

I, too, would love an output signal for this even if it was only output every so many ticks (e.g. every 10s or so). I can latch it, or the game can

Complicating this however is that you have to consider things like:
* ghost entities
* ghost tiles
* inside-entity things (module slots, etc)

However, even a best effort implementation would be appreciated.

[worph]

RE: my earlier comment about it totally being possible.

I have no idea about the source code of factorio, but I strongly believe the game uses some sort of eventmanager, like any other modern game.
Looking at it from an event based perspective, there really are not that many cases that can create a ghost entity.
It's always player input (I know there are mods, that do it, but they will use the same functions, I assume).

It would be perfectly fine to keep a per-surface list of unbuilt entities in memory. Append to the list on place_ghost_event, or whatever.
And checking which ghosts are in range of which roboport could be done every so often and also kept in memory for every robonetwork.
The cornercase, of a ghost being in range of two networks, shoud just report the ghost in both networks.
And whenever a construction bot starts his journey to grab and later place an item to build, or whenever a player builds over a ghost entity, should remove the ghost from the list. Also when the ghost itself is removed.

It's not too many if statements and not a lot of events, and lists to keep track of, considering how much stuff the game already tracks each second. Even if it's twice or three times the amount of conditions, that still seems reasonable and manageable to me.

[Peťan_Máša_Křižák]

Hello,
this idea can help us in our 1000x science prize game, where we have automated delivery stations and we have to manually enter the required quantity of specific items for delivery into a constant combinator.

07-09-2026, 07-36-54.png (1009.19 KiB) Viewed 851 times

Control circuits are "powerful magic" that can be incredibly helpful - especially when MALL can subsequently produce the required amount of things for construction. All this thanks to radars transmitting signals from control circuits.

[The-Zee-System]

+1 so automation can be more efficient and not have to rely on massive amounts of alerts on my screen blocking and blinking everywhere

[Lingkar]

+1
I also just figured out that there is no way to retrieve ghost entities from the surface (within logistic network).
It feels a bit unintuitive as this is supported for ghost entities on the space platforms, which give the possibility of reading orbital requests based on ghost entities.

[worph]

It feels a bit unintuitive as this is supported for ghost entities on the space platforms, which give the possibility of reading orbital requests based on ghost entities.

I get what you mean, but this is not supported in the same way I was suggesting.
Even on space platforms there is still no way to read the ghost entities with circuitry directly (if you ignore the fact that you could read requests in a rocketsilo and send them back up via a radar).
But you hint at an iteresting fact:
There must be some code that performantly reads ghost entities and processes them already when it comes to space surfaces.
I cannot in my life imagine that this could not be somehow made to work on 5 other surfaces and be made available to read from roboports.

[macdjord]

Note that Factorio already has a system for detecting and counting ghosts; you see it do so every time you get a 'Roboport is missing the materials for construction' notification. We just need that info to be available from the roboport as well as the GUI.

[Rseding91]

Note that Factorio already has a system for detecting and counting ghosts; you see it do so every time you get a 'Roboport is missing the materials for construction' notification. We just need that info to be available from the roboport as well as the GUI.

This information is not what you think it is. It's only accurate *at the exact moment* that the alert is created. At any point after it's created it may in inaccurate - the ghost may have the items available and or a robot may be on the way to build the thing.

The game also only processes so many ghosts each tick so if you have a lot of ghosts the information will take some time to show up.

It is also only relevant for a single specific logistic network. If there are overlapping networks - one may generate an alert that something is unavailable and in the exact same moment find another network with the item available and send a robot to work on it.

[worph]

It is also only relevant for a single specific logistic network. If there are overlapping networks - one may generate an alert that something is unavailable and in the exact same moment find another network with the item available and send a robot to work on it.

But isn't that fine/expected behaviour? I only ever built two separate robonetworks close enough to eachother, so this could occur, once and it was a bad solution for what I was trying to achieve with it. And even then, you would have to manage those potential conflicts. It's expected that both systems work independently and may process the missing entity differently. It's all about how you process that information.

This same conflict already exists in the game anyway. If you setup a ghost entity in reach of two robonetworks, you cannot influence which one builds the building first, and thereby uses up the item. And it's fine, or at least I haven't seen anybody complaining about it. In this case it would be even less of a problem because you decide where and when to process the info.

Edit: I would even be happy if Radars could read this information for the entire surface and you have to figure out which robonetwork might need it. Now I could at least send the correct item down from orbit, especially on Aquilo.

[Villfuk02]

The game is already collecting the information about what items are needed to build the ghosts and reports to the player what is missing. It does not process all ghosts every tick, but instead sweeps through them, so the total count is not available. However, this incomplete list is enough for the feature's use case. Maybe call it "read missing construction material alerts" and just report the alerts originating from this specific roboport network? This would make it clear that the same quirks apply to both.

[Loewchen]

The game is already collecting the information about what items are needed to build the ghosts and reports to the player what is missing.

As has been explained in this very topic more than once and in this forum more than 100 times:

No it does not.

The only thing that is shown to the player is how many times within the last 10 seconds a job could not be allocated because material was missing. If you see 100 alerts for inserter not being placed there could be 0 inserter missing or 1 000 000 inserter missing or any other integer value, because it counts the number of alerts not the number of items. The number of items missing is never obtained.

[worph]

The number of items missing is never obtained.

I think the misunderstanding most people have is not the mismatch between what is displayed and how many ghosts actually exists.
The game does remember how many ghosts you placed. They never disappear for any reason other than they were built or you removed them again.

Most people I believe are - rightfully - confused by the fact that the engine does not keep track of those entites in a simple list.
The game keeps track of thousands of bots, thousands out of hundrets of items on thousands of different belts. Everything in different locations. And so much more.
In comparison a list of static ghost entities, does not seem like a huge deal, neither on performance, nor in terms or programming difficulty. (Especially given the fact that the game clearly already does remember every single ghost entity in some fashion or other without exception.)
I know (now) that it's always a little more complicated than it seems, but it just seems very strange still.