Factorio Forums

I suggest that when robots launch out of a roboport, they take energy from the buffer when launching. When they land again after a job, they drop off any excess energy (up to the roboport's capacity) and just dock instantly. They will not need to recharge before docking.

Optionally, add a secondary power buffer of unlimited size to store any power dropped off, which is used up first.

The expected effect.

-Robots take off a bit slower, a large group then a stream as power builds back up.
-Robots never get stuck trying to charge before docking, they only charge without docking during long jobs.


Without the secondary buffer, power consumption will increase significantly, so it is recommended.

What do you want to improve with that?

Robots would stop hovering around roboports to charge before docking, resulting in massive power use, but would rather charge first, resulting in them going as fast as your power can support. Effectively making it so that robots launch only if there is enough energy for them to run, instead of 1,000+ of them launching and then taking 5-10 minutes after the job finishes waiting to dock. I just think it would be more reasonable.

Lore-Wise, It would make more sense that the robots actually charge up before launching, rather than magically having full energy when in item form (implying that when you mine one it gains full energy)

I am also against the idea of robots charging before landing. I think they should charge inside a roboport just fine preventing this mess after a job is done.
The most annoying is the charging of personal robots as they often force you to stand still and wait when all of them finish charging as if you move they will most likely lose all their charge and generally follow you slowly for ages.
While the idea of returning the charge can work, I would not give it a go as you don't want to limit the rate at which robots leave roboport.
I would introduce a "charging bay" inside a roboport where robots actually charge while being unable to perform actions. When they charge they will move to a normal robot storage.
And for field recharge I would add the charging pads which would have no docking space.

Good point.

Secondary buffer. Capacity is total capacity of all currently docked robots. When more robots are added or redock, increase capacity and take energy from the network. When they dock, excess energy is readded, and since the capacity increases, no energy will be lost.

This is a simplification of having each robot having energy and capacity when docked, instead combining it all into two values.

Same changes as original post, but the internal buffer ensures no extra downtime.

If the internal buffer isn't full, or lacks enough power to launch robots, then it will wait, but since it can always hold enough for launching all robots, there isn't an issue.

Do you understand why the roboport has an internal buffer?

?
I thought it was consumed when robots were charging. Like every other machine, it has an internal buffer, which is an intermediary between the power network and the function the machine performs.

----

The end goal, where I am standing, is to let robots dock immediately after reaching the roboport. Exactly how this would be done isn't important to the player, which is what really matters. all that matters is that the robots don't hover around roboports trying to charge hopelessly, if it can be avoided.

I came up with an idea that made sense, posted it. Conversation occurred and I simplified the idea to the original goal. Which method, if any is used isn't important, just that the robots getting stuck trying to charge before docking was a problem I wanted to avoid.

Options
-Robot items have charge. Kinda like Ammo or Repair kits or Science potions. Would require a way to manipulate the stacks without causing robots to suddenly stop existing because of low charge stack merging.
-Two sets of slots for robots. Uncharge and charged. Instantly drain charge when possible to move robots from uncharged to charged. On Docking, add energy to the buffer, or use it first to transform from unpowered to powered version.
-Secondary Buffer. Represent total energy stored over all docked robots, Capacity is capacity of all docked robots, and charges from the static internal buffer that already exists. Launched robots would consume power from this buffer (and reduce the capacity) so would have their initial power input.

----

As a side note, Robots tend to queue at the closest roboport and ignore other roboports not too far away which lack even 4 robots charging. They do spread out somewhat, but only to a minor extent. An alteration to the decision-making would help, and would stack with this mechanic to make it all work better.

It is really difficult to compare the internal accu of other devices with a roboport. The roboport has hundreds (?) of time more accu power. No, that would be really difficult, cause the consumption for charging is much above the needed power.
No, what makes the charge so important is, that the robots can be charged, when power is down. It's enough power for SOME charges. And enough power to keep the robotic network open for SOME time.

And when is the power down for a roboport? Not only when you have no power! But when you deconstruct stuff.
That's the biggest reason for the charge in the roboport: that everything can be deconstructed, even if the power has already been taken away.

And to the other behavior of charging before they park: that has also reasons.
First the learning effect: new players need to learn what happens with the bots. If they would charge inside the roboport it would be not visible for the player and he would not understand later behavior, that they need to recharge after a while in the air. And such stuff.
And why should they don't do that also? Cause the roboport is in reality two devices, that can be separated: a charger and the parking. For example: there are several mods that provider a pure charger roboport without parking functionality. And there are some suggestions that want to have such a roboport included.

I also still don't see much added game-value in this: the robots jam before parking. So what?
I mean: what is the improvement? Is it really worth? Think about it, in the sense of what needs to be tweaked also as you know now some reasons why the roboport works as it works.

And last argument: jam at the roboports is for me a sign to change something. For example using belts for bulk transport. Removing some robots from your network. And so on. That can be seen as part of the game. It's not a sign to change robotport behavior.

ssilk wrote:I also still don't see much added game-value in this: the robots jam before parking. So what?
I mean: what is the improvement? Is it really worth? Think about it, in the sense of what needs to be tweaked also as you know now some reasons why the roboport works as it works.

And last argument: jam at the roboports is for me a sign to change something. For example using belts for bulk transport. Removing some robots from your network. And so on. That can be seen as part of the game. It's not a sign to change robotport behavior.

I have mentioned how this behaviour is bad for personal roboport. It is not that bad for stationary ones and can be greatly improved by using some charge pads around roboport and that is not in vanilla.

In older versions, when robots ran out of power, they DIED!!!

When you look at robots from that perspective, and how they only slow down now when they run out of charge now, There's nothing wrong with the current system.

Ranakastrasz wrote:I suggest that when robots launch out of a roboport, they take energy from the buffer when launching. When they land again after a job, they drop off any excess energy (up to the roboport's capacity) and just dock instantly. They will not need to recharge before docking.

Optionally, add a secondary power buffer of unlimited size to store any power dropped off, which is used up first.

The expected effect.

-Robots take off a bit slower, a large group then a stream as power builds back up.
-Robots never get stuck trying to charge before docking, they only charge without docking during long jobs.


Without the secondary buffer, power consumption will increase significantly, so it is recommended.

Edit: My comment is primarily for the regular roboport, not the personal roboport (where I shamelessly mine my construction bots to restore charge )

Would be helpful if you could elaborate on what exactly you are trying to achieve with this change because, imo, this would be a massive nerf to burst throughput given by robots in the current state of the game.

Let's take a train station as an example. Let's say we rely on 1k robots to unload trains as they come in (aka moving items from passive providers into nearby requesters). In the current state of the game, the 1k robots would be launched within seconds and go about their job. After the items are moved as necessary, the robots will go back to roboport to charge and will repeat this cycle all over again for the next train. The ability of the system to "unleash" 1k robots nearly instantaneously is what allows robots to provide massive throughput. Having the robots be deployed more slowly or limiting the deployed robots based on roboport buffer charge would simply cut throughput.

The aesthetics of a lot of robots charging is not great but I think the more important question is how well the bots are serving their role (of providing throughput) prior to charging.

I dropped that part of the suggestion further down after some discussion.

The robots would charge in the roboport when you first put them in and after docking, so there would in fact still be the huge number of robots able to take off immediately. It will only delay them if you just built a new roboport or put a ton of new robots in.


As for the personal roboport, this is more important there, and is honestly what I was thinking of when I made the suggestion, But I couldn't see a reason it shouldn't just be a robot mechanics change rather than a personal roboport specific change.

There is a reason, that the robots are not taking off all at one time: The game would freeze/stutter. There is a limit for of up to 3 tasks/orders robots are given per tick per logistic network (=up to 3 robots can get an order per tick, that is 180 orders per second).

ssilk wrote:There is a reason, that the robots are not taking off all at one time: The game would freeze/stutter. There is a limit for of up to 3 tasks/orders robots are given per tick per logistic network (=up to 3 robots can get an order per tick, that is 180 orders per second).

That explains the snakes. When I said immediately, I meant as quickly as is it does now. I kinda thought it was one per tick, not 3, admittedly.