[0.15.10] missing material for const. constantly change

[factoriouzr]

The missing material for construction alert notification constantly changes even though roboport coverage stays the same and no new items are placed as ghosts. This can even more easily be seen when placing many ghosts to be constructed without having all the required materials available right away. Eg. having 150 construction bots, complete roboport coverage, sufficient power for all roboports and charging bots, then placing around 700 walls with one factory making the walls (though this is likely not related) results in the missing materials notification constantly fluctuating between 290 and 480 walls missing materials. The annoying thing is that this number changes every few hundred milliseconds (more then once a second) and it goes down by about 10 at a time for a while, then goes back up by about 10 at a time, covering a range of about 150 - 200 up and down every few seconds.

This presents incorrect information to the user as to how much materials are missing as the number goes down, then back up for no apparent reason. Once an item is "scanned" or identified as having needing materials and being in roboport range, it should be added to a permanent list of such items, and only be removed from that list when it's actually constructed, the ghost is removed, or the ghost goes out of roboport range (eg. a roboport is deconstructed). This would display accurate information to the user and avoid that annoying constant up and down fluctuation that makes the notification pretty much useless.

This used to work this way in a previous version of Factorio I believe. Not sure why this algorithm was implemented, but it's completely confusing and there is no reason to keep re-scanning and re-adding and removing the same ghosts over and over again.

[Loewchen]

Pretty sure it is a symptom of this one: viewtopic.php?f=23&t=38949 it only considers 10 jobs per tick, so when you have more than 600 open jobs it cycles through them.

[kovarex]

Yes.

[factoriouzr]

Yes.

So are you going to fix it as I noticed you marked it as not a bug like other issues?

Do you recognize that the way it works now is confusing, not useful, and not a desired behaviour?

[factoriouzr]

Can you fix this please

[Rseding91]

Can you fix this please

Changing how that works has significant performance implications and isn't likely to ever happen.

[factoriouzr]

Can you fix this please

Changing how that works has significant performance implications and isn't likely to ever happen.

Thanks for the reply, but you guys are improving the fluid system and making other "big" improvements (which is great), but why not count this as one of those improvements? It's cleanup to make the game better, though I agree it's not as high as some other things like fluid improvements.

[Squish8294]

No, Kovarex has a point.

If you'd like to change this behavior, a mod exists for it, called ConstructionQueue. https://mods.factorio.com/mod/ConstructionQueue

Changing this behavior does indeed have very far reaching consequences. Your PC is already processing 600 construction requests/sec.

For most users, this doesn't present a performance impact, but changing the amount of requests processed per tick has exponential effects due to the fact there are 60 ticks in one second. Change the number from 10/tick to 11/tick and you're processing 660 requests/sec.

For each of these requests, the game polls the local robonet's logistic list to see if it has the resources to fulfill the request. If it doesn't, it moves on. If it does, it has to localize down to the chest in the network where the item is, deliver it, and place it. This whole time, it's in the queue, still being processed as far as I can tell. Kovarex can chime in on the finer details of how it works but that's my layman's understanding of the process.