Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
If you are producing enough (because you have no control over where they distribute first among the chests that request an item) in a compact layout (which is easier to do when there are no belts involved) they will shine.
Of course you can also opt to make a single large network and throw in many bots to somewhat overcome the lower efficiency when the distances grow, there are quite a few people that like using them like that as well.
Basically, trains are the best by far for long distances, belts are pretty good at short and medium distances and you have a lot of control over them as well as more visual feedback on how your factory is doing, and logistics bots are amazing at short distances.
Like everything else in this game, experiment a bit with them to see how they work and decide how you want to use them because even the goal is designing your own factory so if you like having thousands of drones in a single large network because it's easy to setup and you enjoy watching them fly everywhere, go for it.
Would an okay usecase of example be the Drone frames? I produce them on the completly other side of my factory to where I need them to produce research bottles. Would it be smart to use drones for that instead of a really long belt for just 1 production line?
The issue would be that it will be harder to work with multiple networks for short distances if you already have one doing a line over your factory.
But that's perfectly fine, it's not like how you use them for right now will remain how you will use them in future maps.
Since you have an idea on how to use them for now, go for it as it is part of the experimentation that will lead you to pick how you want to use them in the future as well.
You could use them to move whatever you want, people do all kinds of things with them and the game keeps up with it, but personally I don't think it's the best idea to put them in your science production pipeline. That's something you want moving in high volume, continuously at all times. Those robots will always be busy, compared to robots servicing a construction hub where you build up a buffer of certain items and then stop.
A robot's internal battery holds 1.5 MJ. The basic movement speed of logistic robots is 0.05 tiles/tick (3 tiles per second) when they have enough power. When out of power, robots move at 20% of their current normal travel speed. This movement speed can be increased infinitely by the worker robot speed research. When flying they use 5 KJ per tile and 3 KW per second while hovering. It takes 1.5 seconds for a robot to recharge at a roboport and each roboport has 4 charging ports.
With those things in mind I limit my self to 50-250 robots per roboport and a total network distance of 200-250 tiles. You can separate networks by having robots deliver to a requester chest on the extreme edge of one net work and then use a stack insterter to move materials over a net work gap and have a different network of robots move the goods further. You just have to make sure that you have gaps in the networks.
Most people think that logistic bots move things in a round robin style but its actually more of a weighted round robin style based on the number if items requested per chest in the network. For example if you have chests in the net work requesting 3 nuclear fuel for trains, 4,800 copper plates (the maximum amount for one chest), and 2,400 copper ore (the maximum amount for one chest) the chests that have fewer items requested will be weighted in least to most requested items order. All goods will get moved but a higher percent of robots per item will be assigned to the things that are lowest requested. This causes the round robin system to fail to deliver items smoothly.
Here are some examples:
In this screen shot I have items requested as stated above, 3 for nuclear fuel, 4,800 for copper plates and 2,400 for copper ore as you can see the robots don't prioritize things properly and items are distributed unevenly.
The robots are taking ore unevenly. Taking it from chests that are nearer first and unevenly.
https://steamcommunity.com/sharedfiles/filedetails/?id=2385270665
and they are placing unevenly. The rear 3 cars on the north train are full and storage is backed up. The front car is not yet full and storage is empty. The other train is also uneven though none of the cars or chests are full yet.
https://steamcommunity.com/sharedfiles/filedetails/?id=2385271093
The smelters also have a similar issue. Some of the copper ore requester chests are empty and some of the copper plate chests are packed full.
https://steamcommunity.com/sharedfiles/filedetails/?id=2385270826
(and yes I have sufficient robots. there are ~500 idle at the time these screen shots were taken.)
I went through and switched all the copper plate requester chests to request the same number of copper plates as copper ore (2,400) which re-balanced their weight and smoothed out distribution. In about 3 minutes the jammed mess smoothed out and I went from having 500 robots idle to having 750 robots idle.
https://steamcommunity.com/sharedfiles/filedetails/?id=2386206436
https://steamcommunity.com/sharedfiles/filedetails/?id=2386205694
They perform very well in small self-enclosed networks with limited, predictable tasks. And they perform well with low-quantity; low-occurrence tasks within a big 'global' network. Very fire-and-forget. But they tend to pretty much crash and burn on high-throughput intermixed tasks at other scales, unless you babysit and fine-tune them according to the undocumented internal machinations of the game.
A not yet mentioned problem with bots is that should you use self-enclosed 'local' networks as opposed to one big global network, bots can - under certain conditions - 'get lost' by being reassigned to another network.
This can happen a lot when your local networks have irregular shapes.
E.g. given an area:
should a bot travel from the left tip of area A to the right tip of area A it has to cross over the airspace of area B. Should it need to recharge while it is over area B, then it will dock with a roboport in area B. If at that time the task it was attempting to fulfill is either cancelled or fulfilled by another bot or the player, then it will remain in area B.
It doesn't matter if half of your assemblers are idle 100% of the time or all of your assemblers are idle 50% of the time - the only solution is to produce more stuff.