programmable buildings (assembler, furnaces, plants)

[SoRaC]

It'd be reaally handy for crafting modules, it also should have the option to turn the assembler off/on.
I also support your idea of inversed filter inserters, it could be useful in various situations

[Xeanoa]

Why not just make a logistic assembler with build in Requester, Active Provider and Passive Provider chests. Make it 4x3 to accomodate for the storage space used.

Would make an logistic system requirement for programmable assemblers, but that's the only thing that makes sense imo.
Items left over from recipe switches would always be dumped in the active provider chest. Left over requested items will be left in the requester chest for the next recipe change.

It would be so much more convenient, since you don't have to set up an assembly machine, chests and inserters every time. You just tell the machine to produce until a certain amount in your logistic system is reached.

Hell, this would be super nice to have even if it can't switch recipes.

[Gertibrumm]

It'd be reaally handy for crafting modules, it also should have the option to turn the assembler off/on.
I also support your idea of inversed filter inserters, it could be useful in various situations

You can turn off the power with a power switch. That damn thing must be god for something I assume .
Inversed filter inserters would not be necessary for circuit-assemblers.
By the way you can mimic the behaviour of a inversed filter by using a filter inserter and hooking up a negative signal from a constant combinator.

Why not just make a logistic assembler with build in Requester, Active Provider and Passive Provider chests. Make it 4x3 to accomodate for the storage space used.

Would make an logistic system requirement for programmable assemblers, but that's the only thing that makes sense imo.
Items left over from recipe switches would always be dumped in the active provider chest. Left over requested items will be left in the requester chest for the next recipe change.

It would be so much more convenient, since you don't have to set up an assembly machine, chests and inserters every time. You just tell the machine to produce until a certain amount in your logistic system is reached.

Hell, this would be super nice to have even if it can't switch recipes.

Please no mandatory logistic system requirement. I am just figuring out how to use the circuit-assembler early on and I really never want to ever bother about bots.. but that of course is personal preference. But maybe the circuit-assmbler shouldn't be combinator-mandatory either, rather free to choose what system you prefer to use?

[Xeanoa]

Please no mandatory logistic system requirement. I am just figuring out how to use the circuit-assembler early on and I really never want to ever bother about bots.. but that of course is personal preference. But maybe the circuit-assmbler shouldn't be combinator-mandatory either, rather free to choose what system you prefer to use?

Well, technically you don't need it. But you'd be limited to taking items out from the provider chest tile, if you need to use an inserter.

[Yoyobuae]

Well, technically you don't need it. But you'd be limited to taking items out from the provider chest tile, if you need to use an inserter.

Which would be extremely annoying.

[Xeanoa]

Well, technically you don't need it. But you'd be limited to taking items out from the provider chest tile, if you need to use an inserter.

Which would be extremely annoying.

That's why it's a logistic assembly machine.

[Yoyobuae]

Well, technically you don't need it. But you'd be limited to taking items out from the provider chest tile, if you need to use an inserter.

Which would be extremely annoying.

That's why it's a logistic assembly machine.

Which would also be annoying (to me at least).

[MeduSalem]

I'll basically copy&paste what I've written in the Assembling machines and signals Thread (since I don't know if everyone interested in the topic looks over there):

[...]

• Items that cannot be used for the current recipe are moved to an internal residual item buffer
• Output (Filter) Inserters can take items from that residual items buffer
• Input Inserters can only input resource items from the current recipe.

I think we can all agree that this is what it might work like.

But if you always have to wait for residual items to be completely removed before you can start crafting the new recipe one is actually delaying things artificially and increasing the overhead, decreasing overall crafting throughput considerably if you always have to wait for the slow inserters to output everything.

I mean as I see it... the Assembler could already start working on the new recipe after moving the unusable items to the residual item output buffer and once the actually required resources are inside the assembler. The residual items can still be removed from the buffer in the background at the same time.

So I thought about how it could work similar to how CPU pipelining works, just with a 3-stage assembly pipeline instead or so:

Pipeline.png (8.01 KiB) Viewed 4041 times

In each step the Assembler would do following:

1. Recipe Resource Fetch: Look at current Recipe signal and allow input inserters to prefetch necessary resource items (if they are not already inside the buffer)
2. Recipe Crafting Execute: Start Crafting the recipe once all required resources are inside
3. Items & Residuals Output: Output finished items. Output mismatching residuals if new recipe signal mismatches old recipe. (Basically your Write Back for those who are into CPUs)

The output can be handled by 2 different inserters... one that handles the output of finished items and one that handles the output of residual items.

This way one can make it so that there is always a limited "internal cache" for resource items... and as long as one is switching between the same 2-3 simple recipes or something there would never be residual items to be removed because they fit into the cache. But if you switch between more complex recipes or a lot of simple recipes then the cache will overflow and the oldest (least used) resources will be moved to the residual item output for pickup. And the assembler will only stall if you don't remove the residuals fast enough filling up the residual item output.

That would increase the overall throughput for simple recipes because the penalty of switching the recipe is largely mitigated.



I came up with that because with all the suggestions of "taking out residuals" almost nobody ever thought about how inefficient the throughput gets if the assembler always stalls waiting for removal of items. It becomes way too ugly that the machine spends more time waiting for item removal/insertion than it actually does pure crafting... It becomes so inefficient that it is not worth going for in comparison to dedicating machines to specific recipes.

So my above suggestion of pipelining the input/crafting/output is might actually be necessary to increase the efficiency of the entire "Set recipes"/"Smart Assembly" concept.



I continued to made a rough mockup of how I think that it might actually "work" with being able to switch the recipe at any given point without any performance loss within a certain "window":

Assembler Flow.png (17.87 KiB) Viewed 4041 times

Basically this is how it would work:

1. So basically you set the recipe by signal, which then tells which items are "allowed" to be input into the internal Resource Cache.
2. Once all required resource items are inside the Resource cache the recipe starts crafting.
3. Finished items are moved to the Finished Item Output buffer. An Inserter can pick the stuff up from here.
4. If Recipe Switch happens then the requirements of the new recipe are compared with what is already inside the cache.
5. If it turns out that the resources for the new recipe don't fully fit into the cache (= "Cache Overflow", since there may still be other mismatching items) then it proceeds to dump one mismatching resource item after another to the residual Item Output buffer until there is enough space. It could begin by dumping the "oldest" resource that hasn't been used recently to the youngest.
6. From the Residual Output buffer the inserters can grab the items that aren't needed anymore.

So basically the assembler could go on with crafting the new recipe (given that the resource items are already in place in the cache) without waiting for the residual items to be removed first. It would only start dumping residuals if there's not enough space in the cache, so it will not happen with every resource item on every recipe switch (except if all 6 resource items of the new and old recipe mismatch). The only time when the assembler would stall is either one of the following three cases:

1. Output buffer for finished items is full.
2. Cache is empty because you didn't deliver enough resources to the assembler.
3. Output buffer for residuals is full while a recipe switch requires dumping additional residuals since the Resource Cache is also full.

There would still be a circuit signal necessary to tell the output inserters that there are resdiuals or finished items for pickup. Don't know if a single signal outputting either the finished items or the residual items would be sufficient, but at least one is absolutely necessary to tell the residuals from the finished items apart. Maybe both could be provided: Finished Items would have a positive circuit signal, Residual items have a negative signal. Then you could use "Each > 0" for finished items and "Each < 0" for residual items... that way one would be able to even have several finished items for output (important for mods maybe).

The amount of Cache/Buffer Slots is up for debate of course, but I'd say the 6 slot variant is a solid foundation to work with.


So how I see it, it would be possible to store the resources for up to 6 "single-resource" recipes in the cache and switch between those 6 recipes before it would become necessary to dump something into the residual item output buffer. That in turn increases the uptime of the assembler significantly. Maybe a stall doesn't even happen at all because you get a lot of time to remove the residuals.

That in turn makes it possible to use it even with belts that may have huge delays in item delivery/export, though maybe still not as effective as bots would be of course.

[mrvn]

I think a more interesting and amusing solution to this would be to implement the ability of an inserter to reverse direction based on criteria from the circuit network -- in other words, to rotate itself 180 degrees on demand. This would also allow certain things to be done with trains that are not currently possible.

Or while we are at make the direction freely settable. N, S, W, E signals to set direction or R = 0, 90, 180, 270.

[wat3rstone]

TL;DR

Let the assembling machines allow their recopies to be adjusted, based off of circuit network input.

What ?

Assembling machines can be attached to the circuit network which could allow the circuit network to change the recipe of the assembling machine depending on the input.

Why ?

The circuit network can be used to easily adjust an outpost to create a variety of resources upon demand, or to have an assembling machine switch to a different crafting material once the previously crafted material has been backed up. If iron gears are backed up, then the outpost can switch to iron rods until they themselves are backed up or have run out of raw materials.

[Tekky]

This has already been suggested two years ago in the following thread:

viewtopic.php?f=6&t=32697 programmable buildings (assembler, furnaces, plants)

EDIT: Meanwhile, the threads have been merged. Therefore, my above link now points to the current thread.

[Koub]

[Koub] Merged into older topic with same suggestion

[LordFlameStryke]

TL;DR

Is there a way to add wires to assemblers and chemical plants to select a recipe?

What ?

I'm building a cell-based factory, so I have a lot of assemblers in one location building the same thing. It would be a lot easier to plant a blueprint with a constant combinator attached to all the assemblers with a "select recipe" control so I can set the blueprint on all the assemblers at once. Copy/pasting recipes is ok if you've only got a few assemblers to set up, but if you've got a couple dozen (or more) all crafting the same thing it gets monotonous. Especially if you're putting down a lot of these cells.

[Koub]

[Koub] Merged into older thread with same suggestion.
Note : There are actually dozens threads asking for virtually every building of the game to be connectable to circuit network, in order to be read or controlled.