Factorio Forums

We were also concerned of people segregating their logistic networks for more control, it seems to us it was a workaround to a problem we should fix.

Still need to do that when building perimeter wall. Since bots don't path too well around large areas of no coverage. They go straight for the destination and when they run out of power they go to closest roboport and that can be starting roboport. But buffer chests are nice addition that will help to keep things organized.

Well I guess you really wanted that pentagram to happen in second picture...

OMG Thank you! Thank YOU! THANK YOU!!!

Been waiting for those logistic buffer chests for a long time. You guys rock.

And those robots! So gorgeous!!!

Used to wait for .15 with such anticipation. Now .16 can't come soon enough.

Wife hates you guys. Hates you.

I don't get why do we still need passive provider chest once buffer chest is implemented? Wouldn't buffer chest without any restrictions set work same as passive provider chest? (Meaning you can put any items there using inserter/manually and they provide items for active provider chests/robots/you)

sinsiliux wrote:I don't get why do we still need passive provider chest once buffer chest is implemented? Wouldn't buffer chest without any restrictions set work same as passive provider chest? (Meaning you can put any items there using inserter/manually and they provide items for active provider chests/robots/you)

A buffer chest cannot request from another buffer chest. If you want to be able to insert, then have a robot carry to a buffer chest only when needed there, it would be impossible without passive providers.

Glorious!!!! I love your work guys, keep it up!!!!!!!

I may be wrong in posting this but: The example that you gave of having the buffers act as a requested items storage space, presuming that you have multiple, each of which is fully supplied, Will the bots draw from the closest one full route? I remember that the bot logic was still a little bit broken and that you would and often did have bots flying across the map to deliver items that were able to be gotten form right next to you. I like the addition of the Buffer chest, but I fear that it is only the addressing of a symptom and not that of the problem of robot logic all together.

kovarex wrote:

MeduSalem wrote:How does the Active Provider Chest fit into that? Does it also provide items for the Buffer Chests?

Also... what will be eventually the point of still having storage chests that can't be done with Buffer Chests?

Buffer chest can't provide buffer chest, it would be a loop.
So for example. You can have a central storage with storage chests, and buffer chest can feed from it. If the central storage was buffer chest as well, it couldn't.

Hmm.... That would mean you won't be able to have a buffer chest that support other buffer chests... I guess that limitation is fine.

Personally I use logistics only for supplying myself (I simply love trains and the "belt puzzle" too much), but this buffer chest makes even me to #hype ! No more annoying waiting! : )

TheTom wrote:Decouple draw logic.

It already is.

TheTom wrote:Decouple routing decisions. Keep a separate path network (robots, TRAINS) and handle pathfinding on separate threads.

Not feasible. Routes become invalid during game updates which means you can't calculate a path while the game updates. Routes also effect the cost of the next route so they can't be done in parallel.

TheTom wrote:Decouple AI At least high level (i.e. groups of biters).

Exact same problem as trains.

IronCartographer wrote:

sinsiliux wrote:I don't get why do we still need passive provider chest once buffer chest is implemented? Wouldn't buffer chest without any restrictions set work same as passive provider chest? (Meaning you can put any items there using inserter/manually and they provide items for active provider chests/robots/you)

A buffer chest cannot request from another buffer chest. If you want to be able to insert, then have a robot carry to a buffer chest only when needed there, it would be impossible without passive providers.

It would be by using storage chests. Well I guess it won't matter to me, I'll just use buffer chests everywhere with a few storage chests for misc crap.

With buffer chests we can now sensibly program logistic supply routes across the base - Yay

Now we only need a way to make sure the bots fly sensible routes, without passing over things like power backout zones, or behemoth spitter nests

Oh man, this is probably not feasible, but after reading this again something occurred to me:

When the main base is so far away, it can take a long time for robots to arrive with repair packs, so the biters might be able to break through. Using the buffer chest, it will be easy to setup nearby supplies to quickly repair the walls when needed.

What if these chests could request and deploy locally cached construction bots?

Awesome sauce! I've hit this problem with chests many times and usually end up using a car to move large amounts of things (mostly concrete) around.
Anything which makes covering worlds in beautiful grey easier is a good thing.

Rseding91 wrote:

TheTom wrote:Decouple routing decisions. Keep a separate path network (robots, TRAINS) and handle pathfinding on separate threads.

Not feasible. Routes become invalid during game updates which means you can't calculate a path while the game updates. Routes also effect the cost of the next route so they can't be done in parallel.

TheTom wrote:Decouple AI At least high level (i.e. groups of biters).

Exact same problem as trains.

Couldn't you signal a route recompute during game update if it? If you maintain some data structure (e.g. rail path network) then whenever a game update causes that other data structure to change signal the routing thread to recompute/re-validate? If the route is being calculated in a separate thread, wasted computation shouldn't really matter much. It also seems like the number of updates where the path networks change would be relatively rare [when compared to the total number of updates, anyway].

Just a thought, obviously not familiar with your code base, so maybe a dumb one. =)

More importantly, buffer chest hype! On that note, do buffer chests take priority (for providing player/requests) over passive providers and storage chests? I would assume so, so that you could use it to push items to the edges of a network (such as a solar field/wall network) for rapid expansion.

IronCartographer wrote:Oh man, this is probably not feasible, but after reading this again something occurred to me:

When the main base is so far away, it can take a long time for robots to arrive with repair packs, so the biters might be able to break through. Using the buffer chest, it will be easy to setup nearby supplies to quickly repair the walls when needed.

What if these chests could request and deploy locally cached construction bots?

This is possible already: you can insert bots into a roboport and this will cause them to be deployed. I often have a requester chest set to insert more bots if the number of available bots drops below a certain level.

I wonder how feasible it would be to condense logistics chests into one customizable entity? Ie: You can tell it to be a requester, passive provider, active provider, and/or storage chest and set a priority level for each of those options. Might be a mess to get into the game and working properly but it'd be pretty flexible.

What kind of bugs me is high CPU usage when the game is paused in the background. Yeah, it's "useful" in winter but I can use other commands for that...

hribek wrote:What kind of bugs me is high CPU usage when the game is paused in the background. Yeah, it's "useful" in winter but I can use other commands for that...

Are you on mac/linux? For me (on Windows) it uses almost no CPU when paused.

Rseding91 wrote:

hribek wrote:What kind of bugs me is high CPU usage when the game is paused in the background. Yeah, it's "useful" in winter but I can use other commands for that...

Are you on mac/linux? For me (on Windows) it uses almost no CPU when paused.

Not the OP, but I'm on linux. Factorio is currently paused and consumes about 70% CPU (i.e. 0.7 core). When I unpause it this goes up to 170% (with over 100 trains continuously being created, running a route, and being deleted in creative mode).