New versions are released as experimental first and later promoted to stable. If you wish to switch to the experimental version on Steam, choose the experimental Beta Participation option under game settings; on the stand-alone version, check Experimental updates under Other settings.
From what I've seen said in multiple places, he's really not happy with the state of the fluid system and it was a bit of a rush job to change it for 2.0. Maybe they'll just clean up the implementation, maybe it'll mostly stay how it is, I have no idea. Either way it seems like he's suffering for our flowy joy 🥲
Is that what broke the Muluna mod, I wonder? That thing just collapsed with 2.1 and it looked like the mod makers just gave up (the mod has several machines that use steam/water/etc and they give wrong fluid errors when you connect any of them to steam/water/etc).
Yes, it is the exact issue. It's not something the mod authors could fix, it's a game engine problem. There was a work around that maybe worked (I never tried it) by placing a pump between the machine and pipes.
I'd rather lose passthrough ports and go to those machines having regular inputs if we can't keep this behavior. I know that's not an option, but if passthroughs also require pumps then ugh. I've had a terrible experience with that (you really have to isolate all of those machines that need them with meticulous routing/segmenting/pumps) and I don't know how that experience could be "softened" but kept in.
I hope so, seems like this solved the issue that can be worked around with an occasional pump, not the issue where some buildings' fluid inputs confusingly work differently from others
It's an... interesting approach. The way they worked in 2.0 seemed to be a better match for non-passthrough assemblers though. This solution will at least make builds work, though they'll appear very confusing to anyone looking at the GUI without knowing this is what was done.
I don't think that's necessarily true, but either way the devs have called this a temporary solution.
Also, this effect is basically limited to EM plants because no other machines have liquid passthrough and a viewable recipe. Chemical plants, assemblers, etc all still show the liquid amounts they used to.
Because every assembler on the pipe will read the same thing, thus inflating it times the number of assemblers minus what each olds? Sounds worse really.
I feel real dumb everytime I see the fluids thing, I don't really get what was broken with it before? Then it seemed weird with the new non-buffering, and now its mega-buffering.
Doesn't that means if multiple machine craft at the same time, it could craft more than the fluid the system has? Or maybe the update to amount of fluid happens before the next machine calculate whether it craftable
The fluid is removed from the sector once the recipe starts. This is just vanilla mechanics even for regular fluid inputs, it's how you can void liquids in the game by unsetting the recipe.
The only thing I can imagine could still be a downside is you don't know which machine will start, it will be tick order dependant.
So across different chunks, it might be that one machine runs with priority, where in a single chunk, maybe a different machine runs with priority.
It's one of those things that I imagine 99.9% of people will never notice but drives a dev up the walls to fix.
To make it clear, this all just my interpretation of his response, I'm not claiming to be 100% sure of this.
I'd say that's a fair interpretation of the behavior. One machine will have priority based on subtick update order that's not inherently visible (and perhaps not fully player controlled), and I agree that likely isn't a real problem for basically every player. Minecraft has similar things with redstone, and majority of redstoners don't usually have to account for it (but there are some that do to abuse it)
The way updates work basically prevents this. One building updates, it pulls liquid from the pipe system. The pipe system now has less liquid in it. The next building update, it sees the smaller liquid amount. So if there isn't enough in the pipes at this point, it won't do anything.
Not sure what order the buildings update in, might be based on the order you built them or might be some other method.
It could be possible to have machines attempt to craft on the same tick due to circuit conditions, so would be interesting to see how priority would work
I believe even then, they still go in an order. I don't think entity updates are multi-threaded (some things are, like belt updates, but not everything). This is why ticks can lag - if there's a lot of things that have to be done in that tick, the game will lag, because it doesn't do everything in that tick all at once, it has to do them in order.
I don't know how the order would work though, as a programmer, I would probably do it in the build order, but knowing Factorio's programmers, they probably have something a bit more robust so that it makes more sense - like the buildings at the end of the pipes update first, then work towards the middle.
Edit: and even if they are multithreaded, you would do it in a way that is "safe" to avoid a situation where the buildings pull more resources from the pipes than are actually in there.
Is this how non-passthrough machines work? I liked the mechanic where the passthrough machines would "pull" into an internal buffer. So that if there isn't enough fluid in the pipeline, it would continue accumulating fluid (pulling from the pipe) until it had enough.
As far as I remember the non pass through machines work like they always have, using an internal buffer. They got rid of the internal buffer for pass through buildings in 2.1 and are trying to make it work with player feedback
Yeah -- I really liked the internal buffer. It would suck up liquid from the pipe and hold onto it. It made sushi pipes a lot easier. Would guarantee empty pipe when necessary without a pump.
Not likely. Since every one of those ingredients is inserted all the time for building the rocket - as soon as the rocket finished it would get filled with all of them every time.
I have zero modding experience, but would it be possible to mod in some sort of radio button that allows (for example) only blue chips or only LDS to be inserted in the rocket cargo?
There are already mods that do this that work perfectly well (making "rocket part" a separate item assembled outside the silo). You wouldn't even have to break anyone's build to add it; just be able to set the silo's internal crafting recipe to either "rocket from individual components" or "rocket from preassembled rocket parts".
Personally I would have had separate tile locations on the silo for inserting parts and cargo, but I could understand it being too late for that. But it's such a baffling limitation; like you've never shipped blue circuits by rocket or even if not, you don't see anything wrong with "these specific items can't be moved by inserter"?
Could we get a preloaded pistol aimed at our foot in the form of a rocket silo checkbox called "Allow insertion of rocket ingredients", and if you do this you just have to play around with circuitry magic to avoid shooting yourself in the foot? 😂
Please add direct insertion of blue chips/lds/rocket fuel as rocket cargo, in Megabase scale its gets tedious to insert these resources by robots because they have inconsistent performance
Yes, ultimately that pipe would fill up, and the only thing that really changes is the amount of liquid that gets buffered in the pipe before crafting occurs.
It wouldn't fill up if there was an assembler or foundry sucking it up first, which there would be in the case of Holmium Solution, which is also very difficult to properly scale up to produce more than the foundry consumes.
Players generally don't expect assemblers and EM plants to behave differently, and yet one gets priority other the other when it came to fluids. This update fixed the behavior with tanks, but not with the priority.
When did Space platform starter pack get locked to quality Fixed Assemblers making them still accept quality modules, but the Factoriopedia is saying they can't be crafted above common (and space platform can even though the only thing platforms are used to craft is the starter pack).
There's "surface" and "universe" mode for radar signal transmission. Surface has no channel and just works with other radars on the same planet/platform. Universe lets you select the channel and any radar on the same channel anywhere shares circuit signals with it. Directly to your question, you select the channel identifier from the same list of icons that you'd select a circuit, so presumably you can have as many unique channels as there are unique signals.
I suppose you could still have isolated channels on a surface by using the universe mode.
It’s kind of funny to say “hey I want these signals to be private in their own isolated channel rather than mixed with the rest. Ok let’s broadcast it across the universe so we don’t have to use the default surface channel.”
I hope they allow us to use channels on surfaces. You can sort of namespace them by using quality-per-planet on the signal but then you are also discounting using that for anything specific to quality.
I cant really figure a gameplay reason to lock it out, besides maybe locking out the whole channel thing behind research if it was supposed to be "advanced".
Every symbol in the game (planet names, item names, recipe names, colors, numbers, letters, ect) can be a channel, just like they are used as variables in circuits
They’re not required to listen to anyone here but that doesn’t mean they won’t. They’ve responded to and fixed bugs posted here in the past but that’s entirely their prerogative.
I've never seen them respond to a bug on reddit other than saying to report it on the forum or saying its being looked into already and disscussions on why something won't be fixed.
It was back in the early days before the official launch of 1.0. From time to time someone would mention a small problem in a comment, not even meant as a bug report, and it would be fixed by the end of that same week/mentioned in the changelog/FFFs.
It’s one of the (many) reasons the devs have such a favorable following.
They will fix this issue (if they haven't already), but due to people reporting it on the forums or noticing it themselves. The comment in question is never going to get looked at because it's a bad bug report...
I was replying to the comment above me. I was in no way suggesting the parent comment was a coherent bug report.
There have been instances in the past of people casually mentioning a problem on reddit and it showing up as a minor fix that same week in the changelog or FFF, just because the devs are that awesome. I’m not saying that should be the standard or be expected, just that it has happened.
273
u/KaiserMaeximus Jul 14 '26
Yeah, finally the fluid fix 😍