Factorio Forums

Hi

Not really a bug, but its bugging me none the less

I do a lot of build factory > choose recipe > copy&Paste recipe on the requester chest next to it.
This always works, it requests the correct ingredients.

However the amount it questions varys deeply within recipes.
For instance, if u paste :
prod modules 1. (5 red and green chips) the requester chest requests 7 of each, so 1.5 times the recipe (and way to low imho)
Walls (5 brick) the requestster chest asks for 225 brick. or 45 times the recipe.

Anyone know where those figures are coming from ?

t-lor wrote:Anyone know where those figures are coming from ?

Info here: https://www.factorio.com/blog/post/fff-213

It aims to keep the chest supplied with 30 seconds of crafting ingredients.

Klonan wrote:

t-lor wrote:Anyone know where those figures are coming from ?

Info here: https://www.factorio.com/blog/post/fff-213

It aims to keep the chest supplied with 30 seconds of crafting ingredients.

I wish that time would be configurable.

I think it could easily stand to limit default requests to 1 stack: if the player truly needs a higher throughput they can always increase it manually. For example, a Heat Exchanger will cheerfully request 1200 copper plates and a fast underground belt is happy to request 1500 iron gears - those quantities are absurd. Limiting to 1 stack wouldn't have any serious effect on the situations where the current logic works well.

Of course this can also just be a matter of these things not having a requester_paste_multiplier or having a daft one (10 for centrifuges? what's the chance I want enough buffer to produce 10 centrifuges? I probably don't even want a total of 10 centrifuges ever because modules and beacons). Most things in the logistic and production tabs are not going to be mass-mass-produced in the same way as intermediates.

Some flaws in your examples.

I easily want 16-32 heat exchangers and extending a nuclear reactor in a 2xN setup requires that much. But that is probably rare so it doesn't matter if they are build one after the other with huge gaps.

But fast transport belts? I easily use up 400 of them and then keep right on going using 400 more. If you build them with requester chests than a 30s buffer is totally reasonable. If not too small. I don't think the assembler would run continiously here with only 30s buffer.

Totally with you on the centrifuges. But why do they only take 4s to build? They are hugely complex machines that need high precision. Nothing that you manufacture in a rush. A build time of 30-60s would be absolutely reasonable.

mrvn wrote: But fast transport belts? I easily use up 400 of them and then keep right on going using 400 more. If you build them with requester chests than a 30s buffer is totally reasonable. If not too small. I don't think the assembler would run continiously here with only 30s buffer.

The thing is I don't think that production/logistic things with a build time of 0.5 have that for the sake of machine crafting, it's rather for the sake of hand crafting.

The question is "how probable is it really that an average player is going to want this thing produced non-stop on a sustained basis". Wanting 800 underneathies? I can believe that. Wanting them non-stop? To make Express Underneathies non-stop in Assembler 3 would require 18000 gears/minute, 1000spm is only ~9600 gears/minute and very few players ever get as far as making 1000spm factories.

To me it's absurd to think that the majority of players would intend an assembler to produce underneathies nonstop and thus the logic of having a large enough buffer to produce them nonstop is not applicable. And that freak of nature who is making a 10000spm factory and really does want those underneathies pumped out non-stop (because he's going to grind that UPS into the DIRT) can just go to the damn requester chest and turn the quantities up.

It's not about needing them non-stop. It's about placing a blueprint and then needing them non-stop for 5 minutes.

mrvn wrote:It's not about needing them non-stop. It's about placing a blueprint and then needing them non-stop for 5 minutes.

Is this how you actually play? Because it seems to me the design pattern of placing an assembler in advance and producing a stockpile of the things in a chest in advance of needing them is overwhelmingly common.

Secondly, some conclusions are strange: To sustain production of Assembling Machine 3 at 0.5/s (modified by assembler) you would need a 1:2:4 ratio of Assembling Machine 1,2,3. I guess I could imagine some players doing this for the sake of perfect ratios but I find it hard to imagine them thinking "I'm really going to need to produce these assembling machine 3's at a rate of 2.25/s, so I'd better drop down 4 assembling machines to produce assembling machine 1".

I think that it'd be cool if the copy paste mechanic from assemblers was an additive function. I often have a single chest providing to multiple assemblers that make different things, and being able to copy paste all of them onto a single chest would be nice.

It'd help this situation to, pasting the same recipe over and over should increase the amount of each item in the recipe.

This is in line with how copy paste works in a document, pressing ctrl-c multiple times concatenate (adds).

BlakeMW wrote:

mrvn wrote:It's not about needing them non-stop. It's about placing a blueprint and then needing them non-stop for 5 minutes.

Is this how you actually play? Because it seems to me the design pattern of placing an assembler in advance and producing a stockpile of the things in a chest in advance of needing them is overwhelmingly common.

Secondly, some conclusions are strange: To sustain production of Assembling Machine 3 at 0.5/s (modified by assembler) you would need a 1:2:4 ratio of Assembling Machine 1,2,3. I guess I could imagine some players doing this for the sake of perfect ratios but I find it hard to imagine them thinking "I'm really going to need to produce these assembling machine 3's at a rate of 2.25/s, so I'd better drop down 4 assembling machines to produce assembling machine 1".

I stopile iron plates without limits. There is nothing else to do with iron ore (except much later and only small quantities). But if you then convert them all to belts then what do you build your oil factory out of when you need to make more oil products? So belt stockpiles are limited (although that's probably the biggest limited stockpile I keep). Assemblers are even more limited, to just one slot in a chest. For other things like roboports I even use a wire and enable the exserter to roboports == 0. Which means one in the chest, two in the assembler, ingreediences to build some more in the requester chest (if that is used). Overall I try to not stockpile things I don't need while keeping the materials to build what I need when I need it.

In some cases I go a different way. For example with Bobs+Angels you have a lot of excess crushed stone to get rid of. Crushed stone gives you landfill, stone, stone bricks, stone wall, gates, stone pipe, stone underground pipes. For those I tend to wire up inserters and program them for e.g. stone underground pipes < stone pipes. So I keep them balanced but build as much as crushed stone comes in.

Anyway. No, I don't build assembling machines 1/2/3 in the perfect ratio. But in such chains the slowest step should run non-stop when the output is needed. Otherwise it slows down all the steps. If your gear assembler isn't producing gears as 0.5s a gear then you have to wait forever for anything else to get built.

mrvn wrote: I stopile iron plates without limits. There is nothing else to do with iron ore...

Yeah but that's intermediates and things needed in thousands per minute, it makes sense to produce those things non-stop and I can't really think of any intermediate or intermediate-ish thing (i.e. stone brick, concrete) where I have a problem with the requester paste defaults. I was talking about production/logistic things, especially those with low build energy needed in relatively small numbers and with high resource requirements to build.

The worst offender is Assembling Machine 3, when pasted from a non-speeded Assembling Machine 3 it wants to buffer up enough material to make 75 units, it requests 150 Assembling Machine 2 and 300 Speed Module 1's. Resource-wise, enough Speed 1 modules end up in the requester chest to produce 12 Speed 3 modules, if the requester chest isn't dialed back down or removed then that is 12 Speed 3 modules which never get created because the request buffer is unavailable to other assemblers. What's more I probably use logistic conditions to limit the stockpile of Assembling Machine 3's to 12 units, and I'm having them created specifically to be placed by bots to fullfill blueprints (after all the existence of requester chests implies comprehensive roboport coverage), and if I blueprint more than 12 at once I really don't care if it takes a few minutes for the order to be fulfilled in the background. So for me it is essentially non-optional to dial the request limits down, typically I'd dial it down to maybe 5 AM2 and 10 SM1s, a mere 1/30th of the default.

Another viewpoint is that it could be that the build energy of some things is overlooked. In the raws some things don't have a defined build energy, that includes assembling machines, so they default to 0.5. When things do have a build energy, even a relatively small number like 5, the problem is a lot less bad. For example if AM3 had build energy of 5, in the above case the requester paste would only be for 30 speed1 modules, which would still annoy me but I might be too lazy to dial it down to 10.

Hmm, I can see the logic behind both arguments, though personally if I put a blueprint down I expect those 400 Transport Belts to already be built and in a chest - I think when I hit Express Belts I stockpile 2,000 belts, 200 Underground Belts and 50 Splitters, the same goes for all my nuclear stuff and everything else. This is especially convenient with nuclear actually because if I have a standard expansion model (eg always expand by 4 reactors) then you can prepare the exact requirements. I usually also implement logic to prevent the absurd amount of additional resources that then get tied up in the Assembler itself so personally I don't find the logistic pasting a problem as I handle it manually.

I do think 30 seconds is a bit extreme, ideally it would be slightly longer than you expect the bots to respond and lategame that should be pretty fast. Maybe 10 seconds?

I also think it's better to have a buffer of products (belts) rather than components (gears and iron). There are two main differences, firstly with how the resources get tied up. When buffering components it will separately request those 1500 gears and 300 Lubricant, even if you don't have the 300 lubricant. Similarly with Iron and Gears, if you have a shortage or Iron Plates then most likely it will maximise the buffer for one before starting on the other, resulting in completely useless resources. By storing the product and using minimal component buffers, it ensures equal ratios of components are tied up. The other difference is that you can't deconstruct a product to manually shunt the 1500 iron gears somewhere else, to me this is a bit of a band-aid solution to a problem but can occasionally get you out of a bind.

There is also construction (and thus response) time etc but that is circumstantial.

I think 30s to be rather too little. My bots take way longer than that usually.

The previous comment about the build power being to low for assembler on the other hand makes a lot of sense.

For production chains where the requested ingredients are produced nearby, 30s seems fine, especially after you get a few robot speed updates. If the there is a provider chest or chests with enough gears within 15 tiles or so (and enough bots and robot charging), then I expect that the bots can keep the blue belt factory running continuously. (If there is an issue of not enough nearby gears, then that is a problem with the factory layout, not a problem with the 30 second request size).

Zavian wrote:For production chains where the requested ingredients are produced nearby, 30s seems fine, especially after you get a few robot speed updates. If the there is a provider chest or chests with enough gears within 15 tiles or so (and enough bots and robot charging), then I expect that the bots can keep the blue belt factory running continuously. (If there is an issue of not enough nearby gears, then that is a problem with the factory layout, not a problem with the 30 second request size).

If it where within 15 tiles then I would use a belt to move the gears.

mrvn wrote:If it where within 15 tiles then I would use a belt to move the gears.

I was pretty conservative above, you will probably be fine significantly further than 15 tiles away, but the number of bots needed to service requests grows as their average travel distance increases, and with that so does the number of roboports needed to keep them charged. Without any worker robot speed research a logistics bot can travel 90 tiles in 30 seconds, so provided the trip to the provider chest, then from the provider chest to the requester chest is less than 90 tiles, then (assuming enough available bots), the bots should be able to keep the assembler from running out. With worker robot speed 2 (which is cheap enough that you should get it fairly soon if you are relying on logistics robots for production) that grows to 157 tiles, and 198 tiles with bot speed 3 (which is still cheaper than requester chest research. If I recall the numbers and the math correctly, robot range before diverting to recharge at worker speed 2 is about 179 tiles, and 183 tiles at worker speed 3, so you should aim to keep travel distance down around 120 tiles, otherwise too many bots will get part way, then divert to recharge, which will delay delivery).

Given the way bots will tend to charge near their last drop off point, your gear production could probably be nearly half those distances from your source of gears without the assembler running out. So about 60-80 tiles with bots speed 3, assuming enough bots and enough charging, and maybe up to 120 tiles if enough bots will be dropping off other items near the gear providers.

For any high throughput, high demand items, it is to important to keep the demand close to the supply, otherwise the number of bots gets progressively larger, as does number of roboports needed for charging, which starts requiring extra space for more roboports for recharging, plus recharging part way through route, which starts impacting average travel distance, and hence numbers of required bots, roboports and request sizes. So try to keep your average travel distances as small as possible, ie less than around a quarter to a half the roboport supply distance which is around 15 tiles.

Zavian wrote:

mrvn wrote:If it where within 15 tiles then I would use a belt to move the gears.

I was pretty conservative above, you will probably be fine significantly further than 15 tiles away, but the number of bots needed to service requests grows as their average travel distance increases, and with that so does the number of roboports needed to keep them charged. Without any worker robot speed research a logistics bot can travel 90 tiles in 30 seconds, so provided the trip to the provider chest, then from the provider chest to the requester chest is less than 90 tiles, then (assuming enough available bots), the bots should be able to keep the assembler from running out. With worker robot speed 2 (which is cheap enough that you should get it fairly soon if you are relying on logistics robots for production) that grows to 157 tiles, and 198 tiles with bot speed 3 (which is still cheaper than requester chest research. If I recall the numbers and the math correctly, robot range before diverting to recharge at worker speed 2 is about 179 tiles, and 183 tiles at worker speed 3, so you should aim to keep travel distance down around 120 tiles, otherwise too many bots will get part way, then divert to recharge, which will delay delivery).

Given the way bots will tend to charge near their last drop off point, your gear production could probably be nearly half those distances from your source of gears without the assembler running out. So about 60-80 tiles with bots speed 3, assuming enough bots and enough charging, and maybe up to 120 tiles if enough bots will be dropping off other items near the gear providers.

For any high throughput, high demand items, it is to important to keep the demand close to the supply, otherwise the number of bots gets progressively larger, as does number of roboports needed for charging, which starts requiring extra space for more roboports for recharging, plus recharging part way through route, which starts impacting average travel distance, and hence numbers of required bots, roboports and request sizes. So try to keep your average travel distances as small as possible, ie less than around a quarter to a half the roboport supply distance which is around 15 tiles.

Do bots actually recharge near their drop off point? From what I observed they simply recharge after X seconds of flight or before returning to the roboport when idle. There is no "I better recharge now before taking a new job" logic.

That makes me wonder. This might be the optimal setup: Place the recharge point between the source and destination. Place source and destination far enough apart that the bot can go from recharge to source to destination before running low and can still reach the recharge point with the remaining charge. Have the bot travel the way it needs to go anyway to reach the recharge point. If it ever needs to turn back somewhere then you lost something.