Factorio Forums

Those requester changes... When you thought it couldn't get any better. Great work as always

I particularly like the 30s craft requests. Is this mechanism similar ton the one calculating how much an assembling machine requests to its inserters, depending on its speed ?

[Edit] I almost forgot something I've not been the only one bothered with if I trust some posts I've seen : is it possible that, when rendering the preview of where the ghost would go, the grass was hidden ? I often find it quite difficult to see what's underneath my ghost when I try to plonk it on an iron field covered with grass doodads.

On which friday will "The little things 3" be coming out?

I love the requester changes, and its something that been asked for for quite some time, but it might seem inconsistent to a player that does not know why performing the same action results in different values being set (E.g. if a row of assembly machines are mixed types of have different modules in them). It might be something to note in a tutorial about the copy and paste mechanism overall.

For small bases the copy/paste function will be quite cool. ^^

In my base I will still have to adjust the requests manually... because of distance problems...

The request should probably be based not only on recipe/assembler speed but also on distance to the closest provider chest holding a specific resource and also on Robotspeed to determine how fast they can make the distance.

It would be neat to have a "factory request signal" that uses the 30s calculation for the requested items (minus inventory already inside) in order to connect that to either a request chest or some other delivery system up the line. That way we could greatly improve on-demand factories.

MeduSalem wrote:the closest provider chest holding a specific resource

Do we already have these buffer-chests that hold up to a certain amount of items ready for delivery to requester chests?

I think it's hard to say anything on the network availability for any calculations. That 30s-rule would be baked into the layout of your logistic network instead of the other way around.

What we can hope for is automated logistic bot redistribution to always have enough of them available close to where they are needed.

ske wrote:Do we already have these buffer-chests that hold up to a certain amount of items ready for delivery to requester chests?

I almost fear that the upcoming Buffer Chests will introduce their own problems.

Like for example currently it is quite easy to stop production of an item by simply checking how much there already is in the logistic network.

But when there are logistic Buffer chests involved the total amount of produced items must be greater than the total amount of requested items for ALL Buffer Chests combined (since they count towards the total amount of items in the logistic network) or otherwise some of the Buffer Chests might end up running dry, especially if the consumption rate is not equal for all buffer chests. The equal distribution of items among the buffer chests through bots will be counter-productive in that relation. I've already wrote once on the forum that the bots should actually distrbiute items based on priority, the further the current amount of items in a requester chest is from its total requested amount of items the more priority it should get because it's obvious the chest is starving.

The Buffer Chets will introduce a lot of fiddling on their own which probably makes them only suitable for low amount of items and if the distance is really, really far (like repairpacks or ammo for defense walls etc).

MeduSalem wrote:The request should probably be based not only on recipe/assembler speed but also on distance to the closest provider chest holding a specific resource and also on Robotspeed to determine how fast they can make the distance.

Even for something as one-off as a paste action by the player, that's way too much logic to bake into the mechanic.

I'm a little saddened that this paste change will likely be in lieu of the "pasting adds to existing requests" feature that seemed planned, which would have made sharing requesters more convenient while also enabling simple request multiplier scaling. That said, it's a minor thing, and I can see why they'd take this route instead (it's much more consistent with how paste works in general).

ske wrote:What we can hope for is automated logistic bot redistribution to always have enough of them available close to where they are needed.

This has been discussed in the past, but an "Idle Robot Request" feature for roboports would be pretty awesome: Any available robots would travel to roboports with an unsatisfied robot threshold, allowing us to "soft tether" bots near train stations / walls that might need repairs / etc. when they aren't being used at maximum capacity.

Would it be possible to either manually or (preferably) automatically mark tutorials as done?

For example, if the player has built a running train, the basic train tutorial can probably be marked as "done".

I'd be happy enough if the 30 second value was exposed via the modding API. It's easy enough for someone to make a mod or to add it to use preferences later.

Another thought though: if buffer chests had two priorities you could have one at the producer (such as a train station) and another at the consumer. Then you only need to scale up your buffers to handle the travel time, not individual requesters.

Another thing to perfect would be inserting modules in existing machines by bots. As far as i know there is no easy way to let bots change or ad modules in already existing machines as blueprints with different modules can't be placed over existing machines. The only way is to delete the old machines and than place new ones with the new modules

MeduSalem wrote:Like for example currently it is quite easy to stop production of an item by simply checking how much there already is in the logistic network.

I think we need something like this using multiple "signals" for the logistics network accounting:
* Number of items in Provider Chests.
* Number of items in Storage Chests.
* Number of items in Buffer Chests.
* Number of items in Requester Chests.
* (Minus) Number of requested items of Requester Chests.

When reading the logistics network you can choose which you want to add up in your calculations. Obviously there would be one default configuration preselected. (Provider + Storage + Buffer)

Currently we don't get the requested number of items.

The copy/paste requester chest change is brilliant!

re: Buffer chest production problems - you can solve that fairly simply by just wiring your assembler's output inserter to your passive provider chest, resource < 50, instead of using a network condition. As buffer chests bring items away to the far locations, the provider chest will keep that given amount ready to be provided to any depleted buffer chests.

Ah, the little things! That requester change is extremely nice and will save a lot of manual changing and tons of time honestly. There will obviously be some things that still need changing manually, primarily when it comes to large distances the bots have to travel. I do like that you guys chose 1 minute of production worth of materials sense that is usually a really good amount to aim for even ranging from a small base to a megabase.

The change with the miners and such is nice for new players for sure. For people who already know how that stuff works it isn't really impactful, but definitely adds clarity overall which is good.

One question. How will the new request paste functionality work if the requestor chest is serving 2 assemblers with different recipes? eg. one chest serving an assembler making construction bots and an assembler making logistics bots? Im guessing that you
will need to manually add either the green or red circuits to it's request?

Zavian wrote:One question. How will the new request paste functionality work if the requestor chest is serving 2 assemblers with different recipes? eg. one chest serving an assembler making construction bots and an assembler making logistics bots? Im guessing that you
will need to manually add either the green or red circuits to it's request?

For this, the assembler would actually need request-functionality and you would have to connect the chest via blue wire. I think that doesn't exist (yet).

Zavian wrote:One question. How will the new request paste functionality work if the requestor chest is serving 2 assemblers with different recipes? eg. one chest serving an assembler making construction bots and an assembler making logistics bots? Im guessing that you
will need to manually add either the green or red circuits to it's request?

Unless they add an additional features to somehow take care of that, then yeah you would still have to manually add the stuff that is in the recipe from the assembler you didn't copy.