yeah like already said … i am a bit extreme on belts.
as you can see on my screenshot, my supply stockpiles are emtpy. my guess is… my production needs every ressource comming out.
So, my bottleneck is now SERVO. i have a stockpile nearby but there is not enough ressources comming out to fill it.
i attached my savegame
btw. this version is WAY more stable. no more lags when adding belts.
Wow… You really shouldn’t place that many Resource Conveyors.
That makes the pathfinder go all crazy and also will cause the Slots to compete for the same nearest Resource Importers…
The problem there is that each slot only looks for the 2 nearest Resource Importers to schedule their request… which is the reason why your resource importers have such long resource import queues… a lot of slots compete for the same resource importers.
Basically you bottlenecked yourself by not distributing the resource demand over the available resource importers.
Try distributing the demand over more resource importers by removing most of the resource conveyors paths… Basically only route a few slots to the same resource importer. And don’t interconnect all paths.
For Cliff: But that’s probably another reason why the resource importers (=m) and all queued resources (=n) should be a global m:n table… if it isn’t already… with an overall information how busy they are (like a sum of all currently queued items = queue_length).
And each slot having its own local importer table (of all reachable resource importers) that contains the path distances (path_length) to them that is created during path updates (or slowly over time in the background so not all paths have to be calculated at once to avoid the slowdown… and instead a slot gets more route alternatives the longer the game is running, of course with a maximum amount of alternative routes being searched)…
And then when scheduling a resource import iterate through that local table of reachable resource importers while also looking into the global m:n table how “busy” (queue_length) that one is and if it is too busy pick the next resource importer with a penalizing total_time factor… something like so:
for (i=0; i < number_of_reachable_importers; i++) {
total_time = resource_importer_path_length[i] * time_per_tile + resource_importer_queue_length[i] * time_per_spawn;
if (i == 0 || total_time < total_time_shortest) {
picked_resource_importer = i;
total_time_shortest = total_time;
}
}
Where the travel time it would take the resource to get from that resource Importer to the slot (path_length * time_per_tile) would be added to how long it would take that resource importer to get rid of its queue (queue_length * time_per_spawn).
… and then pick the one importer where the total_time is the shortest.
Or that’s at least how I would try to implement the resource import logic. But I don’t know how efficient that is considering performance. It may not be all that efficient if the list of reachable importers is quite long and the amount of slots it has to be done for is quite high… so it might only be worth doing it for the 3-5 importers with the shortest route as determined by the pathfinder.
But then again the slots could be distrbuted into multiple threads on multicore CPUs… with each thread taking on a proportional fraction of the all the slots.
Also it doesn’t factor in Manufacturing Slots and Stockpiles… but there is probably a priority system anyways where first it checks stockpiles, then manufacturing slots outputs and only if there can’t be found anything in them then finally go to the resource importers.
yeah you are right.
just doing that … and i see some results already.
i might go to a therapy for those belts bad habits 
thanks a lot.
