Change ordering of drone repairs when large numbers of buildings are damaged/destroyed

[BicycleEater]

TL;DR

Change the logistic system so that when more buildings are damaged than the drones will attempt to repair at once, separate logistic systems still attempt repairs

What ?

I can't find a good term for it - I'm sure one exists - but when a large number of buildings are damaged without repair packs, cannot be built, or are destroyed, only a certain number of the warnings are shown/processed at any one time. I will refer to this as the batching of the warnings unless I find a better word.
When warnings are batched, the game appears to only update them at certain times. I'm sure this saves huge amounts of performance when large amounts of damage has been done, as the game only bothers looking at a certain number of the repairs, leaving others for when those are resolved. But this batching should be done on a per-logistic-network level, rather than globally (or per force), as it appears to work at the minute.

Why ?

In the right situation, issues in a larger base can result in the logistic network of a smaller base (or a personal roboport equipment) refusing to repair buildings - it will build new ones, but won't fix old ones. This manifests as the smaller base (or personal roboport equipment) not repairing damaged entities, but still building new ones promptly.
I don't know quite how this batching limit manifests, but there does appear to be a limit to the warnings.


A brief demo of the effect (I am well aware that I am using lots of mods, these make it much easier to show this issue):

ShownWithInventory.png (2.47 MiB) Viewed 4072 times

DronesNotRepairing.png (3.01 MiB) Viewed 4072 times

-----------------------------------------
EDIT:
To clarify - I am not proposing the removal of the queue, I am simply proposing that it could be more responsive to the needs of separate logistic networks and the player.
In the screenshots, I am miles away from the nearest roboport, and my construction range does not overlap.
I am not proposing a change to the priority of different tasks, only that tasks near the player get done in reasonable time.

[ssilk]

I can think of good reasons, why building has a higher priority than repairing. When you have a wave of biters and want to place some wall or turrets for example.

[BicycleEater]

I don't want the repairs to have higher priority, I just want the repairs to be split among separate roboports. The main base is going mad right now repairing damage, but my player just has to wait around for it to happen.
I don't care if it prioritises building deconstruction or what - I just want my character to actually repair the things around them some time this year.
You can easily find you have to repair a remote base by hand because your main base is too busy.

[BicycleEater]

To clarify - in the above pictures my character is nowhere near in range of any roboports, so the damage should be fixed by the personal roboport equipment, but isn't because the game is too busy doing repairs elsewhere.

[Squelch]

Perhaps some clarification is needed here?

When the OP refers to a separate logistics network, is this actually the case? ie when viewed from the map with logistics network overlay active, are they are separate islands?

I haven't noticed this, but if separate logistics networks are included in the "batching" of robo tasks, then that would be rather undesirable.

Eg.
A new satellite outpost with network id 123 that is priority queued to be built, would prevent another outpost (network id 100) needing repair due to a global task list.

Is this the case?

If, on the other hand it is one large network, then splitting it up with belt/inserter bridges should allow robots in each part to work on tasks within that smaller network. This tends to be my personal strategy for a number of other reasons.

[BicycleEater]

Yes they are entirely separate - sorry for this not being clear.
This will not show normally as you need hundreds, if not thousands, of tasks in the queue - see the warning in the screenshot says 71k buildings destroyed, so it requires an extreme situation for this to come into affect.
The only reason for the queue is (I believe) to reduce the performance impact of having lots of tasks that need checking - only checking a certain number at a time. This can be seen if you try and pave an entire huge base (which doesn't have enough stone bricks to pave) - it will only flash up the warning for maybe 400 of the stone bricks.

[BicycleEater]

From my (relatively limited) testing it does seem to be the case that the bases can interfere, and I agree that this could be very bad, for instance preventing a remote base from repairing because the main base has too many robo tasks to complete.
The only reason I noticed this was that I have made a mod adding really huge nukes - these can damage the whole map at once, and easily flood the batching system, without this it is hard to notice.
To make sure the answer to your question is really clear:
I am not anywhere near any other roboports (like a hundred tiles away from the nearest building other than the chests), and my construction range is entirely separate from any other.
I am not using modded roboport equipment, roboports, repair packs, chests or drones, although there are other mods installed:
https://mods.factorio.com/mod/True-Nukes
https://mods.factorio.com/mod/True-Nukes-Graphics
https://mods.factorio.com/mod/Aircraft
https://mods.factorio.com/mod/SchallTankPlatoon (this adds modded repair packs, but I don't use them).

[Squelch]

Interesting.

I feel a scenario coming on to test this out. Bots are hard to monitor, and I've always wondered why sometimes they don't appear to be doing what I had hoped them to do, and this new revelation might explain why.

The alerts are definitely capped, but I have been under the impression that it was just the alerts themselves, not necessarily the tasks. If build orders are prioritised globally, regardless of logistic network, then it makes having individual networks for different areas moot with regards to breaking the factory down into smaller networks. They do still benefit from bot travel time reduction, and helps keep materials manageable too, but apparently not as effective as one might hope.

If the task priorities are changed, balance may be affected - albeit I'm not sure a global task list can ever be balanced. Perhaps if the whole map (wrt construction area) could be split into smaller areas of equal population and then each batched in a round robin (time slot multiplex) fashion so that they all get serviced with whatever tasks are pending?

Random biter attacks not being serviced because you have decided to build a large outpost the other side of the map means a whole deal more micromanaging. I hope there might be a more transparent solution forthcoming. I'll make a test scenario over next few days and see what's what.

[MEOWMI]

The logistics networks will only process up to a certain amount of tasks per tick. If you have hundreds and hundreds of tasks queued up, it'll both slow down the processing of assigning individual tasks, but also mean that not all tasks may get alerts. From what I know this is relatively well known by now.

What you're bringing up here seems to be the same thing. It's just made that way and, as we know, there's reason to believe it was made this way with computational efficiency in mind.

To add some detail, AFAIK a task being fulfilled doesn't cause problems, only tasks that are waiting to be fulfilled (hence the warning icon), so for example bots recharging at an overcrowded roboport doesn't count as "queued" since the bot is already working on the task, albeit slowly. Also, separated networks may bear no difference on this task assignment, as it is most likely all done in bulk by the game code.

The solution is to have less tasks queued up at the same time. Either increase capacity at bases where you complete a lot of tasks, or assign tasks in smaller chunks (especially large build projects). Probably a bit of both. There's not many reasons why you need to have lots of things queued up and usually it's just a matter of improving bot infrastructure.

That being said, I guess it would be nice if it could be improved upon even a little. It's not something I've experienced, but I can see how it could be pretty confusing for players who do run into it.

[BicycleEater]

My problem isn't that I don't like the system - I'm fine with the fact it exists, but was thinking that something could be done to reduce the impact on the player - it is really annoying to have to repair a base by hand, even though it has nothing to do with a different base which is busy.
I was making this suggestion not to change this system, but merely change the order in which tasks are queued.

I really just want the addition of some logic like:

"every logistic system has at least one task on the queue, if it can", or
"the closest task to the player(s) remains on the queue"
Both up to some kind of limit, maybe 1/2 the queue length.

This would mean that while the tasks still queue up, smaller bases still get a look in, reducing the impact of the queue. These changes would not add significant performance load, as no more tasks are checked, and would not affect most cases. Again, I have only hit this because my mod is extreme, but it does provide a nice example of a situation where this kind of thing becomes an issue.

[BicycleEater]

Just as another note:
The personal roboport should really have priority - looking at it from the perspective of a player who doesn't know about the queue limit, and it is easy to believe the roboport isn't working, as it will simply not respond for minutes on end, with no apparent cause.

Another way to resolve this would be if personal roboports simply took priority in the task queue (maybe up to the first half of the queue for really large multiplayer) - they aren't that common, and can't cover that much ground so won't fill the queue - and then the system would at least appear somewhat responsive.
This also prevents the case of "the factory is too busy building stuff, so won't repair my tank", although I would still prefer a more general solution, allowing better priority for remote/independant bases.

Just to ask, since you seem to know more about this than me:
Does the queue limit work globally, or per force?

[Squelch]

The task queue cap has been known about for some time for sure. However, I'm not sure that the order of operations and priorities are that widely understood. Breaking base development into smaller chunks seems sensible, but for new players - maybe some veteran players, the rationale is not exactly transparent. This is further exacerbated by not having a complete overview of bot activity and goals across the base.

I think it is safe to say that the reasoning behind the limit is accepted for performance reasons. What does seem to be a recurring issue, and is quite often reported as a bug, or help query, is that bots do not appear to be doing what the player has expected. This is explained away as the total number of bot tasks being full. Does that mean logistic and construction tasks combined? Does it mean ghost layouts must be deleted to allow repair and replenishment of a section that has suffered a biter attack? The nature of the bot network being dynamic and distributed over a wide area means that it is hard for the player to strategize through discovery.

Time multiplexing the individual logistic networks might help with those apparently lazy bots in one area. It can be observed that the alerts are recalculated periodically, therefore it might not be too much of a stretch that the task list is re-evaluated at the same time and so might present an opportunity to also consider the number of unique logistic networks and then spread the capped task list equally between them. This could prevent one network from hogging all of the tasks, and allow those few, but very critical repairs to be made the other side of the base in a timely manner instead of waiting for all of that concrete to be laid.

I've been running some tests, and it is not exactly clear that there is a priority between tasks (eg. building vs repair). It looks more like it is simply first in first out. That makes trying to build an outpost as much a matter of luck in timing between biter attacks as it does in logistic planning when it comes to saturating the task list.

[BicycleEater]

Yeah, I haven't had any luck trying to decode the system either.
Even if there are no changes, it might be worth someone who does understand the queue (maybe even the devs) adding a wiki page (or an in game tutorial) on this topic, simply so that players have a way of finding out about how the system works, and to provide a good source to reference when someone asks these kinds of questions.
I would normally not ask the devs to explain something about the game, as the player base should be able to explore game mechanics, but in this case that feels less relevant - the problem is an optimisation built into the game in an unpredictable way, in a system which, as you mention, is very hard to experiment on.

If per-logistic network distribution of tasks is not possible, maybe space-wise, so that the game executes a breadth first search for tasks - this might mean 1 task gets added to the queue per chunk first, then more tasks get added if there is space. This might (in a really big base) mean allocating 1 task for every 10 chunks, or some equivalent.