I find it more ridiculous to assume that the development team decided to nerf a single items recycling time, almost 2 years after release for no apparent reason.

I probably can't articulate why very well, but I genuinely don't know why you would believe this. Wube strike me as particularly strong ...

I don't know specifically about mmmPI's point, but the developers have made it fairly clear about using mechanics to dis-incentivize hand-crafting. Or more specifically, not adding mechanics that would help hand-crafting.

And this should not be blindly assumed to be the right course simply ...

I'm not sure what chain of logic leads you to think aobut spoiling seeds, but I quoted the reason to do this -- to have a seed stockpile -- and the primary application is the opening post of this thread -- for people having problems with factory design that "cause fruit to be stopped processing and ...

I am absolutely convinced that this is not a nerf to concrete recycling but a buff to quality iron production on Fulgora.

Then you are absolutely wrong, because it is objectively an enormous nerf to concrete recycling. The suggestion is mildly ridiculous, frankly, because iron ore is not useful ...

I feel like some dedicated process that allows to increase seed chance at a worse mash/nutrient output would benefit people like me (if there are any that is) and give more room for experimentation while being secure in knowledge that I have a seed stockpile and don't have to run around exploring ...

Yes it's not that bad. But also, "it's not that bad" isn't a reason to make a change like this, which introduces inconsistencies and harms the player experience for no discernible reason.

Steel is an interesting point of comparison, because crafting up to steel chests to recycle it faster is ...

All movement speed bonuses should just be active all the time, whether you're flying or not. The whole point of mech armor is that it lets you ignore buildings and terrain. If it doesn't "just work" and you still have to think about what you're moving over, what's the point?

If I understand your use case correctly, this may be satisfied perfectly in 2.1.10 by using the brand new "recipe product" blueprint parameter.


A wildcard like what is being suggested would be strictly better than a blueprint parameter, because it would allow you to change the recipe later ...

worph wrote: Mon Jul 13, 2026 6:30 pmYou can still use hazard concrete to void concrete fast. You just have to deal with bricks and iron ore instead.

No you can't? Hazard concrete now has the same recycle time as concrete, and recycles to the same products.

This complaint dominated discussion on Reddit for a while, and I have not heard a compelling reason beyond "I was using it before and now my factory doesn't work." That does suck, but it's not a balance argument.


"This existed for 18 months and wasn't unbalanced" is, in fact, a balance argument ...

I believe the reasoning given for why this wasn't done is that it allows a productivity exploit in which you can raise the productivity bar with low quality crafts then trigger the bonus item with a higher quality craft.

I'm skeptical this is actually a problem though. It seems like a neat puzzle ...

According to the devs they discussed concrete recycling not taking the 10x recipe output into account during 2.1's development and decided it was intended.

I'd like to know what the reasoning for that was, and why they thought it was necessary to increase the time needed to void concrete on Fulgora ...

+1

I don't know what the intended impact of this change was. Was anyone sitting around cursing hazard concrete for making concrete recycling more efficient? Scrap processing was still roughly 40% item voiding by building count, it's hard to argue hazard concrete recycling was unbalanced in any way ...

Bumping as well because I thought this is how the 2.1 changes were going to work, and it isn't. The fact that it's still impossible to send both contents and ingredients out of a machine at the same time in any useful way is an enormous oversight, in my opinion.

I mean isn't this the exact thing ...

Currently if you have a space platform that is intended to provide some item to a planet or another platform, there isn't a good way to get it to wait until it's fulfilled that request. You can set it to wait for inactivity, but this will cause it to wait longer than necessary, and without careful ...

When setting a space platform's requests via circuits, the request source will be both platforms and planets, with no way to set them otherwise. This is incredibly limiting. There should be a way to limit circuit based requests to either platforms or planets, or either.

One concrete example for why ...

1.1 fluids weren't an actual challenge to solve except in the very simplest cases, because they were fundamentally inconsistent and impossible to meaningfully debug. Solving them mostly just meant adding pumps by trial and error until things worked.

Not that it couldn't theoretically be improved ...

In 2.1 items can be transferred between platforms, which is great. I expected players to be able to move directly between platforms as well, but it looks like they can't.

This would be nice to add. The drop to planet button could allow other platforms in orbit to be selected as well.

In 2.0 if you hovered over a fluid entity like a pipe it would show the colored indicators for the entire network the entity was connected to. This was removed in 2.1, in favor of showing the indicators for all networks whenever you have a fluid entity in your hand.

Please bring the old behavior ...

Give the buildings a dummy pipe segment internally, or whatever, so they can pull in the same way non-passthrough buildings do.


I reread the FFF, and I guess this is how the system worked before?

My thinking now is that the change to remove the internal fluid buffer was just unnecessary to ...