Smelting Iron

[iteration2]

Has anyone come up with a solution to this that would work indefinitely? I had to dump some refuse CO2 into a pipe and just let it build up, which is a shame, because it wasn't a ratio issue. In fact, what I was dumping was something that was needed for the solution, but I didn't have enough reactors to combine the two CO2 outputs I had into one pipe...

[cake>pie]

Yes. (http://spacechem.net/solution/published-29-1/21840) (edit: new link. removed stray SYNC in reactor 3)
Reactor 1 β: Fe2O3 / Fe3O4 / 4(SiO2); ψ: Fe-O / O; ω: SiO2
Reactor 2 α: SiO2; β: CaCO3; ψ: Ca2SiO4; ω: CO2
Reactor 3 α: Fe-O / O; β: C; ψ: Fe; ω: CO2
Reactor 4 combining CO2
R1 is running a little faster compared to R2/3, so intermediate pipes will fill up and cause output blocking.


One of the biggest drawbacks of blast furnaces is the inevitable carbon dioxide production as iron is reduced from iron oxides by carbon and there is no economical substitute – steelmaking is one of the unavoidable industrial contributors of the CO2 emissions in the world.

No kidding. Test-solving this puzzle really drove the point home for me.

[iteration2]

Yes. (http://spacechem.net/solution/published-29-1/21838)
Reactor 1 β: Fe2O3 / Fe3O4 / 4(SiO2); ψ: Fe-O / O; ω: SiO2
Reactor 2 α: SiO2; β: CaCO3; ψ: Ca2SiO4; ω: CO2
Reactor 3 α: Fe-O / O; β: C; ψ: Fe; ω: CO2
Reactor 4 combining CO2


Mine starts pretty much the same way, except reactor 1 outputs Fe and O as individual atoms (in different positions). What I couldn't figure out was how get reactor 3 to combine the carbon with the random O's without sensors. I could split out the Fe from the O, but couldn't get the O-carrying waldo to always grab an O (sometimes it would grab nothing), which screwed up the CO2 production. So I had to split the O and Fe up first, and then make CO2 in it's own reactor.

[ExK]

hi cakepie, can you explain how does your reactor 3 work? I've the same issue as iteration 2. without a sensor, I can't make the CO2. so my solution is same as everyone's else - let it build up in a pipe. in fact, I even bond up all the O so that I need a shorter refuse pipe lol.

[cake>pie]

I noticed an unnecessary stray SYNC in the earlier solution I posted which may cause some confusion. Replaced the link with an amended version.

Here's a video (http://tinypic.com/r/2lo3jx4/7) of reactor 3 in action; hopefully adequate to demonstrate what it does.

I could split out the Fe from the O, but couldn't get the O-carrying waldo to always grab an O (sometimes it would grab nothing)

The key is ensuring that there is always an O.

Notice that Fe2O3 and Fe3O4 both have one O more than Fe. The staircase pattern in reactor 1 produces either Fe-O or O, with the O's in the same position. From reactor 3's point of view, every input-α will reliably get an O -- the randomness lies in whether it has an Fe attached to it or not. Crucially, trying to detach an atom of Fe that is in fact absent will not break the solution, whereas not reliably getting O's is definitely a much harder problem to surmount.

[ExK]

thanks cakepie, it makes sense. I think this kind of puzzles is more thought provoking than those that require phantoming the programming priority of the game. keep them coming.

[iteration2]

Yeah, my error was in breaking down the molecules too far in reactor 1. If I'd left the Fe-O pairs connected, I'd have had an easier time, but for some reason I thought it'd work better if I broke them down into individual atoms. But then I ran out of reactors :(

Anyway, my solution works, and isn't really slowed down at all (even throwing out a lot of my CO2, it's still not the last one to be completed). Just not as satisfying, knowing that, eventually, it would shut down.

[iteration2]

thanks cakepie, it makes sense. I think this kind of puzzles is more thought provoking than those that require phantoming the programming priority of the game. keep them coming.

I don't think I've found any puzzles that really require doing anything crazy with programming priority. Though remembering that red resolves before blue and taking it into account sometimes simplifies things.

Technically, you never even have to use either color to input or output to the opposite quadrant, because I only realized they could do that a couple weeks ago :p

<edit> Actually, I guess the "red before blue" rule is pretty important for all the puzzles that involve starting with constructing long carbon (or australium) chains using the simultaneous red input/blue bond+ commands. But I don't think you ever need to exploit the bonder priority. I never did, unless perhaps by random chance.

[ExK]

I don't think I've found any puzzles that really require doing anything crazy with programming priority. Though remembering that red resolves before blue and taking it into account sometimes simplifies things.

Technically, you never even have to use either color to input or output to the opposite quadrant, because I only realized they could do that a couple weeks ago :p

<edit> Actually, I guess the "red before blue" rule is pretty important for all the puzzles that involve starting with constructing long carbon (or australium) chains using the simultaneous red input/blue bond+ commands. But I don't think you ever need to exploit the bonder priority. I never did, unless perhaps by random chance.

How about Life: Cytosine? is it possible to solve that one without parallel operations and the 'red before blue' knowledge? Without the knowledge, I've a feeling that a solution can't even exist.

I agree with you that the bonder priority has so far been not very crucial for all the ResearchNet puzzles so far - and I hope it will stay that way. :(

[iteration2]

How about Life: Cytosine? is it possible to solve that one without parallel operations and the 'red before blue' knowledge? Without the knowledge, I've a feeling that a solution can't even exist.

Hmmm, I'm actually not sure. Although I don't really consider the "red before blue" rule as being particularly arcane. There are tons of instances in any puzzle in which both waldos activate commands at the same time, and it should go without saying that 2 commands can't happen literally at the same time. And since the atom must exist before it's bonded, it shouldn't take much trial and error to realize that one always happens before the other.

And ultimately, the problem with designing puzzles is that once you're aware of some rule or mechanic, you can't ignore it. If someone designs a puzzle that doesn't require knowledge of all the mechanics that more advanced players are aware of, then the puzzle might potentially be trivially easy for the very audience you're designing puzzles for.

My guess is that most players who are scrounging through ResearchNet in search of more puzzles tend to be pretty advanced.

[ExK]

ok iteration2, you do have a point there. if one likes the game enough to trawl this forum, I guess he/she must be pretty advanced - or frustrated lol.