Construction robots

[Omnifarious]

Some of the things I'm requesting be built never get built. I know about construction zones and logistics chests. That doesn't seem to be the issue.

It mostly happens when I'm building roboports themselves, and when I blueprint things in anticipation of the blueprinted items becoming part of a roboport's construction zone in the near future when the roboport is built.

I'm in the process of walling in a huge are of the map. I've gotten tired of constantly beating back the biters, and have just picked a gigantic area and I'm walling it in so they can't get in.

As part of that, I'm extending my roboport network using blueprinting from space. I'll clear out all the biters from a large (using nukes on the larger nests) and then blueprint in a whole bunch of new roboports and walls.

This had been working, though it's also been taking forever sometimes because the area I'm working on is far from the roboport hub at my main base and all of its storage chests and all of the passive provider chests also at my main base.

But for some reason it's stopped working. Roboports sit there as ghosts forever, and there appear to be no construction bots on the map even attempting to build them. Even ghosts that are within a construction zone sit there forlornly.

It seemed to start not long after I created a blueprint for roboport network nodes that included power and had nodes at the maximum distance possible for the network links to work. I had a blueprint before that didn't include power. But when I added power to the blueprint I started seeing this problem.

My guess is that maybe there's a time limit on ghosts before they stop trying to find a construction robot to construct them? But when I erase things that have been there forever and put them back (now a part of a construction zone) they still sit there as ghosts.

I'm running the last 0.15.x. Has anybody else seen this?

[KatherineOfSky]

Are your Roboports close enough that their logistics zones connect? (The orange square inside the green one). The orange squares need to touch boundaries to be able to share items from the main logistics zone in the base.

If this is not the issue, please provide a screenshot.

(Also, blueprints will stay ghosts if placed by the player indefinitely. The only ghosts that expire are those items that are destroyed -- they have little purple bars indicating the length of time they have left)/

[Omnifarious]

Originally posted by KatherineOfSky:

Are your Roboports close enough that their logistics zones connect? (The orange square inside the green one). The orange squares need to touch boundaries to be able to share items from the main logistics zone in the base.

If this is not the issue, please provide a screenshot.

Yes indeed. I could've supplied that screenshot. But I felt that screen shots showing my entire map and a logistic report screen showing that I have exactly two logistics networks (my personal roboport and all the roboports on the map) would be more helpful for other reasons, and more convincing.

Here is a screenshot showing one such persistent ghost sitting in the construction zone of a roboport:

http://steamcommunity.com/sharedfiles/filedetails/?id=1086870140

Here is another showing that yes, indeed, I have only one logistics network, and so the roboport it was sitting in the construction zone of must be connected to all the others:

http://steamcommunity.com/sharedfiles/filedetails/?id=1086870694

And here is a third showing a screen shot of my map with electric network coverage and logistics network coverage turned on. The persistent ghost is near the upper left corner of the map. My main base with all the chests is where the electrical network gets especially dense and tangled. I used a main bus design (arrived at independently, before I read about them) but I implemented it poorly. One lane for each product and they all run side by side so splitting off a lane or two for a production line is really hard.

http://steamcommunity.com/sharedfiles/filedetails/?id=1086875511

That ghost has been there for over ten minutes of gameplay.

One other data point is that I've lost a lot of construction and logistics robots. The biters are fond of sneaking into my territory and setting up a base that seems to be mainly artillery (10 worms, 2 spawners, for example) to shoot down all of my robots. I've rebuilt. I have logic set up to keep my construction robot level at at least a third of my logistics robot level. I rebuilt and have plenty as you can see by the screenshot showing the ghost.

Also, I have 12 roboports and 112 big electric poles available to my logistics network. Those are both set up to build on demand.

Originally posted by KatherineOfSky:

(Also, blueprints will stay ghosts if placed by the player indefinitely. The only ghosts that expire are those items that are destroyed -- they have little purple bars indicating the length of time they have left)/

Good to know. I was wondering about that.

[KatherineOfSky]

Looking at the map, I would assume that factory is in the lower left area.... and to get to the upper right, bots would have to travel over biter-infested territory, at super slow speeds, so one thought is that they may be getting destroyed by passing attack parties of biters. The other conclusion -- they're just moving super slowly since they have to go so far away. (The nearest roboports are very far from their flight path).

IMO, your network is waaaaaaaay too large. If you want to have a functional and efficient system, it's wise to separate your roboport networks into discrete zones. (E.g. for wall repair/construction, I have a single network for each segment -- east, north, west, south, etc., depending on how they are divided by the lakes I connect together). To each of these networks, I deliver materials by train. To prevent biters from attacking the bots, all corners are convex within a segment.

[piccolo255]

To expand a bit on what Katherine said, bots fly in a straight path from the pickup to the construction. Your network is very irregular, so depending on source and target locations, the bots have to fly over large areas with no roboports nearby.

I'm not sure if they keep flying when their energy depletes or divert to the nearest roboport for a recharge, but in either case, it's an enormous slowdown. They'll likely take way longer than ~10 minutes to arrive.

AFAIK, you could turn on the both pathing display in the debug menu (F4) and trace the line back from the destination to find the dispatched bot. Following it for a bit should help with diagnosis.

I'd suggest either splitting the network as Katherine said, or clearing the in-between areas, walling them off, and connecting them with roboports, even if you otherwise don't need that space. Keep your roboport coverage convex!

[juliejayne]

They do keep flying, but they get slower and slower, and if that is over enemy territory, then they are likely to be biter bait.

[Omnifarious]

Originally posted by KatherineOfSky:

Looking at the map, I would assume that factory is in the lower left area.... and to get to the upper right, bots would have to travel over biter-infested territory, at super slow speeds, so one thought is that they may be getting destroyed by passing attack parties of biters. The other conclusion -- they're just moving super slowly since they have to go so far away. (The nearest roboports are very far from their flight path).

IMO, your network is waaaaaaaay too large. If you want to have a functional and efficient system, it's wise to separate your roboport networks into discrete zones. (E.g. for wall repair/construction, I have a single network for each segment -- east, north, west, south, etc., depending on how they are divided by the lakes I connect together). To each of these networks, I deliver materials by train. To prevent biters from attacking the bots, all corners are convex within a segment.

The super-slow robot theory is a good one, and it's something I've noticed, which is why I started tiling roboports internally. And making sure your base is convex is also an excellent idea, and something I've also realized.

But I've dealt with both problems before, and so this current issue doesn't seem like either of these. 10 minutes was an extremely conservative estimate. It's more like an hour or more. And I've built other things with construction robots in nearby areas of the base and they've built fine (though at a considerable delay).

I suspect it's a combination of the robots originally tasked to do the building being shot down and the distance involved.

To be clear, my robots are not currently getting shot down. I've stayed very alert to that kind of thing and have quickly gone over to kill off the offending biter nests. But, at the time I originally placed those ghosts, some robots were shot down.

Next game I'll have to consider a base design in which there is a train that runs around loaded with one or two stacks of every single item and loops around keeping each of the logistics zones topped off. Handling bulk commodities (iron plates, green circuits, etc...) that way won't work. But, handling all the small batch items (assemblers, roboports, water pumps, etc..) that way could. I really don't want to start to have to worry about what item I can request where on the map.

I could probably even make some logic to automatically pull in excess items to load on the train. I'll base it on the system I developed for automatically burning excess wood by feeding it into my power generation system in place of coal when the excess has gotten over a certain amount.

Originally posted by piccolo255:

AFAIK, you could turn on the both pathing display in the debug menu (F4) and trace the line back from the destination to find the dispatched bot. Following it for a bit should help with diagnosis.

Thank you. I've been looking for something a bit better than trying to find the robots on the map and following them by hand.

[KatherineOfSky]

Something that I do is create a "building train" -- a train that I take to build outposts, etc. I have around 5 cars of goods ranging from walls to roboports to belts, etc. -- basically materials for different outposts. I feed it with requester chests at the main base, and so even if I am sort of materials, I can send it back, and summon it to me again, and it'll bring me what I need. (This negates the need for a gigantic roboport network).

For self-constructing solar areas, I use a separate robonetwork, and deliver materials by train. A solar field tends to be vast, so I don't want those 3k robots covering lengthy distances to do stuff in the main base, for relative efficiency.

Just some thoughts for your future base :-)

[stlyau]

First, Kat, loved your videos and lovely voice. Learned a lot from them.

Second, the bigger issue is that Construction Bots will attempt to construct ghosted items in the order they were "queue'd" up via when it was ghosted. In conjunction with this, it doesn't seem right that Bots can't deliver logisticly or build if not in the zone of a roboport or personal port, but have no problem traveling outside of these zones to get to it's "target" location. IMHO, if the Bots won't do their jobs unless inside the zones, then they shouldn't be traveling unless inside it as well even if this means they take a longer route around obstacles such as large lakes.

My brother and I are playing a MP game together and had just did an expansion. The ConBots as you stated, kept trying to get to their target locations via going over biter territory. Before we knew it, almost all the ConBots were toast and we had to go expanding twice more. Still waiting for the ConBots to get back up into a respectable quantity.

[KatherineOfSky]

Thanks @Stlyau! Glad you're enjoying the content!

As to the robot behaviour -- it's intended. Think of it as part of the puzzle aspect of the game. You can liken it to the Flamethrower Turrets -- if you place them in the middle of the base when biters come calling, your base will burn to the ground! Same with robots -- networks require planning to not send defenseless bots over enemy territory.

Bots fly in a straight line because it's most fuel efficient.

It's been brought up several times over the last year -- people requesting a feature where bots fly along the roboport connections -- so the devs are aware. It's intended behaviour.

[Omnifarious]

The item finally built! On it's own. After sitting there for nearly an hour. My only thought is that the bot assigned to build it spent almost the entire trip in 'tired' mode. I've been watching for tired bots and building out my roboport grid so that there's a convenient roboport not too far away just when they're about to need a recharge. Doing that cleverly will have the global effect of guiding robots onto 'fast lanes' where there's a recharge station every step of the journey.

[stlyau]

Originally posted by KatherineOfSky:

so the devs are aware. It's intended behaviour.

Typical gaming mentality.... "Working as intended!!!" LMAO

Didn't say it was wrong, just that it makes for a really annoying mechanic on large bases.

P.S. I couldn't help but laugh everytime during beginning of Tasty Vanilla series when you kept wondering why everything was so expensive and bus was anemic, having forgotten you set options to expensive during start-up. Sorry :)

[KatherineOfSky]

Originally posted by stlyau:

Typical gaming mentality.... "Working as intended!!!" LMAO

Didn't say it was wrong, just that it makes for a really annoying mechanic on large bases.

P.S. I couldn't help but laugh everytime during beginning of Tasty Vanilla series when you kept wondering why everything was so expensive and bus was anemic, having forgotten you set options to expensive during start-up. Sorry :)

It's not a mentality -- I gave you the reasons why it is the way it is -- it's part of the puzzle mechanic and strategy of the game. If it's annoying, then find a better system! :P

To be fair, I started the game the very day the new patch came out, and no one knew what to expect... It may seem silly now, many months later, when we all have the benefit of hindsight, but then it was going into unexplored territory!

[Varenvel The Festive Dinosaur]

Roboports should never be used at big ranges you should use inventory robots/items then system , orhave them in inventory or trains(especialy if you got mods with logistic trains) and use that instead

My chart usualy is:
Belts: short-medium-semi long
Roboports short-medium
Trains: long-infinity

[Omnifarious]

Originally posted by Varenvel:

Roboports should never be used at big ranges you should use inventory robots/items then system , orhave them in inventory or trains(especialy if you got mods with logistic trains) and use that instead

That makes sense. I'm going to try something in my next game. This time I have a main hub where all the passive provider chests are, and all of the storage chests.

Now, handling storage chests is going to be interesting because of how the game allocates items to chests. But I think maybe I'm going to try a system where I again only have one logistics network, but I use sophisticated set of logic and trains to try to spread things around so that stuff I ask for is always reasonably close to me.

I just want to always be able to request something and have it show up, no matter what it is. And I always want to be able to plop down a requester chest and have it fill with what it's asking for.

If I use a train system to try to balance stuff around, then, most of the time, when I plop down a chest the network will find what it's asking for close by.

I'm going to have to run some experiments with storage chests though. When it wants to put something in one, does it look for the closest chest that already contains the item? Or does it always pick the chest with the most of the item?

If it's the latter, then I'll have to centralize storage chests and just deal with the fact everything will go back to the base, and then just distribute it back out with trains.

If it's the former, maybe I can keep storage chests in various hubs seeded with things and so stuff won't have to go all the way back to base.

[stlyau]

I believe it goes Active, Storage, Passive on order of containment to Request. I know Actives instantly go into the system, which leads to items in them going straight to any open slots in Storage first and foremost, so try to stay away from them. There is also the issue of a continueous loop if a Request has an inserter taking items from it and putting into a Passive near it, for example, Request at one end of belt putting things on while Passive on other taking off extras, Request would then take them back if not at cap limit set. This can also happen if for some reason you have the inserter going from Request (distance request) directly into Passive for personal nearby requests. LogBots will just keep bouncing back and forth between the two boxes.

I try to stick to Passives. If I decide to mine a smaller dimension mineral patch, depending on size of patch, I tend to place at least 1 Passive with Stack Inserter (2 Passives with second getting fed by Stack Filter Inserter if miner is on that dual resource merge) as I have Requests for loose ores, stone, coal by something that will use it. I know this is OCD, but there are times I don't wanna just cover up resources. Miners with 3 Spd3, usually eat through a couple 100k patch in couple hours maximum depending on how much is getting taken away by Request.

The problem with Long Term Storage chests is that there is no good way to keep them specificly sorted. The Passive-Request loop can occur just as easily with Storage-Request. LT Storage will be the first place anything the ConBots/LogBots are carrying will go if you don't have the inventory room or just slighting step outside of the orange Logistics zone of roboport network.

I'm not really sure on distance or quantity factor on priority of Request.