Factorio Forums

#hype

I fully approve of this pre 1.0 scope creep! This will be really useful. Thank you!

This...

This solves all my problems. Thanks.

Chests are fixed at last!

This is great, I hate the ping-pong bots trying to resolve the requester/provider chest loops that also needed circuit control to stop them getting out of hand, and that was exactly the solution I wanted (stated elsewhere, but I'm almost certainly not the only person to suggest it).

I still find, though, that the CPU improvements are good, but are still highly CPU bound. I know the problems of full multithreading (I program myself, I'm not about to claim it's easy or even feasible!) but is there not SOMETHING that could be pushed out to other threads, even if drawing code runs in one thread and game logic in another? My "CPU" sits at 12% (really just 1/8th of the cores busy) but I still chug along at 30fps on a heavy map, and it's not graphics limiting it as I get the full FPS otherwise.

The bugbears now are startup time (could we not, you know, be sneaky and pre-load only what's needed for the menu, folding the rest of the texture-loads into the "game save loading" / "new game" time, or even in the background while you're on the menu?), save time (so annoying, surely THAT can be pushed off to another thread so that it's saving in the background? I realise it probably needs a kind of snapshot/journal/replay to do so consistently but anything's got to be better than a 2 minute pause every ten minutes, or risk losing /redoing whole swathes of actions if the save doesn't happen), and some kind of error handling when video memory is full - currently it just falls apart and kills the program without a save, I've had to turn the hi-res textures off because if I had to redo that complicated setup I was doing ONE MORE TIME and have it crash mid-way and lose my place.....

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 chests. Release them. Right. NAO !!1111

Awesome. Didn't expect this to happen, but it was certainly discussed "a few" times to make it warranted.

The pre-fetch optimization is cool to hear about, especially with a significant improvement like that. Someone commented with that idea ages ago (no clue when/where) but it's good to see it both implemented and helping measurably!

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?

Robots will only put overflow into Storage. Buffer chests won't accept anything unless they are requesting it.

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

Active providers just push out to everything, so they will push to buffers just the same way, to clarify, this is the current priority:
1. Requesters/Player
2. Construction orders
3. Buffer chests
4. Storage chests

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

Buffer chests won't accept any random items, so if you want to trash some item and don't specifically have a buffer or requester asking for it, it won't go anywhere

I really REALLY REEAAALLLYYY like the buffer chests. Finally a filtered storage chest that acts as a provider!!

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.

ledow wrote:Chests are fixed at last!

This is great, I hate the ping-pong bots trying to resolve the requester/provider chest loops that also needed circuit control to stop them getting out of hand, and that was exactly the solution I wanted (stated elsewhere, but I'm almost certainly not the only person to suggest it).

I still find, though, that the CPU improvements are good, but are still highly CPU bound. I know the problems of full multithreading (I program myself, I'm not about to claim it's easy or even feasible!) but is there not SOMETHING that could be pushed out to other threads, even if drawing code runs in one thread and game logic in another? My "CPU" sits at 12% (really just 1/8th of the cores busy) but I still chug along at 30fps on a heavy map, and it's not graphics limiting it as I get the full FPS otherwise.

Fully agree.

Decouple draw logic.

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

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

All those can "lag behind" and thus are perfect for this. All those can work on a much reduced data set. Particularly routing / pathfinding can really use multiple threads.

Getting ThreadRipper CPU's here in September - hate to see them at below 5%

The buffer chests are excellent, they make a lot of new options possible.

This should also obviate the need for storage chests in a lot of places, which means that my trash won't be scattered around in places it shouldn't.

Any chance this will be released in the .15 branch? It sounds so simple ^_^

TheTom wrote:

ledow wrote:Chests are fixed at last!

This is great, I hate the ping-pong bots trying to resolve the requester/provider chest loops that also needed circuit control to stop them getting out of hand, and that was exactly the solution I wanted (stated elsewhere, but I'm almost certainly not the only person to suggest it).

I still find, though, that the CPU improvements are good, but are still highly CPU bound. I know the problems of full multithreading (I program myself, I'm not about to claim it's easy or even feasible!) but is there not SOMETHING that could be pushed out to other threads, even if drawing code runs in one thread and game logic in another? My "CPU" sits at 12% (really just 1/8th of the cores busy) but I still chug along at 30fps on a heavy map, and it's not graphics limiting it as I get the full FPS otherwise.

Fully agree.

Decouple draw logic.

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

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

All those can "lag behind" and thus are perfect for this. All those can work on a much reduced data set. Particularly routing / pathfinding can really use multiple threads.

Getting ThreadRipper CPU's here in September - hate to see them at below 5%

We are aware of that. Multi-CPU power is going to be more and more important. But still the more we optimise single core performance, the more it will be powerful once we start using multithreading.

12 % increase already .. MMMm
Well Done. While we are on the subject of logistics . How do you tend to solve the deconstruction / request problem of the player when inventory is full . The beeping is soo annoying and shouldn't happen with clever robots...

I think I missed one thing.... will we still need requester chest?

Edit: nvm, I figured that requester chests will still be useful for requester chest -> inserter -> assembling machine.

Isn't buffer chest without request equal to storage chest? Isn't it makes storage chests kinda useless?
edited: sorry, already answered

loving the idea of the buffer chests, hopefully these will work well, i can see one possible issue, logistics robots will take from the buffer to fill a requester if the factory runs low on that item it's holding and then i wont have it, still see the requester at my resupply area (for player) as i can simply grab those items, requesters and active providers at resupply location with manual pickup / drop off still works well for the factory that always needs - something. on the other hand if i could tell the buffer chests not to distribute to requesters, only deliver to the player and used by construction robots, i definitely would find that very useful.

Mooncat wrote:I think I missed one thing.... will we still need requester chest?

Requester chests are not a source for your bots. You can feed machines from buffer chests, but bots will grab from it too.
I think... it depends.

I'm very excited for the buffer chests! My only disappointment with them is that my 5 by 4 compact design which did the same thing will now be redundant...

It was essentially a buffer chest in itself:
Using circuit conditions and combinators, 100 items were requested by a requester. Once all 100 were there, the request was turned off and they were transferred to a normal chest in between and then onto a provider. When the provider was empty, the cycle repeated.

I can't remember the details for why the in-between buffer was needed now, but it was something to do with preventing the requester/provider loop with the bots...

Shame it's redundant but it's 1000% worth it for sorted storage!!!