Increase bot queue processing rate

[NotRexButCaesar]

Sorry if those are pretty forward remarks that you already thought of or are already implemented in a better way..

I also would be interested in hearing the reasoning behind this

(Only because I find these “stories” interesting)

[badde_jimme]

I didn't want to get into complex solutioning as Rseding and other developers at Wube have demonstrated extraordinary skillsets and success in this area. I still would like this suggesting to be the simple idea of increasing the basic number of attempts per tick. I know that strikes most developers as bad, but from a practical standpoint it very well could be the ideal solution as it does not introduce new complexity, nor does it increase management of custom data structures, nor have an additional memory footprint.

I do have one other idea which is to resort the queue every iteration of it by repositioning every job randomly within the list. This would increase bot productivity in many cases because of how placing a giant blueprint leaves the jobs in one section of the queue - creating a "dark age" so to speak. In my 100% speedruns I have been doing this manually by cutting out blueprints and pressing undo every few seconds. By doing that act, it distributes large chunks of ghosted entities throughout the queue reducing the maximum amount of time between processing of an entity for a given roboport.

What about a dynamic boost?

If we go with your shuffled queue, it can quickly find a single buildable ghost, then the rate can be increased for a few seconds to find more. And the improved rate could be dependent on how many ghosts you had, so it would be very targeted. If you don't need it because you don't have many ghosts, it can remain at 1 per tick. If you don't need it because nothing can be built, it stays at 1 per tick. But it can shoot up to 100 or more when the queue is large and likely to have buildable ghosts.

[Xarovin]

Instead of having a queue of ghosts, it might be better to have a queue of (chunk, building_type) pairs, with each pair holding a list of ghosts that can be built of that type in a given chunk.

I sort of suggested that a few years back, but without the chunk idea.
Basically instead of checking 10000 times that concrete doesn't exist across the whole base, it should just skip straight to the next item if concrete is not found.

Something like this (psuedocode in Python since I know nothing about the game internals):

Code: Select all

for entity_type, entities in build_queue.items():        
    for entity in entities:
        result = do_stuff(entity)
        if result == 'no_resource_found' and not check_logistic_item_exists(entity_type):
            break

[rain9441]

I don't know if skipping concrete jobs entirely if concrete wasn't found is as straightforward as that. A single tile of concrete could be under two different roboport construction areas, and each area may or may not have concrete. If you want to short circuit all the concrete attempts, you'll have to keep track of whether concrete exists in each logistics area. I don't know if this infrastructure exists, or if the corresponding GUI generates that information every tick if it is open (It might generate the information every tick for simplicity, as performance impact is less of a concern in that UI).

Do you then manage that data structure or generate it each tick?

Is the cost of those operations to manage/create the data structure greater than the cost of one failed attempt per tick?

... how about two failed attempts?

... how about ten?

... how about twenty?

[Xarovin]

I don't know if skipping concrete jobs entirely if concrete wasn't found is as straightforward as that. A single tile of concrete could be under two different roboport construction areas, and each area may or may not have concrete. If you want to short circuit all the concrete attempts, you'll have to keep track of whether concrete exists in each logistics area.

I only wanted to do a quick example there as I've no idea how the game does it internally. My thought was that if it finds an item is not available a few times in a row, it will do a check against all logistic networks. If it does exist somewhere, then set a flag to avoid doing the same check again within the loop, otherwise break the loop for that particular entity type.

Since my net is playing up and I can't do much else right now, here's the same code fleshed out a little with what I just said.