Distribution of robots

[ssilk]

In https://forums.factorio.com/forum/vie ... f=6&t=8905 in the initial post at the end I wrote:

Placing of robots
Roboports make the communication inside of an connected logistic area and robots just fulfill the requests. I even don't need to say how many robots should be in which logistic network. Cause the robots belong to the robotic area, and not to a logistic network. The roboports take care, that the robots in one logistic area are equally distributed. They may take into account, that there are points, where more robots are needed (they have some kind of usage statistics and can estimate the average need of robots within their port area (which would also enable us to put the right number of robots into the area)).

I will decouple this here from the above mentioned thread.

The basic idea of this suggesiton is, that the player don't need to do anything, cause the roboports of one connected area will do that for you in an aceptable manner.

The basic principles are still valid:
- It's not good, if the logistic area is too big. I would say it should not be bigger than 1000 tiles...
- It's a fatal idea, to transport many items over long ranges with the bots. I would say, everything over 200 tiles is too long.

But there will be nothing, which forbids that, it's up to the player to use it right.

New feature: Parking

- A new feature is needed (that might eventually be researched): every roboport can request robots to park in his port.
- The initial number of robots in a new placed roboport is simply: total number of robots / total number of roboports (per area of course)

How it works
Robort-Usage-Statistics: Every roboport makes a usage statistic: in my area are X robots working, I still have Y robots left, that makes a usage of Z percent.

Example:
50 bots working in the area, 10 parked => 50 / 60 (working plus parked) = 83 % usage.

Logistic-Area-Usage-Statistic: All roboports of an area make an usage statistic over all their usage.

Example: If there are 2 roboports, one with 83% usage, the other with 17%, the total usage of the logistic area is 50%.

Now after some interval of time a roboport checks, if the requested number of robots is ok.
In our simple example: We have 100 robots in the area. The first roboport will request then 83 robots, while the other will request 17 robots.

This is of course not changed immediatelly, the increas/decrease is slow. This depends on the total-usage statistic: If the total usage is high, then this means, things are changing fast and the change is done faster, than with low overall usage.

In other words: If you don't have much free bots, this check and update of requested bots per roboport will happen in faster intervalls. Low usage, low change, roboports look in long range statistic and change robot requests slow. High usage, high change, fast robot request changes.

As side effect, we can effectively insert new robots into the area, if needed, for example, if the overall usage is over 90%.

Another side effect are the usage statistics over transport per item, which are then quite easy to calculate.
Transported tiles vs. transported number of items. Plus the relation: (items per tile) * item . That with the highest value has the highest optimizing potential for speedup. But that is eventually another suggestion.

[ofca]

In my game, which now spans a pretty big chunk of map, the only long range traffic I'm seeing are:

1) construction drones;
2) drones delivering goods to me.

I can't say for sure that your suggestion will solve anything, especially since there's no problem in normal situation with idle drones on standby. Problems start to arise when something causes all the drones to do one thing, like transport a million plates because of a misconfigured chest.

Another problem I've noticed are drones that are not flying between roboports, but instead in a direct line between source chest and their destination, which causes drones to drain their energy reserves and drift towards nearest roboport, which obviously impacts whole fleet (drones are busy longer than they need to be)

Currently drones park in nearest roboport once they become idle. I'm not sure if spreading them evenly over the map will make things better, and your statistical spread based on workload may be pretty close to what happens now, since drone parks where it worked last.

I think our collective idea about implementing smaller logistic areas may actually solve this problem too, since it's somewhat aimed at eliminating intergalactic drone flights

[katyal]

I agree with ofca. If we succeed in getting betters tools for managing the size of our lognets, distribution of bots will become moot.

[Marconos]

I'm not a fan of the idea.

Simpler to just assign robots to a named network, done. Let the user balance out the bots. If I want to put 10k bots in a spot where I only need 100 let me. Don't control me. IMO, you cannot separate this from the named logistics networks, the two go hand in hand and require each other. Trying to separate them is a bad idea from an implementation and usability standpoint.

[ssilk]

Well, I don't know how others are doing, but this suggestion will solve the issues:

I transport often things only in one direction, the robots then will gather in the surroundings of of the destination.

Another issue is, that you have a train station vs. some kind of continuous craft. The train station usage is non-continuous, the robots there will be sometimes used to 150%, sometime no use, depending on, how the locomotives drive in. There are peaks for transport capacity, which currently disorder the whole distribution.

These two issues and some more similar can be fixed with this. It would work much better, if the generated statistics include, if the bots take up or place down.

[Marconos]

Well, I don't know how others are doing, but this suggestion will solve the issues:

I transport often things only in one direction, the robots then will gather in the surroundings of of the destination.

Another issue is, that you have a train station vs. some kind of continuous craft. The train station usage is non-continuous, the robots there will be sometimes used to 150%, sometime no use, depending on, how the locomotives drive in. There are peaks for transport capacity, which currently disorder the whole distribution.

These two issues and some more similar can be fixed with this. It would work much better, if the generated statistics include, if the bots take up or place down.

The train station "issue" doesn't make sense to me. In my stations, I only allocate enough bots to completely empty the chests before the next train arrives. I may have a few extra if I want it sooner, but they are limited to that job. I currently have to do that with a disconnected roboport which is kinda a pain.

The only one direction is how everything is pretty much transferred. Here if you have specific networks you again solver your issue. If you need to move coal to your boiler lines and your plastic lines you set up a coal network. Then allocate enough bots to keep those items running. It's no different the using the right number of belts to move materials around. For the crafting anything areas you have chest setup in a network that services that. Again it's all defined networks that robots are assigned to. The actual coverage is handled by the roboports that have nothing to do with a named area, they just mark an area that bots can work in. The named network that the bots and chests are assigned to is where the work is done. As a developer this makes sense to me on how to implement and as a player of the game solves how things actually work. Essentially your roboports are your cell towers that pass messages between the bots. The difference being you don't care about specific areas, just named working groups. IMO this is simpler to understand.

[ske]

I think this is the right topic to add.

Problem:

When transporting items from one place to another e.g. coal to a train station or repairing a laser tower, the robot currently stays at the roboport close to the destination. This will accumulate robots in places where they are not needed while they deplete where they are needed. Even worse, this means that at the border to the enemy you will have a roboport full of construction robots but without repair packs.

Solution:

1. Define two thresholds:
- supply threshold = number of robots in network / number of roboports in network
- request threshold = number of robots in network / number of roboports in network / 2

2. If the number of robots in a roboport is below the request threshold, the roboport requests a robot from a roboport above the supply threshold.

This could also easily be extended to repair packs.

The large gap between both thresholds means, that you still have an accumulation of robots close to hotspots but you will not have total depletion of robots in other parts of the network. You will have to feed the network some more robots than without redistribution of robots. But there is nothing to configure and it will "just work" "good enough" "for amost everyone".

[Linosaurus]

The basic idea of this suggesiton is, that the player don't need to do anything, cause the roboports of one connected area will do that for you in an aceptable manner.

This sounds very useful. Like after I build a solar farm at the edge of the network, they would over time migrate back closer to the pickup chests. That would be awesome.

Usage should probably be measured by how many transports *start* in a given area. How far away it ends is doesn't really matter for the parking distribution. A gradual change is a good idea.

I don't think it should be more often with high usage. If the usage is very high, all the robots will be doing something all the time anyway. I don't think there's much use for being redistributed to some busy area if it would otherwise get an order to pick something up there a second or two later anyway. It risks adding pointless travelling.

Suggestions.
- Make the redistribution some percentage of the non-working bots, every few seconds.
- Maybe make bots that are currently redistributed available for assignment.
- Maybe change the task assignment so if there are lots of busy robots nearby, it will wait a second or two before assigning a robot that is 5+ seconds of flight time away.
- Have the overall usage statistics available on the circuit network, for automatic insertion of new ones.