Steam engine fluid types. Array?

[bobingabout]

There is already two types of water in my mod, and I don't see why it shouldn't be possible to make steam from both of them

This isn't really a problem right now, because the water from the offshore pump is what you'll likely be using.

However, because Electrolysis is a key part of my mod, I want to add Salt water too (so that it actually makes sense having to boil water to get salt, to add to pure water), unfortunately what I plan to do might mess with how steam engines work.


Is it possible to make it so that the generator tag can accept an array of fluids, not just one?
So this

Code: Select all

 fluid_input =
    {
      name = "water",
      amount = 0.0,
      minimum_temperature = 100.0
    },

could become this:

Code: Select all

    fluid_input =
    {
      fluids = {"water", "pure-water", "lithia-water"},
      amount = 0.0,
      minimum_temperature = 100.0
    },

or this

Code: Select all

    fluid_input =
    {
      {
        name = "water",
        amount = 0.0,
        minimum_temperature = 100.0
      },
      {
        name = "pure-water",
        amount = 0.0,
        minimum_temperature = 100.0
      },
      {
        name = "lithia-water",
        amount = 0.0,
        minimum_temperature = 100.0
      },
    },

[bobingabout]

Same request, but now on boilers.

Possible?

[Mooncat]

Just realized the new fluid_input and fluid_output properties have broken almost all the fluid related entities in Creative Mode (except Fluid Source, because it is an assembling machine).

Would be perfect if they, or their "name", are optional:

• If fluid_input is not provided, the entity can accept any fluid type.
• If fluid_output is not provided, it will output the same fluid as input.

[bobingabout]

Although that would work too, I would want to limit the sources to those with "Water" in their name, something that when evaporated will create steam.

So, in the example above, it would only accept Water, Lithia water, and Pure water.

Now a question I was asked was... why would you want to boil Lithia water for steam? well, long story short, you might be wanting to place a steam based power plant in "The middle of nowhere" were there is no access to use an offshore pump, meaning you'll need to get water elsewhere. You could barrel and unbarrel it, or even use the fluid wagon, but in my mod there also exists the option to mine it from a water splotch similar to oil. There are currently 2 types, Lithia water, and ground water (Ground water currently produces "water", but with some of my planned changes, will likely change to "pure-water")

In 0.14, it didn't care, you could boil either type of water and it would work. in 0.15, you're limited to offshore pump, or ground water for your water source, Lithia water no longer works. And with my planned changes (to introduce pure water, basically to make my implementation of electrolysis make sense(Water simultaneously has salt, which you can boil to get salt from, and is pure which when electrolysed gives hydrogen and oxygen, and you need to add salt to make it give chlorine)), you would be limited to the offshore pump.

Now, which the relatively simple idea of boiling water to get steam, I don't want to limit people too much, and would rather allow ANY type of water to give steam, which you currently just can't do (unless you specifically make custom boilers to boil each type of water), in fact, replacing the boiler entity entirely and using a custom furnace that takes in water and outputs steam, auto-changing the recipe according to the type of water going in seems like the only viable option.
Though that raises the questions:
Can that be powered by heat? (Needed for a heat exchanger type boiler)
can that actually be used instead of boiler entity? (Boiler knows heat, and reports related values to the player, a furnace entity would just use a recipe and wouldn't take starting temperature into account, and wouldn't report how hot it makes water to the player. It WILL work, but wouldn't fit as nicely as base game boiler)


So... the "Ideal" solution in my opinion is to allow the boiler (And maybe steam engine too) to accept a specific array of fluids that it will boil into steam.

[Klonan]

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.)

But i have removed the 'required' filter for 0.16, so now steam engines/boilers can have a defined input/output filter in the fluidbox, or have none
So they can work like in 0.14, where boilers can accept any fluid, steam engines can consume and fluid etc. if they are defined without a filter

For instance the 0.16 boiler definition:

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",
      filter = "water"
    },
    output_fluid_box =
    {
      base_area = 1,
      height = 2,
      base_level = 1,
      pipe_covers = pipecoverspictures(),
      pipe_connections =
      {
        {type = "output", position = {0, -1.5}}
      },
      production_type = "output",
      filter = "steam"
    }

The 0.16 steam engine definition:

Code: Select all

    fluid_box =
    {
      base_area = 1,
      height = 2,
      base_level = -1,
      pipe_covers = pipecoverspictures(),
      pipe_connections =
      {
        { type = "input-output", position = {0, 3} },
        { type = "input-output", position = {0, -3} },
      },
      production_type = "input-output",
      filter = "steam",
      minimum_temperature = 100.0
    }

Also all fluidboxes will now support filters, so if you make some special 'hydrogen-pump', you can specify that it will only allow hydrogen to enter

[eradicator]

Also all fluidboxes will now support filters, so if you make some special 'hydrogen-pump', you can specify that it will only allow hydrogen to enter

Oh. My. Did you just invent my-fluid-only tanks and pipes? That's awesome . (And now i'll go sit in a corner and fantasize about changing that filter during runtime and allow players to build filtered pipe networks...)

Btw, you say it's now (then? ) possible to not specify any filter to allow all fluids, would it be possible performance wise to filter for "gas" type fluids as a second group?

[Klonan]

(And now i'll go sit in a corner and fantasize about changing that filter during runtime and allow players to build filtered pipe networks...)

Added for 0.16:

Code: Select all

fluidbox.get_filter(index) → table

The filter of the given fluidbox index, 'nil' if none.

Parameters
index :: uint
Return value

    name :: string: Fluid prototype name of the filtered fluid.
    minimum_temperature :: double: The minimum temperature allowed into the fluidbox
    maximum_temperature :: double: The maximum temperature allowed into the fluidbox

or 'nil'.

And

Code: Select all

fluidbox.set_filter(index, table) → boolean

Set the filter of the given fluidbox index, 'nil' to clear. Some entities cannot have their fluidbox filter set, notably fluid wagons and crafting machines.

Parameters
index :: uint
table: Table with the following fields:

    name :: string: Fluid prototype name of the filtered fluid.
    minimum_temperature :: double (optional): The minimum temperature allowed into the fluidbox
    maximum_temperature :: double (optional): The maximum temperature allowed into the fluidbox
    force :: boolean (optional): Force the filter to be set, regardless of current fluid content.

or 'nil'.
Return value
If the filter was set sucessfully.

[eradicator]

Added for 0.16:

Ooh. With temperature! High temperature pipes here i come! Oh wait...if name is mandatory but temperature optional i guess generic high-temperature pipes aren't going to work. Why is it that if i see an awesome new feature the first thing i think of is what i can't do with it. Something is wrong with me. Regardless. Awesome! Thanks! Now i just need to set my time machine to the release day of 0.16...

Also the forum is lacking a worship-smiley for occasions like this ;).

[bobingabout]

It's a bit of a shame that the filter is either a single fluid, or no filter at all, but I understand the problem.

Thank you for your time working on this, Klonan.

[darkfrei]

The 0.16 steam engine definition:

Code: Select all

    fluid_box =
    {
      base_area = 1,
      height = 2,
      base_level = -1,
      pipe_covers = pipecoverspictures(),
      pipe_connections =
      {
        { type = "input-output", position = {0, 3} },
        { type = "input-output", position = {0, -3} },
      },
      production_type = "input-output",
      filter = "steam",
      minimum_temperature = 100.0
    }

So, if I have two fluids, then they both have the same min_temperature?
Why not the table?

Code: Select all

filter = {"steam"},

[Klonan]

So, if I have two fluids, then they both have the same min_temperature?
Why not the table?

Code: Select all

filter = {"steam"},

I don't quite understand...

Having two filters on a fluidbox is just not supported, adding supported would basically mean rewriting half of the fluidbox code, and ruin performance

[mrvn]

Shouldn't there be a "recipe" for boilers that has water as input and steam as output, lithia water as input, steam as output and so on?

And if you boil (dirty, salty) water you should get a dirt or salt residue that an inserter has to remove. Screw electrolysis, boil away the water to get at the salt.

[eradicator]

@Klonan:
Thinking about this a bit more: As far as i understand a filter can be defined in a prototype (data.lua) or on-runtime with control.lua.
A) This seems to imply that even if i tried to make a special "my-awesome-fluid" tank that is supposed to only hold that one fluid... the filter could then afterwards be overwritten on-runtime to something else (or even no filter)?
B) Or does a prototype-defined filter imply that it can't be changed on-runtime anymore and only fluidboxes that don't have a prototype-defined filter can be changed on-runtime?
C) And does the prototype also support min/max_temperature?

I had those thoughts because i was thinking that, if any fluidbox supports filters now (i.e. in 0.16), it might be feasible to have a mod that provides a universal gui to interact with those filters. But then i'd have to somehow account for fluidboxes that aren't supposed to be changed. I guess i could read the prototype myself in control.lua and then just refuse to change it if it's defined there. But some other mod doing something similar might still (without bad intent) allow to change the supposed-to-be-fixed filters on my own entities.

-----------------------------------------------------

Shouldn't there be a "recipe" for boilers that has water as input and steam as output, lithia water as input, steam as output and so on?

As said in above post:

Some entities cannot have their fluidbox filter set, notably fluid wagons and crafting machines.

This is probably because they already set the filters on their fluidboxes themselfs. And my guess would be that this implies that boilers don't have any recpies.

[bobingabout]

So, if I have two fluids, then they both have the same min_temperature?
Why not the table?

Code: Select all

filter = {"steam"},

This is effectively the original request, and he answered why he can't do this in his opening line.

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.)

[mrvn]

Shouldn't there be a "recipe" for boilers that has water as input and steam as output, lithia water as input, steam as output and so on?

As said in above post:

Some entities cannot have their fluidbox filter set, notably fluid wagons and crafting machines.

This is probably because they already set the filters on their fluidboxes themselfs. And my guess would be that this implies that boilers don't have any recpies.

So maybe replace the boiler with a furnace that produces stream using recipes instead of fluidbox filters.

[eradicator]

So maybe replace the boiler with a furnace that produces stream using recipes instead of fluidbox filters.

Go ahead, make a mod that adds one then? Though you loose the pipe-through-capability for excess water of a real boiler.

[mrvn]

So maybe replace the boiler with a furnace that produces stream using recipes instead of fluidbox filters.

Go ahead, make a mod that adds one then? Though you loose the pipe-through-capability for excess water of a real boiler.

Bummer, yes, that would suck.

[bobingabout]

So maybe replace the boiler with a furnace that produces stream using recipes instead of fluidbox filters.

Go ahead, make a mod that adds one then? Though you loose the pipe-through-capability for excess water of a real boiler.

If you know what you're doing, you can still program that in.
The problem you'll encounter is you'll effectively have to design it in a way that it runs a full cycle of the exact amount required per tick, which reduces all the other problems.
The main one you'll probably encounter using the through pipe method, is that where a factory uses a fluid box with a level set so fluids can enter and not exist, a through pipe will have an even level, and act as a pipe, so if the levels in the pipe are low, then the cycle won't run. (Because where a boiler will boil UPTO the maximum throughput per tick, an assembling machine/furnace wants exactly the required amount at the start of every cycle. if the fluid is allowed to flow back out to fill the next one, this required amount may never be met unless you have a very low requirement.)

[eradicator]

@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.

[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.