Factorio Forums

Sad_Brother wrote: Mon Mar 18, 2019 6:30 pm But for now one robot can wait for space cleared from trees by other robots before building.

That's not the same as prioritising things - it ties up the robots until the other task is done, the robot has to actually sit there and wait.

Why one robot cannot wait for space powered before placing power consumer?
Why one robot cannot wait for power pole can be connected to other poles before placing new?

They could, but what would be the point? Having the robots wait around would just mean the overall building happens slower as there's fewer active robots. Just placing things without waiting will finish sooner. It also could deadlock and prevent the build from ever completing if you don't have enough robots: you might end up with all the robots holding something and waiting for power to be hooked up, with no robots free to actually build the power poles. To solve your problem you actually would need prioritisation, not just having the robots wait.

Why construction requests cannot be sorted by some priority?

The performance impact of this has been discussed extensively in the thread this is now merged into already.

torne wrote: Tue Mar 19, 2019 3:15 pm

Sad_Brother wrote: Mon Mar 18, 2019 6:30 pm But for now one robot can wait for space cleared from trees by other robots before building.

That's not the same as prioritising things - it ties up the robots until the other task is done, the robot has to actually sit there and wait.

Not entirely accurate. A robot will not be dispatched to place down a structure until one has been assigned to at least clear out anything blocking it. Occasionally, you'll still run into a situation where robot A gets assigned to clear a tree, robot B gets assigned to place a strucuture, but then robot A gets delayed or was further away so robot B reaches their destination and has to wait. This is typically a small wait. The system does in fact already have enough intelligence already to not dispatch robots to do tasks that are reasonably expected to be undoable for the forseeable future.

torne wrote: Tue Mar 19, 2019 3:15 pm

Why one robot cannot wait for space powered before placing power consumer?
Why one robot cannot wait for power pole can be connected to other poles before placing new?

They could, but what would be the point? Having the robots wait around would just mean the overall building happens slower as there's fewer active robots. Just placing things without waiting will finish sooner. It also could deadlock and prevent the build from ever completing if you don't have enough robots: you might end up with all the robots holding something and waiting for power to be hooked up, with no robots free to actually build the power poles. To solve your problem you actually would need prioritisation, not just having the robots wait.

Base on the information above, the system could possibly be reasonably extended such that a robot will not be dispatched to place down a powered building if A: there's an order to place down the electric pole, and B: nothing has been dispatched to place down the power. By also extending this so that a power pole will not be dispatched that would connect to a powered power pole, unless that powered pole has already been dispatched or already exists. The system works... I just can't speak for if it's UPS friendly enough to be considered.

Darinth wrote: Tue Mar 19, 2019 3:44 pm

torne wrote: Tue Mar 19, 2019 3:15 pm That's not the same as prioritising things - it ties up the robots until the other task is done, the robot has to actually sit there and wait.

Not entirely accurate. A robot will not be dispatched to place down a structure until one has been assigned to at least clear out anything blocking it. Occasionally, you'll still run into a situation where robot A gets assigned to clear a tree, robot B gets assigned to place a strucuture, but then robot A gets delayed or was further away so robot B reaches their destination and has to wait. This is typically a small wait. The system does in fact already have enough intelligence already to not dispatch robots to do tasks that are reasonably expected to be undoable for the forseeable future.

Yes, I'm aware of that, but it's still not the same as prioritising things, and in some cases is still slower than simply not dispatching the robot at all until the deconstruction is done. Simply dispatching all possible deconstruction tasks before any construction tasks would be prioritisation, and would reduce wait times (but be more expensive to calculate).

Base on the information above, the system could possibly be reasonably extended such that a robot will not be dispatched to place down a powered building if A: there's an order to place down the electric pole, and B: nothing has been dispatched to place down the power. By also extending this so that a power pole will not be dispatched that would connect to a powered power pole, unless that powered pole has already been dispatched or already exists. The system works... I just can't speak for if it's UPS friendly enough to be considered.

This will slow down building overall as I said, and in many more cases than the current logic for overlapping deconstructions. Right now the building speed for an unobstructed blueprint is roughly linear in the number of robots available; by considering dependencies between entities in that way it can be linear in the number of entities in the worst case (e.g. just a line of power poles), and will have fairly significantly reduced parallelism in almost all cases. It's really not clear what the advantage of doing this would actually be. Again, to actually build in the desired order without creating artificial waiting times would require actually prioritising different entities.

And yes, it would definitely be more expensive than the current logic. Checking if a ghost is obstructed only requires looking for entities that overlap with its bounding box; checking if it will be powered once placed down requires looking for electrical network connections in a much larger area.

torne wrote: Tue Mar 19, 2019 5:54 pm

Darinth wrote: Tue Mar 19, 2019 3:44 pm

torne wrote: Tue Mar 19, 2019 3:15 pm That's not the same as prioritising things - it ties up the robots until the other task is done, the robot has to actually sit there and wait.

Not entirely accurate. A robot will not be dispatched to place down a structure until one has been assigned to at least clear out anything blocking it. Occasionally, you'll still run into a situation where robot A gets assigned to clear a tree, robot B gets assigned to place a strucuture, but then robot A gets delayed or was further away so robot B reaches their destination and has to wait. This is typically a small wait. The system does in fact already have enough intelligence already to not dispatch robots to do tasks that are reasonably expected to be undoable for the forseeable future.

Yes, I'm aware of that, but it's still not the same as prioritising things, and in some cases is still slower than simply not dispatching the robot at all until the deconstruction is done. Simply dispatching all possible deconstruction tasks before any construction tasks would be prioritisation, and would reduce wait times (but be more expensive to calculate).

I think ghost can be disabled until condition met.
I think condition can be checked even if it is more complex than obstruction.
I think such conditions should not be on all blueprints. It may be "blueprint option".

Yes, I understand it can demand more ticks. But it may be worth it.
There are other conditions possible. Like delay inserters until target ghost placed.
Conditions may be helpful in some situations where you need additional control. I just attempt to find easier way.

Sad_Brother wrote: Tue Mar 19, 2019 9:37 pm I think ghost can be disabled until condition met.
I think condition can be checked even if it is more complex than obstruction.
I think such conditions should not be on all blueprints. It may be "blueprint option".

Yes, I understand it can demand more ticks. But it may be worth it.
There are other conditions possible. Like delay inserters until target ghost placed.
Conditions may be helpful in some situations where you need additional control. I just attempt to find easier way.

Delaying inserters until the target is placed isn't necessary - built inserters which are pointing at a ghost automatically disable themselves instead of placing the item on the ground underneath the ghost, so it doesn't matter what order things get built in for correctness.

What actually are these situations where you need additional control? There might be a different way to solve it if you're more specific, and if you can't actually think of one then it's not really a good reason to ask for the feature

I did not know about inserters behaviour. It is good.

The most important case, where power network needed as soon as possible is aggressive laser turret blueprint. It is obvious.

The less important case is solar blueprint, where power connection is more important than panels and batteries.

The minor case is the blueprint, expanding power network with roboport in the middle. Unlike others here power network is the main part actually.

Sad_Brother wrote: Wed Mar 20, 2019 3:00 pm I did not know about inserters behaviour. It is good.

The most important case, where power network needed as soon as possible is aggressive laser turret blueprint. It is obvious.

The less important case is solar blueprint, where power connection is more important than panels and batteries.

The minor case is the blueprint, expanding power network with roboport in the middle. Unlike others here power network is the main part actually.

So what you are saying is: Place the damn power first!

I think this might be fixed by a mod that splits blueprints internally into 2 parts: Power and non-power. When you place a blueprint t it would first place the power sub print and wait for all power poles to get a bot (or to be build, there is no event for bot assigned, right?). The the full blueprint would be placed to build the rest.

mrvn wrote: Wed Mar 20, 2019 6:27 pmSo what you are saying is: Place the damn power first!

I think this might be fixed by a mod that splits blueprints internally into 2 parts: Power and non-power. When you place a blueprint t it would first place the power sub print and wait for all power poles to get a bot (or to be build, there is no event for bot assigned, right?). The the full blueprint would be placed to build the rest.

Not exactly that, but still... No. Your point of view is different.
I do not know mod possibilities. Probably some features absent. Let's try to build algorithm:

1. Player place the blueprint with "power priority" option. Entities, would be disabled, shown by (yellow?) colour.
2. Power poles and power consumer/producer, unable to connect to already existent powered network, placed as "disabled ghost".
3. All other ghost placed as usual.
4. Each time, power pole placed, surrounding "disabled ghosts" checked and enabled if they can get power.

Aggressive laser turrets with your algorithm will first try to place poles leaving them unguarded.
My algorithm would enable turrets as soon as power ready, so poles and robots would be guarded.
Also your algorithm suspend blueprint constructing while no poles available, but my algorithm suspend only those parts, which would not work anyway.

Sad_Brother wrote: Wed Mar 20, 2019 3:00 pm The most important case, where power network needed as soon as possible is aggressive laser turret blueprint. It is obvious.

Yeah, if you are turret creeping with lasers and robots it's somewhat helpful, but it only really makes a difference if the blueprint you're using is pretty big (multiple poles, a bunch of turrets); if you're just placing 1-3 poles surrounded by turrets then your roboport likely has enough robots to dispatch everything all at once which will mean the turrets are only unpowered for a moment at worst. The devs generally don't seem to want to encourage turret creeping and have been trying to make alternatives more viable instead, though.

The less important case is solar blueprint, where power connection is more important than panels and batteries.

It seems like that is only going to matter if you are extending your power when you are already significantly over-utilising it and there's a risk your roboport network might lose power before the job is done. If you're just expanding your solar under normal conditions, then yes, placing the electrical network first would be better, but it doesn't really matter; the whole thing is going to be built soon regardless, "missing out" on that solar production for a minute or two while you wait for the bots to come place the other parts doesn't really hurt you.

The minor case is the blueprint, expanding power network with roboport in the middle. Unlike others here power network is the main part actually.

Not sure exactly what you mean by this so can't really comment

torne wrote: Thu Mar 21, 2019 3:24 pm...

I agree all my "cases" not extremely needed that feature.
It is more like "logical convenience". I do not demand it, but it would be useful.

Sad_Brother wrote: Thu Mar 21, 2019 3:19 pm

mrvn wrote: Wed Mar 20, 2019 6:27 pmSo what you are saying is: Place the damn power first!

I think this might be fixed by a mod that splits blueprints internally into 2 parts: Power and non-power. When you place a blueprint t it would first place the power sub print and wait for all power poles to get a bot (or to be build, there is no event for bot assigned, right?). The the full blueprint would be placed to build the rest.

Not exactly that, but still... No. Your point of view is different.
I do not know mod possibilities. Probably some features absent. Let's try to build algorithm:

1. Player place the blueprint with "power priority" option. Entities, would be disabled, shown by (yellow?) colour.
2. Power poles and power consumer/producer, unable to connect to already existent powered network, placed as "disabled ghost".
3. All other ghost placed as usual.
4. Each time, power pole placed, surrounding "disabled ghosts" checked and enabled if they can get power.

Aggressive laser turrets with your algorithm will first try to place poles leaving them unguarded.
My algorithm would enable turrets as soon as power ready, so poles and robots would be guarded.
Also your algorithm suspend blueprint constructing while no poles available, but my algorithm suspend only those parts, which would not work anyway.

But that would truly slow down construction, Especially with power poles being a long distance away. Each level of power poles would add the full delay to fetch and build them before the next stuff is build. Only useful for automating turret creep and not sufficient even there. You want the next power pole only when the laser turrets are placed to protect it.

I think for that recursive blueprints would be better. You place a blueprint containing the power pole and a blueprint for the turrets. When the poles are done the turret blueprint is placed, which can include a blueprint for the next power poles again. You could easily make this 10 or 20 levels deep to creep your turrets automatically.

mrvn wrote: Thu Mar 21, 2019 4:17 pmBut that would truly slow down construction, Especially with power poles being a long distance away. Each level of power poles would add the full delay to fetch and build them before the next stuff is build. Only useful for automating turret creep and not sufficient even there. You want the next power pole only when the laser turrets are placed to protect it.

I think for that recursive blueprints would be better. You place a blueprint containing the power pole and a blueprint for the turrets. When the poles are done the turret blueprint is placed, which can include a blueprint for the next power poles again. You could easily make this 10 or 20 levels deep to creep your turrets automatically.

You may be right. But may be not. Only testing can show truth. I do not want it for all blueprints anyway.
I did not try recursive as I play without mods most time.

Yeah, I don't think having actual enforced dependencies between steps like that is a good idea even for those cases, because it slows everything down and still isn't guaranteed to do things in the order that you actually want (since different cases might reasonably want different orders).

What I think *would* be a general improvement (if the performance cost was low enough, which I suspect it isn't) is simply sorting the available ghosts by type with a set of fairly simple fixed rules and dispatching the robots in that order, *without* actually blocking/enforcing dependencies. The simplest rule for the cases mentioned here might just be "dispatch all the power poles/substations that you can first, and then dispatch everything else". (or maybe something a bit more complex where turrets are also prioritised inbetween, or something - but my point is just a small number of priority levels based on type only without caring which specific entities actually "go together").

This would not give you a strict guarantee that poles were placed before the things they are intended to power, because if the poles were coming from further away, or had run out, or so on then the other entities may end up being placed first, but it would make it very likely in most cases, and since it would never leave robots idle unnecessarily it would never slow down overall build times (in terms of in-game time required to complete building a blueprint, not in terms of real-world time that is affected by CPU usage).

I don't remember offhand how much the developers have explained about how the ghost building process is implemented, so can't say too much about what the CPU cost of doing this would actually be. If ghosts are just one big queue in memory that's processed in order then adding a few fixed priority levels would be pretty straightforward: just have a couple of queues and decide which queue the ghost goes into at the time that it's created. That would still increase the cost of traversing the lists though (especially since factorio in general has to care about cache hit rates and other hairy low level details due to being memory-bandwidth-constrained). If the structure is something else, it might be much harder.

hi,

i don't know if somebody have already give the idea for the first issue, is it possible to have a way to set our personnal area for the robot? On the roboport icon oe near from it, we can chose the size of the area with a cursor, and normally with the good use the "order" issue can be resolve? (the only way actually is the number of personnal roboport, but number of bot take a hit)

Thanks for makin the game better, bye

I'm working very often with many robots (should be renamed to drones).
When i place a blueprint most of the time the robots will place objects in the ineffective way.
For example a grid of 4 robot hangars connected via powerlines and in their area the accumulators. When i set this the robots build the accumulators at first and then randomly any other of the blueprint (seems to be a problem with "what is the nearest object i can reach to the target").
It should work (in my opinion) that they set reachable power lines at first followed by reachable robot hangars. If that is done they can build everything else so the work stations or whatever can immediately get to work without waiting for power.

Ok, but my sug was mentioned to local robots, not personal.

Yeah I noticed the small difference, hence the "almost". However, all the discussion (and especially the devs' answers and explainations) also apply to your suggestion, I think. That's why I felt it would be appropriate to merge your suggestion in this topic.

JohnyDL wrote: Sun Oct 15, 2017 10:29 am Suicide Junkie: so instead of one list you propose several lists and you do several times as much work, I'm not saying this is unfeasible but it's still more work and more bugs to track and there are conflicts, is the way you'd sort your build order the same as mine, I mean if I'm deconstructing the first thing I'd want rid of is power, I'm deconstructing it don't do more things stop them stop them all stop them now :p

So more work, not saying this is as bad as ordering by distance but it's still work.

If you're checking all ghosts it's far from none trivial. But it's fairly trivial if you're only doing 20 checks rather than 1. But it isn't free.

Check if ghost is within range of personal roboports, easy as that. Um No. For the nth time

there is no shortcuts to finding out if a ghost is in range of a personal roboport you have to do a surface scan of every tile in the roboports range this takes a lot of computational power and time, and you have to do it every tick

With the topic bumped I wanted to address this.

First half is silly.
Multiple lists isn't more work per tick unless you want it to be. It is a different ordering of ghosts to check. If you have no solar panels to deploy, check for a different category of item next tick instead, before coming back around to solar panels later.
Disagreements as to which categories should be priortized is legit, but so are disagreements as to what technology to research first.

Second is confused. This isn't asking WHICH IS CLOSER. The algorithm already has to know if the ghost is in range of a personal roboport to know if the associated bots are valid for the job.
If there are multiple roboports in range, check personals first. And if the player has set bogart mode, then don't even bother to look for other options.