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
I suspect that this is rarely a problem - simple maths says that you should build a rectangular base, so unless you deliberately handicap yourself by building L-shaped or C-shaped bases you don't have to worry about bots getting eaten.
However, a few things to consider/reasons why it's the way it is:
- thoroughput. If bots don't follow the msot direct route, the distance traveled, and as a result of that the time they spent per delivery increases. That means x bots can transport less items per time, possilby overloading your bot network.
- Energy consumption. Every meter the btos travel requires energy, so havign extra distance can easily mean a LOT of extra energy consumption.
- Time/thoroughput again. More energy use means more frequent recharging, which usualy includes additional travel time/distance when they divert to a loading port, meaning more time spent flying/waiting etc.
- And most important of them all: UPS. The straight lien from start to end point is the easiest, CPU-friendliest way to calculate the route. Additional restrictions on that would exponentialy increase CPU load from bots, which in turn would quickly build up over hudnreds or thousands of bots, and greatly affect UPS even in 'smaller' factories that might not have any problems right now.
On the other Hand you got a very few rare cases were that way of routing get's problematic, at which point maybe you shoudl consider just switching your base wall'defenses to a more uniform defense umbrella, or at least put in defended flypaths on the paths your drones have trouble on.
And sometimes it Is almost a percect rectangle, but the bots Far away on the wall are called to do a job, so they go outside the perimeter wall just a Little too far, and travel a Long distance, just outside the wall. It's silly, and easy to avoid if they just stuck a little closer to the safe areas.
Uhm, if I udnerstand you correctly your problem is basically when you want to mine outside your main perimeter somewhere?
If so, why do you have bots there at all? And if you have btos on your mining outpost for repairing, or transport inside of your outpost, why is that connected to your main drone network?
If you have no overlap of the outside base with neither logistics nor construction both coverages of the roboports of your main base/network, they will not send drones to each other.
It sounds like textbook example of poor / lazy network design tbh. (Totally understandable for a player new to using bots: it does take some time & effort to learn to use them well.)
I'm assuming you currently use a single giant logi net? For bot-based construction / player resupply this is absolutely fine, but for item transport it is rather inefficient & highly prone to secondary problems (bot clumping, high delivery latency, large charging queues).
Much of that can be avoided / greatly reduced by using smaller, dedicated networks. Eg; one logi-net per each major wall section, one for main factory area, & so on. It is quite easy to arrange automatic item delivery between networks (via belts, trains, or via air-gapped "logistics bridge").
Quick fix for your mining trouble: belt the ore from the mine just outside your wall, & then load those belts into provider chests inside a safe area.
MEH! to that idea. Because I see bots travel out to no where and come back for no reason and don't carry anything.
Far more likely that you simply did not realise why the bot took that journey so assumed it was "for no reason".
I do have a large bot network because I'm building a mega-base, and I don't have as much experience with this as other base designs.
My general tactic is to expand a wall, add a new section of base. Add more wall, build more base.
The large bot network helps increase the base's rate of expansion. A central factory processes resources, and bots build new wall on demand.
I unexpectedly ran out of iron, and was forced to expand one wall further than usual, and not uniformly, to get to a new iron deposit.
I though this would be ok, as the bots could travel up (from the mine), then diagonally to the smelters. I thought they would alter their course to stay withing the network, instead of traveling into the open where there were no robotports.
I assumed this is what they did, because it's more efficient to travel where the bots can recharge.
Being able to tell your bots not to stray of the actual roboport network just to get somewhere "faster" (since they dont get there faster if they run out of power halfway through) is a reasonable option though.
Another option would be to tell your robots to stay away from biters or seek shelter when attacked.
There should be a simple way inthe game of setting a few rules for each logistics network and i hope this is something that is planned for the future.
Plus the problem can be easily solved by placing roboports along bot flight paths / making a better design without holes in the coverage areas / using a different transport option for that route.
Sorry, but it has been suggested & rejected many times on the main forums.
Try looking at the bot straight-line pathing as part of the challenge.
While such options would seem nice on paper, the problems with them ingame, as said before, msotly come from the CPU load that would create.
At the moment the process assigns a bot which then does the following steps:
1) calculate straight line to the pickup point
2) calculate straight line to the dropoff point
3) calculate straight line to the next roboport with free capacity
Those are all very easy calcualtions, and only 3 of them.
Now let's assume the btos would stay within roboport coverage, or stay clear of biter nests.
First it would do a pathway calculation. Then check if there is a biter nest or gap in coverage in between. Then do a comaprison calculation of the possible routes around it. Then check for problems on those routes etc.
You woudl end up with your Bot network putting dozens, or even hundreds of times the CPU load on your system, in a game where the really large factories have toruble keeping the UPS high already due to it's scale. And you would gain what, maybe 5 mintues of planning of how to expand the base less for it, or maybe alf a dozen saved bots.
might be nice as an option to turn on for bases without UPS problems. But you'd also have to consider the programming time needed to spend on such a very minor feature.
On aside note of the 'fly away from biters' thing: they probably wouldn't implement that anyways, because at some point your drones are faster than biters, so they'd always escape without getting destroyed, which isn't hte point of this.
Also, the pathfinding calculation changes Would be too extreme, unless the pathfinding were streamlined. It's possible for a computer to designate and remember an alternate route, reducing the calculations required. This can be seen in other games, like in GTA V. When an obstacle appears in the road, the first driver struggles to bypass it, but calculates a new path. All subsequent drivers follow this new path.
Calculating bot highways would also simplify this. Areas of high traffic are defined, and then bots just need to calculate which highway is closest that leads to their destination. Methods like this are used in real life because it's easier than calulating many simple routes, and also results in safer routes.
I understant that calculating straight lines seems like the easiest option, but in reality I believe there are even better, simple options.
The idea of a bot highway isn't to bad, in that it forms somewhat of a compromise between bot restrictions and pathing CPU load.
However, it would still require far more calcualtions than the simple straight lines.
Currently, you have 3 lines to get to 3 points. Pickup, Dropoff, Roboport.
A Bot highway would, at minimum, add an additional line to get to the highway, possibly more if there's more than 1 bot highway needed to be taken.
On top of that you would need to calcualte/find where the nearest bot highway that leads the right way is. And, if your bot highways have branches/crossings in them, every single one of them will be another line to calculate.
Real life, or games like GTA can't really be used for comaprison here because they have inherent restrictions palced on them. YOu can't drive anywhere not flat enought/not a street, and you cannot colide with anything. However, bots in factory got their own 'dimension' so to speak. they have no collision box, and as such can literllay go anyhwere in a straight line.
A suggestion for your base building needs/wants to workaround your current problem: The logistics train Network mod. You can set up a train network with it with the trains working basically like logistics bots, just on rails. It's a bit tricky to set up at first, but once you get the hang of it you can just split your base into dozens (or whatever number suits your base design) logistics networks, with trains running between them to automatically deliver the items as the variosu logistics networks offer/demand them.
FOr a simple overview of how it can work (LN beeing short for Logistics Network, and TN for Train Network):
Requester chest in LN 1 requests iron plates.
That request get's passed to the TN.
TN locates a train station linked to LN2, in which there are provider chests with iron plates.
TN dispatches train from depot to LN2, and in LN2 bots collect plates from chests and deliver them to the loading station of the TN there.
Train takes plates from station at LN2 to receiver station at LN1.
Bots take iron plates from TN station in LN1 to the original chest that requested it.
Train automatically returns to depot to wait for the next order, and to refuel.
It's complicated to set up, but once you do so it can literlaly do what you want from a bot hgihway network. Just liek the highway network, it comes with a significant CPU load on larger scales though.
However, that is only one option, there are others.
For me, I find using multiple smaller networks to be a fun challenge ~ how to get product A from network 1, via network 2, to its destination in network 3. While also sending product B in the opposite direction, & product C elsewhere. Yet have it all set it up to work automagically without causing backlogs or item clutter, & without requiring further player intervention. Quite satisfying imo, once you get it all working properly.
Comparing the two approaches:
Mono-network ~ very easy to setup & quite simple to debug, but can suffer from high latency, bot clumping, & kinda boring factory shapes.
Multi-network ~ much more difficult to setup & debug, but minimises latency & clumping, & allows a much more varied factory layout.
Each approach has clear advantages & disadvantages.
It is up to each player to pick a design that best-fits their needs. Such as using a mono-net to easily clear / capture land, to build your megafactory inside, as you are doing.