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
Discussions Rules and Guidelines
Report this post
If you take the time to watch them with another roboport in the cursor, you'll see the network coloring expand when you place the roboport, then a short while later the network colors will go away again. The roboport will have the unplugged icon flashing. When you add electric to the roboport the unplugged icon will go away and the red low-power icon will come on. That won't leave until the roboport is fully recharged.
The internal buffer is 5MW, if you get technically minded.
As to the exact situation you encountered, I couldn't say what's happened from a still shot. I can tell you what happens though. When the robot gets it orders it will make a straight line from where it is to where it's supposed to go (the construction site, or the chest to get something to carry). When it gets low enough on power it will switch to a straight line from there (the instant there, not the starting there) to the nearest recharge port. (If things get busy it will sometimes pick the next, almost nearest, based on some math about the number already waiting for a recharge.) After the recharge, or after loading from a chest, it makes another straight line to the destination. Rinse and repeat.
If the bots launched from the far northwest ports and the line was much longer east, but the same distance south, you could watch the bots fly a saw tooth pattern all the way down the northern line as they moved east. The only time the newly placed, and soon "gone" roboport will matter is when it happens to be the nearest recharge at the same time the bots need a charge. And, even then it also has to have joined, even temporarily, the same network the bots started in.
They come with 10MJ when you plop them, I believe (200 secs @ 50kW discharge).
Internal buffer is 100MJ.
they are flying from my base off screen south west to the wall construction on the narrow land bridge to the east
They are low on power and have been for a while, but are not charging on the ports they are flying over or near. Instead they are going to recharge at the 3 roboports near the wall.
When you have the bot icons enabled on the minimap the bots that are active and in network are white. Bots that are orphaned from their network (by picking up their roboport while they are out of the port and in motion) display a yellow icon.
When the bots are orphaned they head to the nearest network that is currently in existence even if there isn't room for them in the roboports. If that network disappears before they arrive they will divert to the next nearest network and so on.
I suspect the reason that the roboports start charged is so that you can tell where the dashed yellow connection lines will be when its placed (saving you from having to guess or pick up and replace either roboports or power poles after they are placed). Those lines don't show up on your map if all the nearby roboports are out of range or out of power.
No, the color coding is the type. Yellow are construction and white are logistics.
I think also personal are green and spidertron are blue.
Ok, I guess that makes sense as a quick and dirty solution. Doesn't help me when placing ghosts though, so you'd think they'd make a proper UI for it.
Also maybe bots could be allowed to charge at any roboport, not just those in their network.
.....
If a Roboport isn't in their network, they can't get to it..... Keeping separate networks can be useful FYI.
It was precisely to prevent temporary connections that then get disconnected.
Bot networks aren't exactly cheap to compute. Specifically: the mesh of how roboports form networks; which cluster of ports represents an isolated network; which bots belong to which network; which chests belong to which network; etc.
I.e. the topology of the network.
If the game would place roboports with an empty initial charge in a situation where you're using robots to mass-expand in a huge factory, then you'd run into the situation where a roboport is placed; slightly charges and becomes part of the network topology; immediately gets swarmed by a mass of bots that drain its power and knock it back offline; take it out of the topology; wait for it to recharge a little bit again; it has to become part of the topology again; gets a stampede of bots again; it gets knocked out and taken out of the topology again; etc.
Now, do that times 50 or whatever amount of roboports you end up mass-placing during a huge expansion operation. Any change in the topology is expensive to compute; so it will absolutely cripple your FPS/UPS.
So an initial power charge is added there to prevent the oscillation and try to stabilize the situation.
They aren't. Buck for buck given the same level of throughput to meet, bots are the most taxing on UPS. Trains (and direct-to-train manufacturing) are cheapest; then comes belts (ever since they started taking advantage of parallel computing); and then come bots.
They are dumbed down and use very, very basic operating procedures in an effort to keep them at a manageable cost. Making them any more intelligent would make them even less efficient to compute than they already are.
I think he meant in an absolute sense, ie you can have lots of bots without dropping frame rate.
You really can't. Around 10,000 bots in any considerably sized network and you'll start noticing. Assuming a decent flight speed, average distance and taking into account carry capacity upgrades, that probably works out to < 1,000 items p/sec Less than 23 express (i.e. blue) belts worth of capacity.
The only situation warranting bots is where you're condensing a lot of one-off recipes running in single machines into a tight enclosed space where so many ingredients become involved that routing belts becomes impractical or intractable.
I.e. in malls - or hubs, if you prefer contemporary Nilausian terminology.
You're still comparing it to other transportation methods. I said in an absolute sense. I think 10k units moving around is a lot. What other games can handle that? Even a game like cities skylines can only handle around that amount of vehicles before they start despawning, and traffic is all that game is about.
That aside, in the game's development and current operations, there seem to be very few items in vanilla which "land" with the ability to begin work independently of a power source. The only other one which comes to mind is the burner inserter. That this particular situation occurs when it is not the "normal" process implies that it has been coded explicitly, and deliberately. The extra work involved in creating special code for a single purpose exception is no light burden, and not a design choice made on a whim. I'm left with the conclusion that, while I have no clue what it is, the decision, and code, solve some problem relative to the game. It might be a performance issue, or even to avoid a seeming bug in behavior. I just don't know. That there is a reason is not something I doubt. The quality of that reason is debatable, as is any other decision. Unfortunately without knowing the problem solved, the other possible solutions to that problem, and the game and developer costs or effects of each option, there's no way to debate the decision's quality. When the decisions are made by a team with a proven track record of extreme optimization and fixing four-9's level bugs, I'm inclined to trust that team's design choices for the code, and for dealing with problems in the usage of the game.
Having the opinion that you don't like how it works, and/or that you would have done something differently is actually a valid thing. There's been a few cases I've had similar thoughts, including the idea that robots should be able to recharge at "any port in a storm". Okay, keep the networks disjointed, so the bots cannot land there, or access any of the jobs or chests in the zone, but they can still get power. A thirsty man in the desert deserves a glass of water, even if he can't come in, join the table for lunch, or spend the night resting. (That's actually the law in Phoenix, Arizona - might be state law, but not exactly sure which jurisdiction created it.)
The real question remains: why is it this way? The only "real" answer has to come from the ones who made the choice, and near as I can tell, they don't come to this watering hole no more. A lively discussion can be had, for sure, and entertainment as well, by having it here. Answers, however, are mostly speculation, perhaps with some hearsay official reasoning available.
More productive would be to learn the in-game effects, and side effects, and how to use, exploit, or avoid those effects, and how to compensate for them when they happen.
Well, I'm inclined to also compare them to other transportation methods. What other purpose in the game do they replace, and therefore compare to? Yes, 10K units is a large number of units to track. At one point I was discussing the progress of my construction, in a different channel, while having in excess of 40K bots doing construction from within one network. In a similar vein, I can only guess how many entities are on my last game's map, but I'm sure it's well within the upper 6-digit range. Sure, I'm loosing FPS/UPS, but none of the issues you suggest, or report, with the other game at the low 5-digit range. Another reason I've willing to give the devs a "pass" on design choices I would otherwise question strongly.
Similarly, in an "absolute sense" I can think of no better way to compare things than with pure numbers. I pulled up my last game, with around 24k inserters, and added a bot network with some construction work. I got around 1K in the air at any given time. The debugging numbers are here to see. The 1K bots have ~10x the update time as the 24K inserters.
https://steamcommunity.com/sharedfiles/filedetails/?id=2978296820
I'm going to have to place them in the UPS-unfriendly category.