Factorio Forums

TL;DR

Provide chunks information of ghost tiles and roboports related. Add job queue to roboports. This would remove the need for construction checking for ghosts not in construction area.

What ?

Each factorio chunk would have a list of ghosts in the area, and a list of roboports which are related to this chunk. Each roboport would have a job-queue of ghosts in the area.
At ghost placement, check if it is inside the chunk-related roboport's area. If it is, add it to that roboport's job queue, else add it to the chunk's "remaining ghosts"-list. At roboport placement, check the chunks in the construction area for remaining ghosts and add them to job queue if they are in this roboport's area.

When checking for tiles to construct, check roboports' job queues (if roboport is powered). As there are only constructable tiles in these queues, there is no longer need to check all ghosts if they are constructable or not. All of the checking is done on placement of either ghost tile or roboport.

Why ?

At the moment, only a couple of ghosts are checked for construction per tick and as I understand, each ghost is periodically checked if they are in a construction area or not. This leads to situations where a lot of ghost tiles outside of construction network fill up the checking quota, and so none of the ghosts in the network area get constructed. This often leads to frustration and manual work for the player.

Adding more information about the ghosts would remove the need for periodical checks and the construction network would feel much more responsive. It would also open possibilities for logistics and batch placement, as each roboport would have a queue of needed items.

I like this.

This case is especially true, if you place very big blueprints (with a lot of roboports that needs to be constructed). Which can last very long.

And it plays directly into the arms of being able to count needed items for construction. Needed for fully automated expansion, automated outposts etc.

There can be any number of overlapping construction networks which can work on a given ghost: construction networks can move (players) and construction networks don't connect like logistic networks do.

That means any particular ghost could be in any number of construction areas. That means it would have to know what areas it's in, and the areas would have to know what ghosts are in them. Any time a roboport lost power it would have to go over each ghost and remove them from itself and itself from it.

Every time a player moved, lost power, or gained power, disabled or enabled their personal roboports they would have to scan the entire area they're in and add/remove ghosts as they move.

All of that because you've build a load of stuff outside of network that can't be worked on. Just don't do that: build roboports and build things in the roboport area. Building outside the roboport area does not help anything: the jobs can literally never be worked on until you've provided roboport coverage so just build the thing(s) when you do that.

If a roboport is powered, do jobs, else skip the roboport. Absolutely no need for removing them at powerdown, only a simple condition.

Ghost building outside of network has huge value in planning a factory's future. It might also be the case that roboports would be added to a new area, gradually filling the planned expansion, which could be planned many, many hours before actually wanting to build them.

Obviously there are modifications to this idea to fit multiple roboports and moving roboports. For example, if chunks always have a map of ghosts, multiple roboports could have same jobs in queue and as a job is taken, there would be a check if it is marked taken or done already in the area. If is, next job. These come up to n checks per job where n is the number of roboports (which is usually not a large group), and these checks would be spaced out naturally as roboports come up to the job at different times.

Moving players are a bit harder, though. Maybe, when a powered/enabled personal roboport gets a turn, it could check the area's chunks for ghosts and do what it can. This equals to a maximum of 25-ish chunks to be checked per player per roboport-round. Chunks completely in the player area can do jobs straight away, others would need further check.

This request essentially boils down to roboports should output requested and missing construction material

Rseding91 wrote: Fri Jan 24, 2020 6:05 am There can be any number of overlapping construction networks which can work on a given ghost: construction networks can move (players) and construction networks don't connect like logistic networks do.

That means any particular ghost could be in any number of construction areas. That means it would have to know what areas it's in, and the areas would have to know what ghosts are in them. Any time a roboport lost power it would have to go over each ghost and remove them from itself and itself from it.

Every time a player moved, lost power, or gained power, disabled or enabled their personal roboports they would have to scan the entire area they're in and add/remove ghosts as they move.

Right. But I think you are thinking too deep into implementation details, because what you said, Rseding, opened me the eyes that it is not needed that this new feature works absolutely perfect in any case.

Let's lean a bit back and let me explain.

For what is this feature really needed? It's not needed for those that just want to make an mining outpost. Those players, that need this feature are counting in doozens, hundred or thousand of needed items. Otherwise it doesn't make so much sense, because the effort to create such a supply system is really high. AFAIK. We are speaking here of LTN or other delivery systems, because with vanilla Factorio this is really difficult. (AFAIK)

And for automated self-construction (which is somehow the crown jewels of Factorio) this is essential, that you know the amount of items that needs to be placed in that construction network.

Because otherwise you cannot build things fast enough, because you don't know, how many items needs to be transported to that network. And for future things we don't know yet.

As you see, for that cases you don't need the exact amount of items. You will deliver not some, but many items. So things can go wrong, some biters come and eat a whole chest with items in it for example. Or the player just takes some items from that network. So you will order always a bit more. It makes not so much sense to deliver exactly that currently needed amount. Think of a supermarket that orders just the tomatoes it surely needs yet. You need to estimate and order always a bit more than you have estimated.

Only in very, very special and rare cases and autistics need that it is really the correct number. But it is much easier to look - after everything has been built - that the unused items could be sent back.

You can compare that also with massive parallel computing on thousands of cores, because in that case you reserve also some cores for those nodes, that have a malfunction during that calculation. Or that you harddisks have extra sectors for those sectors, that broke. Or a newsdealer shop, which orders also more, that can be selled and he can unsold magazins back.


So - what's the new thing is with this suggestion is: Factorio doesn't need to be super exact for this feature!
I really havn't thought this completly through (and there are of course many special cases), but I think from the technical implementation it would be enough to update the list of to be constructed items chunk by chunk. Factorio goes through a loop of by construction areas covered chunks or chunks that has been marked as that they will be delivered soon. No need to take power failures of roboports into account (through that loop of course). It could be updated some dozen ticks later. It doesn't matter, that the construction items are delivered some ticks later, because it takes some time that the chunk is scanned for new items. There is no need that items are in two, three or more construction networks overlapping (as said before you will always deliver a bit more). It doesn't need to take into account, that an item is delivered to that chunk and about to be constructed. And so on. What it needs, is that it counts the number of to be constructed items within some seconds.

All of that because you've build a load of stuff outside of network that can't be worked on. Just don't do that: build roboports and build things in the roboport area. Building outside the roboport area does not help anything: the jobs can literally never be worked on until you've provided roboport coverage so just build the thing(s) when you do that.

Don't blame me for building outside of not yet constructed construction range when it is not possible to do that in an effective way. Well I know that it would make sense to build first the roboports and power. But THAT is a totally different subject! I wrote some post about construction filters (working a bit like deconstruction planner), that would enable such things easily ( viewtopic.php?p=469552#p469552 )

@ssilk
When delivering material with LTN rounding to at least next full stack is almost required. It's why I added an option to round to full stacks into Ghost Scanner.

However I would rather have the api count correct and do rounding with circuit network later. Otherwise it could end up as frustrating as train stops reporting fluid residue < 0.5 as 0.

Well, that goes a bit off topic now, sorry.

A full stack is IMHO too much or too less. It rounds up to the next stack. Which could be something between zero and stacksize-1. I prefer adding some items. 5 are most times enough. It depends on the distance to the source station, the farther away, the higher this ”threshold”.

At the same time I set the minimum delivery also to 5. Like so when I want to place a pole and there is no one left I place a ghost which is added 5 poles so 6 poles are ordered for that station. This is the compromise I found till yet. (*)

Because if you want to place thousands of concrete tiles it’s not so clever to order much more in advance by estimating. Well it‘s ready at some point, but it could be much faster if it would order an estimated amount of tiles in advance. Because simple performance reason don’t allow to scan 10000 tiles or more.

And here we are again back to topic: if that would work somehow more or less reliable to count ghosted/to constructed entities FAST, then that is what’s really needed...

And fluids are a completely different thing (in my eyes)...


(*) and that would be in my eyes a nice idea for the Ghost Scanner: it can take the minimum requested signal and adds that to the signals. On the other hand: there are super clever automatic supply ordering systems in the real world, which try to estimate the future sells of some article. They could be used for this job, too.