I am not convinced of that. Obviously, the chest->chest, chest->belt, and belt->chest are cases where the new rapid inserter will be superior, but assembler-types are not chests (they're gated inventories). So it is not yet clear. Why? Well it all depends on the current behavior of assembler-types driven by inserters.ratchetfreak wrote: Less because you would use the rapids in the beacon setup. Chest to chest the rapid would transfer even more items than the stack upgrade allows now.
- For assembling machines, the input side must satisfy the recipe but the output side can at most accumulate up to 5x recipe or 1/5th of the item's stack-size. This max-output accumulation is not at all evident from the recipe as some only accumulate up to 2x the recipe, like the train-stop recipe. Luckily, most mass-produced intermediates and items will accumulate up to 5x recipe. Again, this is a recent change as it used to be 2x recipe prior to 0.12.
- For furnaces, the input side must satisfy recipe while the output side can at most accumulate up to the item's stack-size.
- For chemical plants, these behave like assembling machines. The base game only have 5 items produced by this entity namely:
- sulfur, solid fuel -> item's stack-size
- plastic, explosives, battery -> 5x recipe
If the buffering behavior is any indication, as seen here where it is grabbing items off the belt as they come,
chest-to-belt-to-chest
I might deduce that the rapid inserter will grab items from the output of assembler-type_A as it is produced and store in its buffer to be released in one move when full to the input of assembler-type_B or from assembler-type_X to chest/belt. Aside from the initial wave-like propagation of activities, the sustained activities will be as smooth as they are now with beaconized builds. Is this a reasonable deduction? I don't know, but it certainly makes sense.
If this is not the case, then rapid-inserters can not be used because they will get stuck since the outputs will never have enough items to immediately fill their buffer to allow a movement. This would mean that the rapid inserters should only be used on the intitial inputs of a beaconized setup. Internal intermediates movement among assembler-types would need to be handled by non-rapid inserter for buffer-free/on-demand throughput. Here, there is a very real possibility that a beaconized setup will be bottlenecked by non-rapid inserters and not the beacon layout. How can I make such a statement when 0.13 is not out? Because current beacon builds can already saturate fast inserters with stack-bonus. Remove the stack-bonus and well what does logic say? Use more fast inserter. This leads to?...Thus it remains to be seen whether the computational savings really exist.
The belt->assembler use case with rapid inserter is not an issue. The input side has never been an issue.ratchetfreak wrote: Most people have 1 item per belt-lane which is always constantly fed. This means that the rapid inserter will eventually pick up it's full stack, check the target inventory for what it still can accept and then start picking up items again depending on what is missing in the assembler.
Well this is like asking what's your favorite color.ratchetfreak wrote: Then there is that the rapid inserter would make copper wire on belts viable again (still not recommended but could get max speed out of a circuit assembler).
I can only say it remains to be seen. There is nothing like measure the proposed change against real usage in megabases.ssilk wrote: Hm. Not everything. See, there are objective, measurable reasons, why this change is better, than yet; the main point is, that it reduces complexity by reducing similar working inserters. Or take the smart inserter, which will become worthless with 0.13. And it removes a very high (but hidden!) complexity (remove the SSB), which is not needed it any case and sometimes also contra-productive. And it combines that with more specialization, which increases the gameplay by increasing the complexity only a bit.
Blueprints to the rescue. Why lay all of those modular inserters down by hand and insert in their respective modules? Make a good layout then let the bots do the tedious work for you. Also it is not like every modular inserter must have a module to work. For most use case, one-to-one insertion is sufficient. I see here is a really good way to expand the Factorio's theme of automation through blueprinting, modularity, and redesign.ssilk wrote: I have critizied the useless basic inserter, but I don't have a good idea, only the moduled inserters (your idea)... Some technology with such frames and equiping the frames is surely the right way for later game, but not with items, that are so heavy used as inserters.
I wouldn't characterize what I've said thus far as outright rejection of their ideas but more of unimpressed. I trust but verify. So we'll see how it goes in 0.13.ssilk wrote: So I can say: For me (from my sight as moderator and handling most of the suggestions) it's a very clever change. But, well, it's of course just my opinion.
Well, that is of course your opinion.There might be some truth in it. But I don't think so cause I cannot know it. Instead I assume, that the devs will do always their very best. I can sleep much better with this thinking.
Ok, I think they made some decisions and are not very sure about the details, but the decision is like so, cause they need to fill the gaps that comes with 0.13.
All we can do now is to have useful ideas, but rejection will bring nobody forward.
)