Factorio Forums

So I learned through one of the in-game tips, which are AWESOME, that one can setup a requester chest by shift+right clicking on assembly and then shift+left click on the requester chest.

I see this feature is quite nice for most items but for the Spidertron it requests 562 Low density structure. The issue is that the requester chest will be filled with LDS (which has a tiny stack size of 10) and it won't have room for the other materials and thus won't be able to provide all items necessary for the assembly machine nearby.

Of course this is very far from being game-breaking, but it would be consistent with everything else if by setting up the requester chest the same way I did many others, the assembly machine nearby would actually be able to access all needed materials to produce Spidertrons without manual intervention of the requester chest filters.

I don’t think this is a bug. It sounds more like a feature request to me.

How is that a feature request? Setting up the Requester chest filters with shift+right click on assembly machine and then shift+left click on requester chest works for all recipes except this one. Even for high volume recipes like nuclear reactor and rocket silo. This is the only one exception I've noticed.

khalismur wrote: ↑

Thu Jan 07, 2021 4:02 am

How is that a feature request? Setting up the Requester chest filters with shift+right click on assembly machine and then shift+left click on requester chest works for all recipes except this one. Even for high volume recipes like nuclear reactor and rocket silo. This is the only one exception I've noticed.

That is an observation. The question is, how are you suggesting this be "fixed" ? What mechanic should change: recipe(s), stack size(s), something else?

Or, if you think this is indeed a bug, what mechanic isn't working as expected?

Set up multiple requesters with manually defined filters. This is one way to get around the "limitation", and not have to intervene at regular intervals.

Keep in mind that the copy-paste option assigns enough materials to support 30 seconds of production. Spidertron takes 10 seconds base. Using a level 3 assembler (and/or speed modules) will speed this up, resulting in more materials. If you really want to be making 'trons that quickly you will need multiple chests of LDS. If you just want to stick to 1 chest which will then produce 'trons "just whenever" then you'll need to manually adjust the requests.

actually, rocket silo has the same problem when fully speed-beaconed.

Its definitionally not a bug because we all know shift click assigns enough materials to support 30 seconds of production, so this is working as intended. I would say its an oversight.

An easy fix would be for the recipe copy function to look at the size of the container and adjust the multiplier to leave at least one slot for each item. Not complicated and won't break anything already existing.

Not a bug. If you want you can adjust the request amounts. 67985

invisus wrote: ↑

Thu Jan 07, 2021 4:21 am

khalismur wrote: ↑

Thu Jan 07, 2021 4:02 am

How is that a feature request? Setting up the Requester chest filters with shift+right click on assembly machine and then shift+left click on requester chest works for all recipes except this one. Even for high volume recipes like nuclear reactor and rocket silo. This is the only one exception I've noticed.

That is an observation. The question is, how are you suggesting this be "fixed" ? What mechanic should change: recipe(s), stack size(s), something else?

Or, if you think this is indeed a bug, what mechanic isn't working as expected?

Well it's not hard to implement a solution that tries the ingredient multipliers dynamically. The default is 30 seconds according to user wobbycarly

wobbycarly wrote: ↑

Thu Jan 07, 2021 6:34 am

Keep in mind that the copy-paste option assigns enough materials to support 30 seconds of production.

If that'll use all slots in the chest, maybe the filters could try again, by requesting enough for 20 seconds of production, otherwise 10 seconds, and so on. This would be a robust solution also usable for modded content.

User atomizer's solution is also valid. In both cases, there would need to be a method to check chest slots occupation. I'm not familiar with the API but I'd be surprised if that doesn't exist already.

atomizer wrote: ↑

Thu Jan 07, 2021 10:24 am

An easy fix would be for the recipe copy function to look at the size of the container and adjust the multiplier to leave at least one slot for each item. Not complicated and won't break anything already existing.

And lastly, thanks for answering.

boskid wrote: ↑

Thu Jan 07, 2021 10:27 am

Not a bug. If you want you can adjust the request amounts. 67985

It's not game-breaking, as I stated, but calling it "not a bug" implies it's working as intended. Shift clicking to setup requester chest filters should make the chest able to provide all materials for the production. It's not working as intended.


From the WIKI: "By using SHIFT + Right mouse button and SHIFT + Left mouse button to copy-paste a recipe from an assembling machine to a requester chest, the requester chest is automatically configured to request enough ingredients for 30 seconds of continuous crafting. "

The bug I'm reporting is with the interaction between Spidertron assembly machine -> requester chest under light of that statement from the WIKI. By doing what it said (shift+right click on assembler and then shift+left click on requester chest), the chest won't request ingredients for ANY production whatsoever, as it'll be filled with Low density structures.

If we wanted to get technical about it; the specific feature was originally designed to simply: set the requester chest to request 2x the recipe ingredients.

Then it was changed to simply: set the requester chest to request enough items for 30 seconds of crafting this recipe in the given assembling machine

If the items fit in the requester chest was never part of the logic. If the requester chest even has enough slots available also wasn't ever part of the logic. So technically; nothing here is a bug.

It's a power-user feature that works 99% of the time and in the 1%~ where it doesn't; you can fix it by adjusting the requests. We aren't interested in nit-picking the feature to try to handle all of the edge cases.