Discussion: Gas system revamp.

[WardBenjamin]

"A Grand System of Gasses, Leaks and Pumping"

How should we proceed from the room-based solution that we have now, with gases leaking through doors and open airlocks? I've seen several mentions of piping and ventilation systems, CO2 scrubbers, and other interesting things.

(Also see #284)

Discuss!

[kd7uiy]

I was just going to open something about this!

First of all, I think we need a way to operate in a vacuum first, a space suit. Otherwise, it's just not going to be very easy to do anything.

Secondly, gas should be able to move between rooms with open doors, and escape if not properly prepared. An airlock should minimize the gas exchange/escape.

Third, the O2 should slowly be used in a room. If there is no O2, a person should likely die. A space suit has a limited amount of air for working outside.

[Sommerbo]

Gas amount(tile count) should be taken into account when filling a room.

[koosemose]

I think in general room-based is the best approach, as anything smaller scale would likely be too costly for not enough a benefit. @Sommerbo is correct, we need to ensure the roomsize is taken into account when filling it. Ill effects from improper gases in a room shouldn't be implemented until protection from gases (or lack thereof) is available.

A little tightening up is needed on gas leaking, I noticed gas will never quite fully disappear when leaking outside (it just drops to increasingly tiny numbers, I think it got down around 10^-19 before I stopped it, at some point it just needs to vent completely. I haven't gotten around to checking if a similar issue with leaking vanishingly small numbers happens when leaking to another room.

Once that's tightened up, it should be easy to implement a furniture that can force gas to flow at a certain rate and possibly force it to go in a certain direction (possibly 2 separate furnitures) along with being able to be closed off (will possibly need the ability for characters to interact with furnitures beyond the current building focused system).

At some point a decision needs to be made in how complex a breathable air simulation is wanted. Is it simply a question of there being enough oxygen to breathe, should CO2 be generated and need scrubbed/vented, should you also need a proper mix of Nitrogen? I personally think the first or maybe the second would be preferable, the third seems a higher degree of scientific simulation than I imagine the average base builder player would want.

[WardBenjamin]

I personally am all for the O2/CO2 system, but it's not like it couldn't be changed in the future if we want to.

[fre-ber]

I think that it would be cool to have alien characters who require different gas mixtures at different pressures so that the base will have to be split into sections with internal airlocks.

[koosemose]

I am currently looking into revamping the gas system (currently only working with oxygen), how long do people think it should take 1 o2 generator to fill up, say a 5x5 room (5x5 inside the room, so 7x7 walls)

[Dormanil]

n = (75 m³ · 20 265 kg/(m·s²)) / (8.314 kg·m²·s^-2·K^-1·mol^-1 · 293.15 K) n ≈ 623.6025 mol

If we assume 20 moles of gas per second, it would take about 31 seconds to fill a room of 5x5 tiles with a nice and healthy 0.2 atmospheres of oxygen.

Since pressure and amount of ideal gas are directly proportional, adding 0.8 atmospheres of nitrogen to get similar pressure as on earth would take about 124 additional seconds.

I'd personally get a higher grade gas pump/generator, but two minutes and 35 seconds sounds like a sensible amount of time.

(Yes, I used the ideal gas law, because honestly, at these pressures we really don't need the extra headaches from molecular size and intermolecular attraction. And if we go higher than these pressures, our little green aliens die before they notice that the pressure is lower than they predicted.)

[fre-ber]

Now this looks more like the rabbit hole I almost fell into. ;-)

[kd7uiy]

Ideal gas law is the way to go for certain. I think we should ignore the temperature, that's just a level too complex, let temperature have it's own penalty.

I would likely avoid O2, but having CO2 seems like a good idea.

[Dormanil]

I mean, as long as we are dealing with gases and some of our alien friends are not aquatic, the ideal gas law continues to work.

I personally would like a proper gas mix for our space station occupants to live and breathe in. Pure high pressured oxygen is toxic after all. And no matter what species those occupants are, no matter what they breathe, they should use some of that air and have exhaust gases, for lack of a better term. Otherwise, all you'd need to care about when keeping gas levels at proper margins would be gas leaks, and that would be a little boring, wouldn't it?

[koosemose]

The level of micromanagement, or at least different machines to generate a proper gas mix sounds like pure drudgery. And either you need to be able to adjust the machines precisely, or each produces the proper amount of gas so that even numbers of each will produce the appropriate mix which only adds having to build more machines. Or you could have to build a certain number of each to get the proportion right, and that would require accurate knowledge or a tutorial, and with a tutorial it is just "Do what the tutorial said, and build all these machines".

[koosemose]

Ok actually decided to look up how it's done on the ISS, the primary source is electrolyzation of water (and in turn eventually turning the everything back to water). The system isn't a perfect cycle and doesn't completely fulfill the oxygen needs so additional methods are used, and water of course is occasionally shipped up to replenish. The only other thing that IS needed is an inert gas (we of course use nitrogen), which is pretty much just shipped up, and really only needs replaced if there is a leak. At most you would need a way to generate nitrogen or just ship it from somewhere (presumably buy it), and only use it when initially setting up and in case of leaks. It still doesn't sound like a hugely interesting system, and, to me, feels like complicating things for complications sake.

[fre-ber]

One simplification could be to rename the O2Generator to AtmosphereGenerator and have it produce both nitrogen and oxygen at the correct ratio. If we later want atmospheres that suit aliens, we could simply add more types of atmosphere generators that produce other gasses at different ratios or even make the atmosphere generator have a UI element that allows the player to set how much of what gas to produce.

The system doesn't have to mimic reality in every detail, but I think that this level of complexity could be interesting.

[Sommerbo]

We could require that two gas generators are built (oxygen & nitrogen) and then have a computer/controller where you set your desired ratio. This could handle none human atmospheres too, by building desired generators and setting ratios. Computer/controller could also be used to vent existing gases into space.

Another thing struck me gas pressure are we just gonna assume that we keep it at 1 atm or do we model gas pressure?

Example: We have an enclosed area (no leaks) with human atmosphere if we add a Argon gas generator and set the gas mixture to be 20% oxygen and 80% Argon, do we "overwrite" the Nitrogen or do we keep it and increase pressure.

We could assume that computer/controller automatically vented all gasses and then filled it up again with desired gases for a simple and intuitive game experience.

Or venting must be done manually by player. Or we do something else like model gas pressure and so on.

I think an accurate representation could be fun for programmers to create but resulting micro is probably annoying as hell for player, but still something to ponder.

[koosemose]

For now, I'll leave it as just oxygen internally, and perhaps look into changing names and descriptions to imply it is generating an appropriate mix. I do like the idea of the generator by default generating the right mix, so that those who want to keep it simple can do so, and those who want to try to micromanage the setting for some kind of advantage have that option.

For now my primary goal is really just to get numbers tweaked appropriately, and will just be tweaking numbers to match @Dormanil's times. Any further changes will probably require a greater consensus.

[koosemose]

The more I poke my nose around in this the more dissatisfied I am. I can easily get generation to match the desired times (.16 gas per second does it close to exactly), however, my options as it stands now, is to either generate .2 atmospheres of oxygen (and we just pretend there is nitrogen hiding in there), or generate 1 atmosphere, and label it as breathable air or something (or leave it as oxygen and let it be even more weird) but that wouldn't work in the future if we start adding other gasses. As it stands now a gas generator is only capable of generating one type of gas (at least without some serious weirdness with the parameters), as furnparams currently autoparses the value to a float, which also means that for now oxygen is hardcoded to be what's generated. We either need more complex params, or tags specifically for gas generation, I'm not certain which route would be desirable.

[kd7uiy]

Apollo had an atmosphere of pure oxygen. That would be a reasonable option I suspect.

Also, usually a generator manages all gases, but requires some kind of an input to produce each kind of gas. We could have one generator, with an O2 tank and an N2 tank that need to be replenished at some interval. The CO2 could be produced when there's a person in the room, taking O2 away slowly.

As for the generation, let it check the available supply and generate for each type. I can't remember how that code works, but it shouldn't be too bad to manage...

[koosemose]

Apollo's pure oxygen didn't work out so well. As is the only way to generate multiple gases would be to hardcode it in, which would of course work for now, but doesn't work so well in the future, for example if aliens with different atmospheric requirements comes along. I'd rather figure out a reasonably good way to designate the mix in xml now. And as a side note, even a modern o2 generator only inputs water (which in turn gets partially recovered from waste gases) so a futuristic one should be at least that capable (and at least that simple). I can find very little information on ISS's n2 handling other than that they occasionally ship up tanks of it, and not very much, since it is only lost through leaks and other such things, so doesn't get used up very fast.

[kd7uiy]

It worked out, just not in the really high pressure on the ground. Still, having O2 but not N2 could add a fire risk, which might be interesting? Hmmmm...

[fre-ber]

@koosemose Yeah, I thought that I had implemented this in my own version of this project but now when I looked at it I found this:

    protected void Update_AtmosphereGenerator(Fixture fixture, float deltaTime)
    {
        Room room = fixture.tile.room;
        float desiredPressure = fixture.floatParameter["desiredPressure"];
        float massPerSecond = fixture.floatParameter["massPerSecond"]; 

        // TODO: What gases are generated and at what percentage should be parameters, but it
        //       would be a complicated parameter type, i.e. a list of name-percentage pairs.

        float desiredPercentageN  = 0.79f;
        float desiredPercentageO2 = 0.21f;
        if (room.atmospherePressure < desiredPressure)
        {
            float totalMassToGenerate = massPerSecond * deltaTime;
            room.AddToAtmosphere("N",  totalMassToGenerate * desiredPercentageN);
            room.AddToAtmosphere("O2", totalMassToGenerate * desiredPercentageO2);
        }
    }

[koosemose]

The more I think about this, the more I realize that, unless there is a way to store multiple values in a single value in an attribute (such as GasType="O2,N2" GasRatio=".2,.8") and being able to get them back out properly, we're going to need XML tags (and matching variables in furniture) specific to gas generators if we want to have gas generators capable of generating more than one gas type.

[kd7uiy]

GasTypes=2 Gas1=O2 Gas1Ratio=.2 ...

On Aug 21, 2016 4:21 PM, "koosemose" notifications@github.com wrote:

The more I think about this, the more I realize that, unless there is a way to store multiple values in a single value in an attribute (such as GasType="O2,N2" GasRatio=".2,.8") and being able to get them back out properly, we're going to need XML tags (and matching variables in furniture) specific to gas generators if we want to have gas generators capable of generating more than one gas type.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/TeamPorcupine/ProjectPorcupine/issues/302#issuecomment-241279493, or mute the thread https://github.com/notifications/unsubscribe-auth/AFrPJaYFbHcAeVQnlEgFBd4ixlhdsH-0ks5qiLMvgaJpZM4Jotks .

[koosemose]

Hmmm... that would be workable, but still feels a bit hackish. Especially considering a modder accessing it from lua in the future, having to do all the concatenation and looping, when they really should just able to get a list of gas types and use those to get ratio and rate and whatever else.

[fre-ber]

In my project, I changed the atmosphere code so that I have a class named GasMixture, it contains a dictionary of gas name(string) and amount (float). For the amount I used kg, but I am sure that I could just as well use the percentage of one Earth atmosphere as a unit as we have here now. Now, in my code, each room has one instance of the GasMixture class and the amount represents how much of that gas component there currently is in the room.

If we somehow make a parameter system for furnitures, or anything else for that matter, that can hold both simple and complex types, we could let the atmoshere generator have a single parameter of type GasMixture where the amounts indicate desired amount or pressure.

The trick is to make that parameter system in a clever way. If the GasMixture class itself has methods for loading and saving to XML, that part is easy, but I don't have a good idea about how to represent it as a parameter in the model.

[koosemose]

I think I've got it!

Adding an element, I'm thinking ParamList would be an appropriate name, that can be put in Params that can contain other (multiple) Params (or ParamLists), I think get's us what we need. As an example here's what I think the O2 generators params would look like with this:

        <Params>
            <!-- <Param name="gas_name" value="O2" /> -->
            <Param name="gas_limit" value="0.2" />
            <Param name="gas_per_second" value="0.16" />
            <ParamList name="gas_gen"> 
                <ParamList name="O2">
                    <Param name="gas_limit" value="0.2">
                </ParamList>
                <ParamList name="N2">
                    <Param name="gas_limit" value="0.8">
                </ParamList>
            </ParamList>

        </Params>

This would of course require changes to furnParameters, allowing it to store multiple types of objects, I think there's a WIP PR that does this with a Parameter class, this could be further changed, either to have an option for it to contain a Dictionary (that would in turn contain further Parameters), or a subclass, or some other means to allow either of them to be stored in furnParameters.

[Dormanil]

This really seems like a smart way of dealing with this special problem while keeping it general enough to have other furniture be able to use it as well. Good thinking, @koosemoose!

[koosemose]

BOOYAH! I've got it. I had to make a few decisions I'm less than happy with (for example, Param and ParamList are both Param, due to some oddities I couldn't straighten out with subReader, and ReadToSibling needing the tag name). But I've got it, and now have the O2 Generator generating both Oxygen and Nitrogen in the appropriate ratios, and it is not hardcoded. It will take me a while longer to clean up the terrible mess I made trying to get the XmlReader to behave, then properly document things (or at least something approaching documentation), and then make sure it can actually merge with the current version without conflicts.

[fre-ber]

Awesome! Good job!

[kd7uiy]

Is there more to be done with this, or should we just close this?

[vogonistic]

We have a continuation discussion in #704 for the remaining features.