Factorio Forums

Here is mine. Seems to be over-kill and it's a bit resource intensive. Still, it's quite fun to see waves of biters crash and burn on these walls.

Blueprint string:

Very nice! That action shot is awesome! It would make a nice desktop background. I just recently instituted a similar train resupply to my perimeter defenses. Besides ammo and repair kits, I also include extra walls and turrets too so that the construction robots can replace them if they are destroyed. Also I have a chest which inserts construction bots into that isolated logistics network in case they get destroyed as well (which they like to do as they are repairing a wall as 20 biters are trying to break through.)

Also I have a chest which inserts construction bots into that isolated logistics network in case they get destroyed as well (which they like to do as they are repairing a wall as 20 biters are trying to break through.)

Wait ... how? Do you keep each roboport out of range of its neighbor? I am in a pickle about this - if I isolate the roboports from each other that leaves a gap where they can't repair walls, but if I connect them all together I can't use the circuit network to [partly] fill a roboport because it reports ALL the logi and construction bots in the network. I don't see how to feed the ports from chests aside from letting the inserters put 300 bots in each port and hoping that they have the right mix of logi and construction. I had the same problem with tools. My work-around was to put the tools in a purple chest (I think yellow or red would work too) - the bots get the tools when they need them and each bot brings a leftover tool back to the port. This causes a slow migration of tools from the chests to the roboports, which the train can keep up with. Not ideal but good enough I suppose. Another problem I am having with this massive inter-connected perimeter logi network is that weird stuff sometimes happens - like when a bot randomly (?) decides its sacred mission is to resupply a requester chest 500 tiles away while the local bots just sit in their ports eating bonbons (even when the local red chest is full of ammo). It often happens that local bots will not lift a finger to fill a chest in their local area while far away bots drift in to do it. What gives? Have you found a solution to this problem?

I sometimes wonder if this is possible without trains - just feed one station and let the logi bots sort it out. But I worry that they might take a shortcut through the huge no-man's land in the center of the map. Please don't say "use belts" -- I just ... can't. I love the belts but not for this.

Beeblebrox wrote:Wait ... how? Do you keep each roboport out of range of its neighbor? I am in a pickle about this - if I isolate the roboports from each other that leaves a gap where they can't repair walls, but if I connect them all together I can't use the circuit network to [partly] fill a roboport because it reports ALL the logi and construction bots in the network.

Well I don't know if this answers your question, but the green area surrounding each roboport is for the construction bots (i.e. the ones that do the repairing) and the orange is for the logistics bots. And the roboports' logistics network only get connected to each other if the orange field is touching or overlapping, since then the logistics bots can reach the ports. HTH

Also, solid defence. Keep it up

Yep it sure does. I'm embarrassed that I didn't know this, after a few hundred hours of game time, but I suppose that's part of the reason I like it so much. Thank you! Moving the ports a tile or two farther apart fixes all the problems - no more lazy bots, no bot migration. Use the Y and T outputs from the roboport to limit the red inserters. Perfect! Here is the new print, in case anyone cares:
EDIT: ps - I noticed after doing this that I don't need the green circuit for the train stop - I can just set the train wait condition to "no activity" which triggers after the chests are full (only the first slot is available in each chest, except for ammo which has 4 slots open).

I have my walls pushed out away from my main factory so that my defense perimeter roboport construction zones do not overlap with the factory area roboports. Also I have 5 separate zones along my walls so that bots within these zones do not intermingle. Each of these zones has 50 of its own bots. If a bot should be destroyed the train brings in a new construction bot to replace it. This way there are always 50 bots in each of these sectors.

You do need to have a single tile in between roboport zones to do this so, yes, there is one tile of a wall that will not get repaired.

I get frustrated with bot behavior as well!!!!!!!

I wish you could shrink the size of a roboports construction area to make this easier.

Actually no - check out Tubbles' post. Everything in the green zone gets repaired so you can actually separate roboports by a complete orange zone and still have touching green zones.

Beeblebrox wrote:Actually no - check out Tubbles' post. Everything in the green zone gets repaired so you can actually separate roboports by a complete orange zone and still have touching green zones.

Maybe I don't understand correctly. I know the orange area is the "logistics area" meaning the logistics bots will only operate in this area and you can connect orange areas so they will travel everywhere in this area. And the green area is the construction boundaries which the construction bots can operate within. If you connect green areas though won't construction bots drift away from the area which you want to contain them?

Ok, I just experimented and you're right. Green construction areas can be completely overlapping and a construction bot will only go so far as his roboport's range and then he will return to his logistics network (as long as the orange areas aren't touching). Great! Now I have one tile gaps all over my perimeter lmao!

Sorry I thought you meant you had a single tile separating orange zones when you said

You do need to have a single tile in between roboport zones to do this so, yes, there is one tile of a wall that will not get repaired.

I haven't noticed a construction bot migration problem.

Do you have a spiffy way to request a train if your bot count gets low?

If a bot should be destroyed the train brings in a new construction bot to replace it.

My trains are stupid - they stop at every station whether the station needs supplies or not, and all the stations have the same (alternating) name.

Beeblebrox wrote:Do you have a spiffy way to request a train if your bot count gets low?

No, but it is easy to filter one slot in a car for construction bots and use circuit networks to unload them when needed.

Beeblebrox wrote:
Do you have a spiffy way to request a train if your bot count gets low?

My trains are stupid - they stop at every station whether the station needs supplies or not, and all the stations have the same (alternating) name.

(This is all done with version 13.15)Have the train wait at its resupply point. Hook up the resupply train stop to the circuit network of the requesting area. In the train's schedule tell it to wait at the resupply point until the robot count drops below a certain number or ammo drops below a certain number or whatever you'd like. It will wait there until the robot count drops below your specified number then it will go deliver the robot or whatever. Have it delivered to a chest with an inserter that will place the robot into the roboport. If you don't want this train to stop at every stop then you need a dedicated train per stop. For example, I have my perimeter divided into five sectors each with its own train to resupply it.

If you only wanted to have one train, you could do the same thing. Yes, it would stop at every stop, but you could set the condition that it only stops there for a second (so long as that sector doesn't need supplies) before moving back to the resupply point and waiting there until needed again.

I'm trying to determine the main reason you're wanting them isolated... Am I correct in understanding that it's because you don't want them in a giant network because of them flying across the map? You're wanting to contain the bots to a certain area?

I've really had no problems with a large network keeping up with itself. So I do things a little differently. I'll drop some pics and explanation in a bit later. I have to prepare the how-to images.

My standard maintainable outpost (which gets regular engineering / RAC train runs) is guarded by a projectile turret wall (I've not yet incorporated flame turrets, but after the original post, I certainly want to). It's based on a standard blueprint (sorry don't have the string) that uses two roboports as the alignment keys and a standard "corner" blueprint that is rotatable for any corner. These wall blueprints are tileable and have the requester chest for the ammunition just inside of logistics range (it's entirely bot-maintained).

The entire outpost is "manned" (heh) by a logistics network with construction and logistics bots. I maintain the bot levels with two requester chests (one each set to a type of bot) connected to a roboport that reads the roboport bot counts.

A regular train maintains stockpiles of needed goods (bots, walls, repair packs, etc) via a combinator setup (first listed in an FFF, as I recall).

- A roboport, set to output network contents, is connected to the input of an arithmetic combinator. This creates an output containing the negative quantity of all items in the logistics network.

- One or more constant combinators, connected and set to output positive signals, indicate the quantities you wish to maintain within the logistics network. These are connected to the output of the arithmetic combinator mentioned above. This adds the desired (positive) stock level (basically the contents in all networked chests) to the current (negative) stock level across the network. (For instance, if I'm requesting 500 ammunition, and I currently have 411 in stock, the calculation would be 500 + (411 * -1) = 500 - 411 = 89, so a positive 89 signal will be sent across the power lines, to the requester chests emptying the train wagons.)

- Filter Inserters and Storage Chests (one per train wagon) are placed and powered up.

- The output of the arithmetic combinator is connected to the power poles powering the inserters pulling items out of the train wagons and into storage chests (one per car). The Filter Inserters are set to "Set Filters" from the network. (The inserters will then check periodically if there is a positive value on the network and their filter is set accordingly.)

- A decider combinator checks if anything is positive (indicating there is resupplying needed). The input of the decider combinator is the output of the arithmetic combinator. And the output is carried to the train station to be passed to the train. The train then checks to see if there are less than one red signals (this allows multiple "hold" signals to be sent to the train, blocking it until they all clear--this current example only uses one red "hold" signal).

The bots are usually easily able to keep the wall (and other aspects of an outpost repaired and supplied with ammo). (If not, I just up the bot count on the inserters that place bots into the roboport and it automaticall expands operations as train arrivals occur.)

Incidentally, this is all part of my standard outpost blueprint. If you're wondering what that second constant combinator is for, it's for construction projects. I'll temporary set it to request a bunch of stuff from the engineering train (belts, splitters, mines, pumpjacks, etc). Then by the time I want to do the project I have all the stuff for it local in the station's network.

I also use this to build new outposts. I take an engineering train up with me (four wagons of various items), stamp down the first blueprint (which is the basic portions of the rail network needed to get a bypass loop and the engineering siding up), let my personal roboports build the basic infrastructure setup the combinators for the materials needed to build the outpost, then pull the engineering train up to the engineering siding and let it start dumping goods. I'll then stamp down the full station, including walls, etc and the network will start filling with bots, all of whom will start building. (The only weakness, is that sometimes the outpost out-requests the contents of the train which keeps the red "hold" signal set, and I have to manually send it back to base to resupply. But eventually this balances out as the outpost is built.)

The main reason to isolate them is to solve this problem of requester chests not getting filled by bots that are sitting in a port right next to the chest. I am assuming this is because a far-away bot was tasked with this job before the local bots were installed, or before a closer supply chest was filled. I didn't have the patience to wait and find out, and neither would the biters. Also if they are isolated I can use the Y and T signals from each roboport to tell the inserters to feed it logi and construction bots as needed. Otherwise Y and T returns the total number of bots in the network. I am assuming that it would be bad for one port to have no construction or logi bots even if there were plenty of total bots in the network (to avoid them crossing the center of the map that has no ports for example). Maybe not! If I don't need to worry about that then I could just feed one set of chests in the network and the logi bots would sort it out eventually. The perimeter is about 14,000 tiles long. Guessing that is 200 or so roboports?

EDIT - just saw your pictures and how-to. What an awesome outpost construction idea! Sounds great. And I hadn't thought of feeding one turret from another one instead of using a separate requester chest. I will have to study this in more detail.

Beeblebrox wrote:The perimeter is about 14,000 tiles long. Guessing that is 200 or so roboports?

Hmmm...it's hard to say for sure without trying it. But I doubt you'll have too many problems. I don't think the bots will venture outside of a proper roboport boundary (but I haven't tested a loop with a hole in the middle, so I'm not certain on that). They *would*, however, roam around the whole perimiter...that is true.

In my experience I've never had that be a problem. But I overfill my requester chests, and scatter some storage chests around (as they get priority over provider chests for robots pulling stuff out). That's the reason I have my engineering train dumping directly into storage chests instead of into provider chests. I'm *guessing* that if you replaced the provider chests with storage chests for your train deliveries that will help your roaming bots problem.

There are certainly some bot task behavior challenges though. Especially when you're running low on bots (and they all need to jump in to help) or you're running low on supplies and so they panic and feel like they need to grab some from somewhere else.

All-in-all, with a large network, they certainly will cluster in certain roboports. But I find the algorithm distributes them pretty well.

As an example, this is the map I'm currently working on. The two large areas (base and outpost) are both covered in a grid of roboports. I have 1000 logistics bots and 500 construction bots in the main base. And I have 100 logistics bots and 50 construction bots in the outpost. They easily cover those areas. I've never yet had a breach in those walls.

The lower right portion has a *lot* of pressure since that big blue block near the coastline is lined with steam arrays (standard setup of two pumps, two lines, 14 boilers each, and 10 steam engines per line). (Hopefully that gives a sense of scale.)

Looking at the overview of both maps, I'd say yours most likely has a lot more area than mine being defended on the perimeter. So, yeah...not sure, I've never run a configuration like that. But I'm constantly surprised at how well bots can maintain a wall. :: shrug ::

Beeblebrox wrote:EDIT - just saw your pictures and how-to. What an awesome outpost construction idea! Sounds great. And I hadn't thought of feeding one turret from another one instead of using a separate requester chest. I will have to study this in more detail.

Thanks! I actually like the aesthetics of your wall a *lot* more than mine. However, it is nice having the turrets feed each other and minimizing the number or requester chests. I could actually have the entire mid-section between gates fed by a single requester in the middle, but it does take them a bit to fill when they are feeding each other like that (the ammo travels to the ends first, then buffers backward, like a belt would do).

I've recently begun upgrading them with stack inserters, so that they transfer significantly higher amounts of ammo per inserter rotation too, which helps.

The only thing I haven't tried, but wanted to, was to drop a storage chest in the midst of the tileable wall, and then have a main requester chest set to a higher value (maybe 200 or something) that inserts into an active provider chest (thereby distributing the ammo into the localized storage chest). Then the requester chests closer to it *should* theoretically be able to fill more locally to their wall section. I'm not sure it's worth the hassle.

Tricorius wrote:I'm trying to determine the main reason you're wanting them isolated... Am I correct in understanding that it's because you don't want them in a giant network because of them flying across the map? You're wanting to contain the bots to a certain area?

Yeah, I figure it will be a quicker response time if they are contained to a certain local area instead of potentially having to fly from far away.

Thanks for the pics and the ideas!

Beeblebrox wrote:I am assuming that it would be bad for one port to have no construction or logi bots even if there were plenty of total bots in the network (to avoid them crossing the center of the map that has no ports for example). Maybe not! If I don't need to worry about that then I could just feed one set of chests in the network and the logi bots would sort it out eventually.

So, I've revised my opinion a bit after some play last night. I actually accidentally combined the roboport networks for my main base and my smelting outpost (well, I purposefully combined them without thinking through the ramifications).

This wreaked havoc on my resupllier setup (of course) since it combined everything together, resulting in the resupply train staying at the outpost engineering depot (due to exit signal conditions not working properly--it was requesting items that the train didn't have). Regardless, it was easy to put a one-tile break in the roboports at the edge of the outpost once I realized what I had done. It was easy, but time consuming, to go around and collect all the random bots out of the outpost roboports to get it back down to the proper counts in each network.

The interesting part is the behavior I witnessed during the time the systems were connected. This unintentionally created a large center "hole" where there was no roboport coverage. The bots absolutely went through this area, lost charge, and crawled up to a roboport when back in coverage to recharge. It's not optimal at all. I assumed they would stay within coverage of the network even if their path was a longer path. They fly as the birds fly.

I'm actually leaning toward the "zoned" approach mentioned earlier in the thread. A fully separate zone for each wall segment *might* be a bit overkill, but it seems like you probably at least want a separate zone for each area you don't want bots to fly through. So maybe each side of the base rectangle, or whatever... :: shrug ::

I'm still playing with the optimal layout.

P.S. This incident actually made me wish for AI Modules for the bots. It would be sweet to have module slots in a bot that can influence them to slightly change their behavior

Hey mates..
Interesting thread. My defence is not really "laser free" but its pretty close . Its based on gun cover that every turret platform can provide and somewhat optimised on this. If you look at the screen shot for the gun cover you can see that the laser turret and the flame thrower provide a good distance defence and the gun turrets provide the near defence.
The walls are placed in this shape to stop the biters at the flamethrower cover area and at the same time they can not be hit by it. Also you can build a complete line out of this design by placing each block beside each other.
The ropboports are spaced with 2 tiles in this setup and the whole line is maintained with the provider/requester chests on the edges. My fist approach was with trains and it also worked, but I changed it to bots after a while.

So far I lost a couple of front line turrets against biter groups with 10+ behemoth biters which are very rare but occasionally try to run down my defences. Everything less can be handled very easily by this defence. This could be handled with more gun turrets placed beside the frontline turrets but I decided I can live with it how it is now.

I also have a corner setup for this if you are interested so you can make a nice around your base defence.
I hope you like it and ... Take Care