Steam engine fluid types. Array?

[eradicator]

One problem though might be changing fluids. You might end up with half a cycle of fluid left in the box. It can't flow out because the new fluid blocks it and it won't be consumed because it's less than one cycles worth. You have to deconstruct and reconstruct the "boiler". But a) how often do you do that? b) add a pump at the end of boilers and drain them if you don't want to deconstruct/reconstruct.

I think you're confusing something. The new $furnace-boiler would require a similar layout as the normal boiler, that is two fluid boxes, one for input and one for output. The input box would simply also allow flow-through. If you tried to define a recipe with in and output fluids on an entity with only one fluid box i have no clue what would happen. Lucky guess: Either there's a check for it and it errors, or something horribly breaks.

The point was to have a boiler that produces byproducts based on input_fluid_type, was it not?
[Edit: Didn't read properly. Ignore]

[mrvn]

One problem though might be changing fluids. You might end up with half a cycle of fluid left in the box. It can't flow out because the new fluid blocks it and it won't be consumed because it's less than one cycles worth. You have to deconstruct and reconstruct the "boiler". But a) how often do you do that? b) add a pump at the end of boilers and drain them if you don't want to deconstruct/reconstruct.

I think you're confusing something. The new $furnace-boiler would require a similar layout as the normal boiler, that is two fluid boxes, one for input and one for output. The input box would simply also allow flow-through. If you tried to define a recipe with in and output fluids on an entity with only one fluid box i have no clue what would happen. Lucky guess: Either there's a check for it and it errors, or something horribly breaks.

The point was to have a boiler that produces byproducts based on input_fluid_type, was it not?

That was one point, I thought you mend the other, sorry.

So the point is: A boiler that has some residue from boiling dirty water into steam, e.g. salt when boiling normal sea water.

You are saying this is possible with normal boilers?

[eradicator]

So the point is: A boiler that has some residue from boiling dirty water into steam, e.g. salt when boiling normal sea water.

You are saying this is possible with normal boilers?

No. I'm saying it might actually be possible to emulate a boiler with a furnace type entity to have that effect. (Like you suggested somewhere and i doubted initially?).

You said:

It can't flow out because the new fluid blocks it and it won't be consumed because it's less than one cycles worth.

And it sounded to me like you were assuming the output fluid would go into the input fluidbox. And if you're not assuming that i have no clue what you meant with that sentence.

Narf. I should stop posting when tired. I completely failed to read that post properly .
When switching the working fluid in an existing setup i actually like the idea of having to "pump out" the residue from before as a gameplay element. And most players probably already have a learned fear of pumping fluids into non-empty pipes already so i think it wouldn't cause any user issues. But yes. This would happen. Unless maybe if you make the recipe use 0.1 fluid as input, which might still be a valid thing to do depending on how the math turns out.

[alercah]

With the fluid changes in 0.17, could this be revived? Since fluidbox filters are no longer used in flow calculations since the entire fluidbox network needs to be locked to a fluid.

EDIT: Actually I guess they're still used for temperature? But even if you allowed every fluid to have a different temperature filter, you'd be able to cache that when the locked fluid changed.

[mrvn]

@bobingabout

Took me a while to get around what you were saying, until i looked at the current definition of the boilers fluidbox:

fluidbox

Code: Select all

    fluid_box =
    {
      base_area = 1,
      height = 2,
      base_level = -1,
      pipe_covers = pipecoverspictures(),
      pipe_connections =
      {
        {type = "input-output", position = {-2, 0.5}},
        {type = "input-output", position = {2, 0.5}}
      },
      production_type = "input-output"
    },

...which is actually a single box with two seperate in-out positions just like you suggested. So if that works correctly with recipes i'd have to withdraw my earlier post and agree that it might actually be possible to mod in what @mrvn suggested. I don't think the minimum-amount required would cause much of a problem because in a closed pipe system you'd still have an equal amount of in- and output so it shouldn't matter. Worst situation is that you need to wait a bit until all the pipes fill up. And if you're low on input-fluid then you get some stuttering instead of a continous lower output, but that should at most affect the network graph and nothing else.
You do end up in a situation where the new "furnace-boiler" accepts all fluid types though, so you have to be clear enough in the naming as to not "confuse the player" about which fluid types should go in there. But i guess that can be written off as part of the learning curve.

One problem though might be changing fluids. You might end up with half a cycle of fluid left in the box. It can't flow out because the new fluid blocks it and it won't be consumed because it's less than one cycles worth. You have to deconstruct and reconstruct the "boiler". But a) how often do you do that? b) add a pump at the end of boilers and drain them if you don't want to deconstruct/reconstruct.

Now that pipes won't connect with the wrong fluids is that still a problem? Or at least not an unintuitive one. You have to deconstruct/reconstruct all boilers for the pipe to loose the fluid type and be marked as empty so you can connect some other fluid.

If the boiler is actually an assembly machine instead of a furnace type entity then changing the recipe would push out any remaining fluid and possibly void it if no pipe is there. That might be the best choice. The available recipes would also tell the user what can be boiled to steam.

[FuryoftheStars]

With the fluid changes in 0.17, could this be revived?

I'm wondering the same thing.

So specifying a list/array of different accepted fluids isn't supported in the fluidbox at all, and would currently murder performance if it was hacked in (going through a whole list of accepted types for all filtered inputs etc.)

Klonan, any chance that after almost 2 years and recent changes that it's possible to accomplish this without the performance hit?