programmable buildings (assembler, furnaces, plants)

[mrvn]

Over time demand for items changes all the time. Sometimes a lot of inserters are needed, at other times a lot of transport belts are used. Currently one has to build massive complexes of assemblers for each item to meet the maximum demand at any time. A lot of them will be idle most of the time when there is no demand for the item. Which is rather wasteful.

One can set up an assembler so it can produce either inserters or transport belts. Simply provide all the ingredients to produce each item to the assembler. Then an assembler is quickly changed from on item to the other. But that is a lot of manual work.

Wouldn't it be great though if the assembler could be switch from producing inserters to producing transport belts using combinators? The assembler could be wired to something. Then it receives an inserters signal it would switch to building inserters. If it receives a transport belt signal it switches to transport belts.
If it receives multiple signals it could stick with the current item (if still signaled) or pick a random one.

Some thought should be spend on the already stored ingredients. It would probably work to switch production in 2 steps:
1) Limit the requested ingredients to just enough to build the current items till the remaining stock is used up.
2) When all stock is used up switch to new item.

What goes for assembler also goes for refineries, furnaces, chemical plants.

[Deadly-Bagel]

See this topic by the devs, one of the features they are considering is the option to set a recipe via the circuit network.

[Radioactive Pretzels]

I bet the real problem with changing an assembler's recipe is dealing with the supply inserters holding products. Think of a gear assembler being fed iron from a mixed iron/copper belt by an inserter. The inserter is holding one piece of iron, ready to put it into the assembler when there's room. Now the recipe is changed to copper cable. That inserter is still holding iron! It can't put it into the assembler, but it can't return it backwards to the belt. So it's stuck. The assember doesn't have any copper input so it sits idle.
You can work around this deadlock problem by using two filter inserters but that's a real pain. It certainly may be worth the pain in some situations though!

In terms of gameplay, the hassle of programming the recipe and then making robust inserter filters likely outweighs any advantages. UNLESS you make it part of the challenge as a playstyle rule. For example maybe there's an achievement that you get for launching a rocket with having used only 100 assemblers or less. Or enforce the assembler count to be capped artificially (for the challenge). Or simply make the cost of an assembler so expensive, perhaps by requiring alien artifacts to build, that you want to mimimize their use.

[mrvn]

I bet the real problem with changing an assembler's recipe is dealing with the supply inserters holding products. Think of a gear assembler being fed iron from a mixed iron/copper belt by an inserter. The inserter is holding one piece of iron, ready to put it into the assembler when there's room. Now the recipe is changed to copper cable. That inserter is still holding iron! It can't put it into the assembler, but it can't return it backwards to the belt. So it's stuck. The assember doesn't have any copper input so it sits idle.
You can work around this deadlock problem by using two filter inserters but that's a real pain. It certainly may be worth the pain in some situations though!

That's why I mentioned it in my post. When you do the 2 step approach I suggested then the inserter would be able to insert the iron and the assembler would use it. At the instant it starts the next unit of production, when it takes the ingredients from its stock, it would simultaneously reduce the number of items requested by the same amount. So no inserter would start picking up more iron and when all stock is used up the assembler switches and the inserter picks up copper.

So you say: What if the assembler isn't fully stocked? The inserter could have iron in it's hand and the assembler might think it's empty and switch.

Well, I would say the assembler has to finish everything it requested even if not already in stock. That would avoid the inserter problem.

[Furcube]

I think good "smart" assembler should work like this:

It should have input and output connections, like combiners.
In input you can set item to produce in case of multiple input signals assembler will go to error state, and for example some lamp will flash to indicate it.

In output it will set items recipe need and required quantity.

Assembler should have internal storage, where all excess items will go on recipe change and assembler will not work until all items are removed.

Inserters should put item for previous recipe into assembler's internal storage.

With some combiners, requester chests and active producer chests it should be possible to build flexible factory.

[mrvn]

That would require some way to clear the internal storage and to clear the error condition. And I wouldn't want the normal exserter to pick up any left over garbage and put it on the outband.

I think my suggestion that the assembler continues with the old recipie until it has finished all requested (even if not present) items is simpler.

On that thought: The assembler recipie should use the count of the signal. You input a signal "fast inserters=5" to the assembler and it will run until it has 5 fast inserters in its output buffer. If you change the input signal to "fast inserters=10" it will run until it has 10 fast inserters in its output buffer (or to the stack size limit if that is smaller). If you change the input signal to "fast inserters=1" it will run until it has 1 fast inserters in its output buffer.

The assembler should also have an (optional, configurable like with Roboport signals) input signal "R". The amount of input material requested by the assembler is then min(R, number of items missing in the output) * <items needed for output>. If disabled the default would be 2 as it is now. Now the trick to make this all work would be that the amount of input material requested can only be raised by the circuit logic but is lowered when input material is consumed. So once you set "R=5" and "fast inserters=10" the assembler will request input materials for 5 fast inserters and it will build those 5 fast inserters no matter what. If in the next tick you set "R=2" and "transport belts=10" it will keep building those 5 fast inserters, using up any materials any inserter may already have it its hand. Only then it switches over to transport belts.

For this to works two other thing have to change: 1) Inserters have to pick up only as many items as requested. 2) If there are two or more inserters and both pick up requested items the sum of both must be <= the amount requested. The inserters have to coordinate.
One additional benefit of this would be that if an assembler has 2 inserters and needs iron plates and iron gears from a single (mixed) belt then one inserter can pick up the iron plates and the other the iron gears. Currently they both pick up iron plates until the assembler is fully stocked and then both switch to iron gears.

[Gertibrumm]

Totally agree on the idea which has been posted I guess 100 + 1 times now

few suggestions
- It is totally simple, nothing has to change, only one cable to assembler which sets recipe, no signal -> no recipe
- To get the right items into the assembler without input lock, like described, the assembler has a short delay until it changes recipes.
- Upon recipe change all items, except products, inside assembler are deleted just like it would when you change recipes manually or deconstruct.

[daniel34]

- Upon recipe change all items, except products, inside assembler are deleted just like it would when you change recipes manually or deconstruct.

Changing recipes manually or deconstructing an assembler will give you back all items (ingredients and products), not delete them. Even doing so while the assembler is crafting will give you back the used ingredients.

EDIT: Other options beside deleting would be

• the assembler only puts in enough ingredients to craft 1x the product (or a specific amount based on crafting time) and only switches recipes once the current product is finished, leaving no unused ingredients in the assembler (as mentioned by mrvn in the first post), but this is bad for mass production as there is a pause between each crafting cycle
• allow the inserter to also remove leftover ingredients when switching the recipe, the ingredients would then have to be filtered from the products by the player
• have a chest built into the assembler where leftover ingredients go, when switching the recipe and then switching back to the first recipe these ingredients would then be used first

[Gertibrumm]

Oh!
Didn't know that!
Well in that case it must be possible to simply extract wrong items in an assembler, and the delay is now void.

[Yoyobuae]

I used a mod which allows changing assembler recipe and actually built something that works:
https://youtu.be/cGfAFxHplnE

My thoughs:

• A clever circuit network setup can workaround all the issues mentioned above. It's not easy, then again it shouldn't be
• Issues with input inserters locking up are solvable via circuit network, or simply separating inputs to different belts. filter inserters not necessary
• Exact ingredient counts can also be achieved via right timing/control

This kind of exact timing, item counting, clockwork like control is exactly the sort of thing circuit network does best. The modifications suggested above would remove part of the challenge/fun, in my opinion.

[MeduSalem]

If setting a recipe in an assembler/furnace/chemplant etc ever becomes a thing then I would be very much in favor of the machine having multiple resource slots the current recipe can draw from. Something like 10 resource slots (each slot can hold a different input resource). The amount of slots is of course a balancing matter and there might be more slots in AM3s than in AM1s for example.

In my opinion that would be the easiest solution to the "residual item" problem.


Because honestly I don't give a damn about ultra complex circuit network setups to perfectly control the item count and every friggin edge case that may ever arise requiring like 50 combinators and crap just for a "simple controller". It may work, yes, but it sucks, really. Ever since the combinators for the circuit network are in the game hardcore people are going completely insane and want everything to be more ridiculously complex than it should be for the sake of maybe 1% of the playerbase enjoying it. Most of them don't even seem realize that it makes NO fun whatsoever for the other 99% of the playerbase who actually look forward to use the Circuit Network for a practical solution for once rather than one that almost nobody understands because it would require a mastery in IT.

No, I want it to be simple and straight forward. I want it to be accessible to everyone even without being much into programming and IT. Just send a Circuit Network signal to the Assembler to set the recipe and you are done. The assembler should take care of residual items itself within a limited window. If the assembler has buffer slots for 10 different resources then that's what you can work with... you can set recipes that require a subset of these 10 different resources the assembler can hold. The only thing you should have to think about is that you don't try to set a recipe the assembler doesn't have the necessary subset of items in its buffer. That's where hardcore people can shine if they want to make the assembler work even outside the given "window", but it wouldn't be required to make setting a recipe work in the first place.

I don't want to have to deal with entering perfect amounts of items in a system that doesn't even support insertion of perfect items without mind boggling setups that defy any reason and useabillity.

[Yoyobuae]

I don't want to have to deal with entering perfect amounts of items in a system that doesn't even support insertion of perfect items without mind boggling setups that defy any reason and useabillity.

Then just allow bots to take out residual items when recipe changes. The Crafting Combinator mod does something like that.

[Gertibrumm]

As much as these no-combinator solutions go,
in the end, the resources have to come from somewhere, which is
1 - manual filling of storage chests (manual, inefficient)
2 - circuit controlled demand belts (1% player, efficient)
3 - rainbow-belt-madness (automatic, inefficient)
4 - limited resource manufacture or inline manufacture (automatic, restricted to a few resource belts)
5 - bots

Unless there is (4) a maximum diversity of items actually processed,
the slot-suggestion is restrictive for the people who want to go all the way, fully auto, 1 assembler, all products.
Also the items would pile up until all slots are full, then no new recipes could be used. No problem for good combinator setup but restrictive. Maybe simplicity/combinator freeness for 99% and difficulty for 1% players? No elegant solution but not unconsiderable.

The assembler putting out a signal of residue-items I think is more elegant. It is straight forward, just use a filter inserter to exsert items from the assembler

[MeduSalem]

Then just allow bots to take out residual items when recipe changes. The Crafting Combinator mod does something like that.

It wouldn't work for people who go for belts-only and don't want to have bots.

As much as these no-combinator solutions go,
in the end, the resources have to come from somewhere, which is
1 - manual filling of storage chests (manual, inefficient)
2 - circuit controlled demand belts (1% player, efficient)
3 - rainbow-belt-madness (automatic, inefficient)
4 - limited resource manufacture or inline manufacture (automatic, restricted to a few resource belts)
5 - bots

You are aware that you can basically put at least 12 belts around each assembler (3 on each side of the assembler and using normal and long-handed inserters). Even if you have to use one of these belts for outputting the finished items, you could use the other 11 belts for delivering resources, both lanes would still make for 22 different resource items that could be possibly drawn from the belts around the assembler. That said you couldn't place as many beacons around the assembler anymore, or at least the beacon efficiency would suffer to a certain extend.

If you want to have the classic 8/8 beacons/assemblers too then rainbow belts can't be avoided anyways but that's a completely different problem and not really related to how "smart assemblers" with setting a recipe might work.

The assembler putting out a signal of residue-items I think is more elegant. It is straight forward, just use a filter inserter to exsert items from the assembler

That is an interesting thought and approach though... Never really thought of it that way.

So basically the circuit network output signal would contain all residual items that mismatch with what the current recipe requires?

But that would mean that the assembler requires two distinct circuit network connection points because otherwise you have a feedback loop... where the output signal of residual items tells the Assembler to use them as signal to set a recipe. Which would not be desired. (Another reason for why I think that green and red circuit networks should have stayed seperate because the way it is now you can't read from and write to the same item... It should have stayed seperate so something like reading with red and writing with green or vice versa is possible.)

A different problem with that approach would be its performance though... because for some recipes the buffer inside the assembler is quite big... wouldn't be fun to output like 40 copper cables from the assembler to free it up for the resources of the new recipe. Which was ultimatively why I came to the conclusion that once resource items are inside the assembler they should stay inside... because otherwise the overhead of a recipe switch is too great.

[Gertibrumm]

The assembler putting out a signal of residue-items I think is more elegant. It is straight forward, just use a filter inserter to exsert items from the assembler

That is an interesting thought and approach though... Never really thought of it that way.

So basically the circuit network output signal would contain all residual items that mismatch with what the current recipe requires?

But that would mean that the assembler requires two distinct circuit network connection points because otherwise you have a feedback loop... where the output signal of residual items tells the Assembler to use them as signal to set a recipe. Which would not be desired. (Another reason for why I think that green and red circuit networks should have stayed seperate because the way it is now you can't read from and write to the same item... It should have stayed seperate so something like reading with red and writing with green or vice versa is possible.)

Yes exactly, and it is possible to not effect devices with feedback loops from itself.
All filter inserters which also should be count accurate work that way (Though they have single pulse signals ) Haven't experimented enough with read-hand-contents – hold to be sure but single pulse is no problem (Is there a short 1-2 tick delay in inserter LUA code?)

Maybe on single tick recipe change signal there is a signle tick response with 1 tick delay maybe maybe maybe

[Yoyobuae]

The assembler putting out a signal of residue-items I think is more elegant. It is straight forward, just use a filter inserter to exsert items from the assembler

And what stops the output inserter from "exerting" these residue items to output belt. The output inserter would need to be filtered to the output item only. So that's 3 simultaneous signals assemblers would need to handle: Input signal to set recipe, output signal to set residue filter inserter and another output signal to set output filter inserter.

(Another reason for why I think that green and red circuit networks should have stayed seperate because the way it is now you can't read from and write to the same item... It should have stayed seperate so something like reading with red and writing with green or vice versa is possible.)

Or simply work around it. I personally like how the red/green circuit network wires work. At start I had similar thoughs as you, but as I experimented with it more an more I noticed that the 2 wire colors could be utilized in surprisingly flexible ways.

[MeduSalem]

And what stops the output inserter from "exerting" these residue items to output belt. The output inserter would need to be filtered to the output item only. So that's 3 simultaneous signals assemblers would need to handle: Input signal to set recipe, output signal to set residue filter inserter and another output signal to set output filter inserter.

That's also a problem yes, but I would think that the output item is handled by the same filter inserter that also handles the residual items... so you have a mess on the output belt that needs sorting elsewhere further down the line. That or the items get used along the line by other assemblers that need these items anyways.

With robots that wouldn't be an issue at all because the robots do the sorting automatically.


But another approach might actually be to update the filter inserters with an addtional mode that has long since been discussed anyways: Inverse filter setting

So when the assembler outputs residual items signal then the "inverted filter" inserter takes everything EXCEPT what's on the circuit network signal... which then would be your output item.

[Yoyobuae]

And what about recipe setting Chemical plants or Assemblers with liquid input? How would residue liquids be handled?

[MeduSalem]

And what about recipe setting Chemical plants or Assemblers with liquid input? How would residue liquids be handled?

¯\_(ツ)_/¯


But seriously though... I have no clue how these should be handled, except putting a fluid output on them as well.

I always thought that assemblers requiring fluids to work with was a strange idea anyways... and that there should probably be it's own mechanic/entities for merging "solid objects" with "fluids"... instead of distributing some recipes to the Chemplant and some recipes to the Assemblers. Currently there's no rhyme or reason behind some of the decisions. So basically I would have:

Assemblers: Work only with solid objects
Chemplants: Work only with fluids
Filling/Emptying Plant: Inputs/Outputs fluids to/from solid objects (I don't know of a better name for that kind of machine now... as giving things appropriate names is a weakness of mine. But hypothetically it can fill/unfill objects, or apply liquids ontop of solid things or mix solid objects into a fluid)

So how I see it every machine should have something like a subset of tools it can work with. Like the Assembler having Cutters/Drills/Benders etc. The Chemplant having chambers to mix fluids. The Filling/Emptying machine has spray nozzles to fill/spray things as well as suck fluids out of something, etc.

This part is now highly hypothetical and quite offtopic... but that's how I would have done certain things if I was part of the design team of Factorio:

Example 1: "Fuel Cells"/"Battery Shells"

I would use assemblers to craft an "empty" "Fuel cell". Filling the "empty fuel cell" with a fluid (acid, oil, Hydrogen, whatever) would happen at the "Filling Plant". The "filled fluid cells" then would be moved to entities which require "fuel cells". There the "fuel cells" would be slowly turned into "depleted"/"empty" "fuel cells" depending on their usage (charging/discharging etc slowly depletes them)... after that depleted they are returned to the "Filling plant", but this time the depleted work fluid gets removed (and has to be reprocessed) and the empty shell returned to the production cycle to be filled again.
So basically it could work with battery shells or fluid cells or something along the order... with different fillings having different properties and efficiency and other things.
So batteries inside Accumulators/Robots/Laser Turrets wouldn't work for all eternity anymore and have to be replaced after a certain amount of charging/discharging.

Example 2: "Ammo Shells"

Basically the same as Fuel Cells, but just for various kinds of ammunition like Flame thrower ammo and whatnot. Where you craft empty ammo shells, which then have to be filled at the "Filling Plant" with whatever should go in there.
Over time there would be Ammo Shell MK1, Mk2, Mk3... which is basically increase in size... so bigger cannon shells and whatnot which increase the damage output of the explosion/impact. With Mk1 being for guns/machine guns, Mk2 cannon shells and maybe even a bigger calibre. Something like that.

Example 3: "Belts"

I would only have ONE type of belt/splitters/underground belt. (no red/blue)
You place the belt, splitters, underground belt like normal... but if you want it to move faster you'd have to place a belt motor ontop of the belt in regular intervalls which effects a certain amount of belt tiles in each direction (and all splitters/underground belts with it). That belt motor can be driven by fuel/electricity/modules... and if you want it go even faster you even have to provide lubricant into that belt motor to exceed extreme belt speeds... which then provides a constant use for Lubricant.
If you don't provide fuel/electricity (and lube for extreme speeds) then the belt returns to the default yellow belt speed which doesn't require any upkeep (which is a compromise between "should belts require energy or not?").

[Gertibrumm]

I love these ideas!! call it "Improvement Everywhere" and make another thread on it ^^
I would love to elaborate a bit

The exserting of residue items works with filter + assembler output signal (constant or pulsed),
the exserting of finished items works just like the recipe setting (constant or pulsed), did noone notice it is the same signal ,
the inserting-of-resources-signal happens with a bunch of arithmetic combinators for all the recipes you want + rainbow belt or specialized factory.
Basically filter inserter only.

to conclude:
there is only one signal into the assembler for recipe change, say green wire, and one out of the assembler for the residue handling, say red wire
no feedback loops, no signal chaos

residue fluids inside assemblers nowadays get deleted. Is it possible to pump fluids out of the assembler when it is not active? Ill have to experiment..