I want to have a single foundry making the copper coil and steel for my railgun shells. (Because of space constraints on the platform and otherwise the copper foundry being way underused with about 5% duty cycle to keep up with the steel.)
Basically I would like to make it craft for example 48 copper coils (16 craftings and exactly 3 stack inserter swings to empty it quickly), then switch to making 24 steel (16 craftings), and keep doing this forever.
But between keeping track of the number of craftings, and setting/holding the recipe and then switching I have not been successful. Does anyone have a working setup like this?
Re: Foundry logic for railgun shells
Posted: Mon Apr 21, 2025 5:36 am
by Jay_Raynor
I think being exact may be too problematic. A different option may be to set recipe based on the absence of a material at a specific part of the down-trace belt when hold read. Use two filtered stack inserters placing the two ingredients on different sides of the belt so there isn't a hold caused by stack inserters not being empty.
Re: Foundry logic for railgun shells
Posted: Mon Apr 21, 2025 12:24 pm
by jdrexler75
Jay_Raynor wrote: Mon Apr 21, 2025 5:36 am
I think being exact may be too problematic. A different option may be to set recipe based on the absence of a material at a specific part of the down-trace belt when hold read. Use two filtered stack inserters placing the two ingredients on different sides of the belt so there isn't a hold caused by stack inserters not being empty.
That's what I ended up doing, because I couldn't come up with a reasonable simple logic setup. I disagree that being exact may be problematic though (aside from the complicated logic). It would both allow smaller buffer storage on extra belts, and maximize the railgun shell production from one foundry. Being inexact means that the foundry often switches without fully realizing its productivity bonus. So it both produces less, and uses more ingredients.
Re: Foundry logic for railgun shells
Posted: Mon Apr 21, 2025 2:15 pm
by eugenekay
Don’t count Ticks in your Control Combinators - you will have to track & estimate the Production speed for each recipe to guess the right number of Ticks to wait, which is hard. Instead try using the “Read Finished” option to get a Pulse signal each time the machine finishes a product. You can then count the number of Crafting Cycles directly - and switch recipe/reset the count when it reaches your desired threshold (or the output becomes full). There will be an extra Tick of “unfinished crafting progress” right as the Recipe is changed which is a small inefficiency, but its still better than using separate plants at half-idle.
Another methodology is to count the Outputs. Use the Read Hand Contents feature on your output Inserters, and store the difference in ratios between Steel/Copper output. When sufficient of one material has passed, switch recipes. This requires more room in your belt buffers, and may run dry easier.
Jay_Raynor wrote: Mon Apr 21, 2025 5:36 am
I think being exact may be too problematic. A different option may be to set recipe based on the absence of a material at a specific part of the down-trace belt when hold read. Use two filtered stack inserters placing the two ingredients on different sides of the belt so there isn't a hold caused by stack inserters not being empty.
That's what I ended up doing, because I couldn't come up with a reasonable simple logic setup. I disagree that being exact may be problematic though (aside from the complicated logic). It would both allow smaller buffer storage on extra belts, and maximize the railgun shell production from one foundry. Being inexact means that the foundry often switches without fully realizing its productivity bonus. So it both produces less, and uses more ingredients.
Doesn't matter as long as ammo production exceeds consumption per trip. Steel and copper wire are infinite in space.
Re: Foundry logic for railgun shells
Posted: Tue Apr 22, 2025 4:16 pm
by jdrexler75
Jay_Raynor wrote: Tue Apr 22, 2025 4:58 am
Doesn't matter as long as ammo production exceeds consumption per trip. Steel and copper wire are infinite in space.
It's never enough though, is it? The available production rate just defines the maximum safe speed and/or trip turnaround time. Especially on space platforms, squeezing out the last bit of performance is often critical, since just building bigger comes with even higher costs and complexities. More mass means slower, more area means more to defend, etc.
In my case this foundry is the limiting factor and the difference between 16 and 17 shells per minute has a huge impact down the line.
Re: Foundry logic for railgun shells
Posted: Tue Apr 22, 2025 6:30 pm
by Tertius
mmmPI wrote: Tue Apr 22, 2025 3:05 pm
That's unexpected , it look like a 1-foundry-for-railgun-shells-setup, as requested in this thread 128028 and i thought you encountered the mentionned behavior when making a setup to post there.
Yes, kind of, and I guess this thread is a better place for discussion than a "not a bug" report thread. So here my conclusion with this:
I tried to share some foundries for railgun ammo manufacturing myself, but I failed. Not because of the circuits, but because of everything that goes with it.
In my setup, there are 4 foundry candidates to merge into 1 shared foundry. 1 for molten copper, 1 for casting copper cable, 1 for molten iron, 1 for casting steel. The 1 for molten iron is in addition to another molten iron foundry with a fixed recipe used to produce gun ammo - there is a small underproduction otherwise.
Looks easy with 1 storage tank for molten copper and 1 storage tank for molten iron: switch to the corresponding recipe if there is less than 1000 (or whatever) in the corresponding storage tank. However, you need to extract the trashed ore and calcite, if these recipes are switched away. You have to feed this back to the supply. And give the extracted material priority to keep the extracting inserters from clogging and blocking. And you neither have bots nor chests for this. And you need filtered pumps to separate molten iron and molten copper to feed into the proper tank.
Then the casting recipes. You think they're simple, but they have 2 issues: The fluid input is on the opposite side of the fluid output from the molten iron/copper recipes. You cannot produce molten stuff, then change to a casting recipe and expect the fluid go in where it previously got out. Instead, they get in on the opposite side! Much space required on the platform just for some pipes going round the foundry you simply don't need of you use separate foundries with fixed recipes all along. And you need that space round the foundry for all the inserters inserting and extracting stuff (including trashed stuff).
The other issue ist getting rid of the molten fluid on recipe change. The casting recipes simply don't change, no matter what the circuit says, as long as there is molten fluid in the input. So you need a pump as valve to stop fluid input. But... that's not all. It's not enough to stop fluid input until it's empty. You need to explicitly empty the pipe, because the last few units don't go away on their own, if it's not enough for a full production cycle. So you need 2 pumps for each fluid. 4 pumps just for changing the fluid. And it takes quite some time to completely empty the pipe. And you need an explicit process step to empty the pipe, even if the fluid doesn't change, because the recipe will stick until eternity, if the input doesn't get 100% empty.
And that's where I gave up. Not because it isn't possible to build, but there isn't actually much space to gain with all that additional stuff required to handle the trashed items on recipe change. It doesn't make sense. You just replace some foundries with super ugly pipe+belt contraptions. It's so depressing, if I compare this mess with the beautiful 4 foundry layout where you just connect some output with some input, no storage tanks, no trash handling, just input ingredients and output products.
This is compact enough
04-22-2025, 20-58-52.png (1.14 MiB) Viewed 454 times
Jay_Raynor wrote: Tue Apr 22, 2025 4:58 am
Doesn't matter as long as ammo production exceeds consumption per trip. Steel and copper wire are infinite in space.
It's never enough though, is it? The available production rate just defines the maximum safe speed and/or trip turnaround time. Especially on space platforms, squeezing out the last bit of performance is often critical, since just building bigger comes with even higher costs and complexities. More mass means slower, more area means more to defend, etc.
In my case this foundry is the limiting factor and the difference between 16 and 17 shells per minute has a huge impact down the line.
Building wider is far more a speed penalty than building bigger. I know, I have two different five-thruster designs and the longer one with much higher mass gets a better top speed.
As for damage, yeah. My Aquilo cruiser needed explosive 12 to facilitate double-shotting asteroids instead of triple.
Re: Foundry logic for railgun shells
Posted: Wed Apr 23, 2025 5:02 pm
by NineNine
Tertius wrote: Tue Apr 22, 2025 6:30 pm
...It's so depressing, if I compare this mess with the beautiful 4 foundry layout where you just connect some output with some input, no storage tanks, no trash handling, just input ingredients and output products.
This is compact enough
04-22-2025, 20-58-52.png
350 MW. Fusion power recommended.
That's a nice design! I wish mine were nearly as compact as that one is! If you update everything to Legendary quality, I bet it would be super awesome.
Tertius wrote: Tue Apr 22, 2025 6:30 pm
...It's so depressing, if I compare this mess with the beautiful 4 foundry layout where you just connect some output with some input, no storage tanks, no trash handling, just input ingredients and output products.
This is compact enough
04-22-2025, 20-58-52.png
350 MW. Fusion power recommended.
That's a nice design! I wish mine were nearly as compact as that one is! If you update everything to Legendary quality, I bet it would be super awesome.
Yeah, but it's also a bit too much for a space platform. Standard rockets work much better for asteroids than red rockets.
Tertius wrote: Tue Apr 22, 2025 6:30 pm
...It's so depressing, if I compare this mess with the beautiful 4 foundry layout where you just connect some output with some input, no storage tanks, no trash handling, just input ingredients and output products.
This is compact enough
04-22-2025, 20-58-52.png
350 MW. Fusion power recommended.
That's a nice design! I wish mine were nearly as compact as that one is! If you update everything to Legendary quality, I bet it would be super awesome.
Yeah, but it's also a bit too much for a space platform. Standard rockets work much better for asteroids than red rockets.
Too much how? I could fit 4 of these on my larger platforms!
Also, standard rockets work for early end game, but later on, you definitely want red if you're going to get anywhere near the shattered planet. You don't need the extra explosive force of the yellow rockets, because you have updated explosive damage. You do need the multi-hit of the red rockets, though,
Re: Foundry logic for railgun shells
Posted: Wed Apr 23, 2025 11:58 pm
by Jay_Raynor
NineNine wrote: Wed Apr 23, 2025 7:54 pm
Too much how? I could fit 4 of these on my larger platforms!
Also, standard rockets work for early end game, but later on, you definitely want red if you're going to get anywhere near the shattered planet. You don't need the extra explosive force of the yellow rockets, because you have updated explosive damage. You do need the multi-hit of the red rockets, though,
Wouldn't it just be better to just have more rocket turrets and the easier-to-produce standard rockets?
NineNine wrote: Wed Apr 23, 2025 7:54 pm
Too much how? I could fit 4 of these on my larger platforms!
Also, standard rockets work for early end game, but later on, you definitely want red if you're going to get anywhere near the shattered planet. You don't need the extra explosive force of the yellow rockets, because you have updated explosive damage. You do need the multi-hit of the red rockets, though,
Wouldn't it just be better to just have more rocket turrets and the easier-to-produce standard rockets?
I don't think so. As you get closer to the Shattered Planet, the asteroid density continues to increase. The same space on your platform can be used to launch either a missile that will hit one asteroid or a missile that will hit multiple asteroids. So, no matter how many missile launchers you have, or what shape or size of your platform is, the closer you get to the Shattered Planet, the more advantage red missiles have.
In terms of damage... if you're not one-hitting the asteroids, then the red rockets hit for half of what yellow rockets hit for. That means that if one red rocket hits more than 2 asteroids on average, it's a better deal, damage-wise.
But, eventually, you're going to one-hit asteroids with either yellow or red rockets, so the red rockets will then have a huge advantage over yellow.
Platform space for making the rockets really doesn't matter. The edges where the weapons can reach IS relatively precious, which is why the red rockets have an advantage over the yellow in late game.
Re: Foundry logic for railgun shells
Posted: Thu Apr 24, 2025 2:07 am
by Jay_Raynor
Huh. TIL.
Re: Foundry logic for railgun shells
Posted: Thu Apr 24, 2025 4:11 am
by mmmPI
jdrexler75 wrote: Sun Apr 06, 2025 8:13 pm
But between keeping track of the number of craftings, and setting/holding the recipe and then switching I have not been successful. Does anyone have a working setup like this?
I have something that "works" , it is a modified version of what Tertius made on the bug report topic, it's 99% Tertius' design, the problem is that i don't exactly understand why it works and any slight modification breaks it.
It is a 1 foundry design for steel and copper wire BUT it is very fragile because if you change any of the pipe that can contain iron, it can happens a situation where the design get stuck in flickering receipe change. With this particular configuration it has not gotten stuck in my tests. I wouldn't know how to reproduce a different setup using the same principles because i don't understand what cause it to works on this particular case and flicker when the configuration is different and wether or not such things can be made realiable and predictable.
Tertius wrote: Tue Apr 22, 2025 6:30 pm
Not because it isn't possible to build, but there isn't actually much space to gain with all that additional stuff required to handle the trashed items on recipe change. It doesn't make sense. You just replace some foundries with super ugly pipe+belt contraptions. It's so depressing, if I compare this mess with the beautiful 4 foundry layout where you just connect some output with some input, no storage tanks, no trash handling, just input ingredients and output products.
I understand the reasonning and haved used electric furnaces for copper when desired throughput could be met with one for similar reason, because it's less footprint that one foundry. I thought you were going to write explanations on how it works x).
NineNine wrote: Wed Apr 23, 2025 7:54 pm
if you're going to get anywhere near the shattered planet.
Why would you ?
Re: Foundry logic for railgun shells
Posted: Thu Apr 24, 2025 11:15 am
by Tertius
mmmPI wrote: Thu Apr 24, 2025 4:11 am
I have something that "works" , it is a modified version of what Tertius made on the bug report topic, it's 99% Tertius' design, the problem is that i don't exactly understand why it works and any slight modification breaks it.
The combinator performs a map from a set of conditions to a set of signals. In our case, it maps to a set of recipes. All possible recipes are defined in the constant combinator, each with its own value to differ between them.
As conditions, there are blocks of conditions. The blocks are combined with OR, so whatever inside one of these blocks is being determined, will influence the output. In each block, there is an EACH that walks over the recipe signals and gives exactly one match for one recipe signal. There are 4 blocks, one for each recipe. The 1st block contains the conditions for the 1st recipe, the 2nd block the conditions for the 2nd recipe, and so on.
The EACH is used, because it "saves" internally matching signals that can be output with an EACH at the output. The EACH at the output collects the matching signals from all the EACH of the input, but only those whose other conditions (combined with AND) also match. So the 1st EACH outputs the 1st recipe signal if the conditions from the 1st block match, the 2nd EACH outputs the 2nd recipe signal if the conditions from the 2nd block match and so on.
This works similar to a select ... case statement, with just 1 combinator.
The flickering isn't due to that general combinator design. It's because of fluid flushing on recipe change. If some fluid level goes below 1000, the corresponding fluid recipe gets selected to create more of that fluid. If the previous recipe consumes that fluid, and that fluid is flushed back from the foundry fluid buffer due to the recipe change, the level is again back over 1000, and the previous recipe is selected again. If it works or flickers depends on the question if the level goes above the threshold on flushing or not. It cannot go permanently below the threshold in my example (posted in that other thread), because the fluid input and output are on opposite sides and I connected just one side, so the fluid can go out, but it cannot go in, or vice versa, without manually rotating the foundry.
You added these missing pipes, but now there isn't any flushing for the case there is a casting recipe active and you want to change away from that recipe: it will not change until the input fluid is empty, which needs one more set of valves/pumps. Because of these kind of edge cases, I gave up that general design.
Count the tiles: you already need as much footprint for pipes and tanks as a 2nd foundry needs. And currently, we just throw away any trashed solid material. On a real factory, we need to feed this back into some loop, which needs more space, so we don't save even the 3rd foundry footprint. May be even more, if you count unusable single tiles within. So there goes any space footprint advantage over 4 separate foundries.