Jump to content

Oxygen and Pressurized Environments


Recommended Posts

I know this may seem like an obvious thing, but I was wonderinf whether pressurizable environments would be implemented, and if so, how? For instance, in SE, you have to pipe up oxygen networks and it uses large mesh type devices for distribution.

 

I think it'd be cool to maybe be able to customize the size of "vents" and have smaller, more manageable pipes. I felt like the vents in SE were a bit too large

 

Thoughts?

Link to comment
Share on other sites

I know this may seem like an obvious thing, but I was wonderinf whether pressurizable environments would be implemented, and if so, how? For instance, in SE, you have to pipe up oxygen networks and it uses large mesh type devices for distribution.

 

I think it'd be cool to maybe be able to customize the size of "vents" and have smaller, more manageable pipes. I felt like the vents in SE were a bit too large

 

Thoughts?

Yes, but not in some gorey/explosive fashion hopefully. Just make a person have 30 seconds to get into pressurised area before dying.

 

(And yes, 30 seconds is how long you could last in vacuum before going poof :V )

Link to comment
Share on other sites

This is actually an interesting question. Space Engineers recently stopped setting the oxygen system as a default, as it caused heavy performance losses (Like anything in SE, it feels like). Oxygen in a mesh (like a cockpit) seems straight forward - but pressurizing an entire voxel spaceship brings a number of issues. The cheap way out here would be to integrate some sort of 're-breather' in the player characters suit, and call it a day...

 

Has anyone posted this as an ask us everything question?

Link to comment
Share on other sites

This is actually an interesting question. Space Engineers recently stopped setting the oxygen system as a default, as it caused heavy performance losses (Like anything in SE, it feels like). Oxygen in a mesh (like a cockpit) seems straight forward - but pressurizing an entire voxel spaceship brings a number of issues. The cheap way out here would be to integrate some sort of 're-breather' in the player characters suit, and call it a day...

 

Has anyone posted this as an ask us everything question?

Link to comment
Share on other sites

(Sorry still learning how to use quotes)

I was planning on posting it myself. I feel like having the ability to pressurize environments makes for better RP. I play a lot of Empyrion, and one f the annoying things is that, unless you're on a specific planet with a breathable atmosphere, you're using oxygen from your rebreather and fill tanks. You burn so much so fast.

 

You could argue that there is less oppurtunity for gas loss and server issues with filling voxel environments, and I would agree, but I just feel like oke of the cool aspects of a space sim like this would be lost, ya know?

 

I guess it's a fine line between complexity but also having a game that functions (flash back of SE)

Link to comment
Share on other sites

I certainly agree that breathable environments being a thing in space fairing ships. It almost feels like it should be a must have feature. But then again the technicality behind having it implemented into DU the same way SE did theirs would not work to well. There has to be a simpler way around the problem. 

 

Now in SE oxygen is pumped (or removed) via the use of piping and vents that connects to massive oxygen tanks somewhere in the ship. That's alright and all but i fear that people might not find laying oxygen pipes down throughout their ship a very fun experience. In fact if we want to add pressurized rooms into DU, the exclusion of oxygen pipes will have to happen. It would just lead to calculation trouble and lag the server down if the ships piping were to be partially damaged or destroyed some where.

 

I could go into some detail on how i envision a solution of having pressurized rooms on ships/stations but i'll explain it on a later hour. 

 

EDIT:

Okay i got a possible solution.(correct me if im wrong on this) Alright in SE a room is pressurized by oxygen. This oxygen fills the room like if it was filled with water (invisible blocks). Throw this aspect out entirely along with oxygen piping. All a ship needs to operate with oxygen is a oxygen Tank/generator, this in turn will oxygenate every enclosed room in the ship automatically. With every room on the ship there will be an associated modifier if the room is either enclosed (1) or not (0). (1) being that it is enclosed by walls or door and that there is a working oxygen generator working on the ship. (0) is when the room is not enclosed (via damage or edits). A room marked as (0) is considered a hostile environment and that anyone caught without proper gear would suffer (the obvious). If a single oxygenated room were to be compromised in a event of a battle there wouldn't be any star trek level decompression blowing anyone out the opened hole, the room would simply change modifier to (0). 

Edited by Shōjiki_Haundo
Link to comment
Share on other sites

I would be interested in hearing it, I'm a bit stumped. Though I personally like the engineering aspect of having to figure out oxygen logistics in my ship designs (and I also like the idea of, in battle, being able to target such things like a life support network).

 

I think you have a good point that it would more than likely create too many issues for this game

 

Hmmm...maybe instead we have life support modules? Kinda like the old Star Wars Battlefront space battles?

Link to comment
Share on other sites

The SE One works fine they turned it off in DEV because they were implementing new code that wasn't 'ready' and had huge performance hits

 

 

it was definitely functional and usable on all but the largest builds I've tried, and works just fine in stable 

Link to comment
Share on other sites

I would be interested in hearing it, I'm a bit stumped. Though I personally like the engineering aspect of having to figure out oxygen logistics in my ship designs (and I also like the idea of, in battle, being able to target such things like a life support network).

 

I think you have a good point that it would more than likely create too many issues for this game

 

Hmmm...maybe instead we have life support modules? Kinda like the old Star Wars Battlefront space battles?

If piping would be a viable thing to do in DU i will be all for it. but sadly i dont think it will go through, there's just way to much to account for in battle-like situations. Just to get an image of why just look at the other components that a ship needs. Most of them can be just one offs with no connections required (reference to DU gameplay vid). If piping were to become a thing it would single handedly be the largest component on the ship.

 

But then again im open to other ideas. 

Oh yes the starwars life support modules. The technology behind such a thing always puzzled me when i was a kid with my PS2. And i always kinda hated why the life support module the very thing that controls the well being of the crew of a massive ship would have a critical weak point on its exterior. always pissed me off. 

Link to comment
Share on other sites

Well, when I say emulate it in this case, I mean more a placeable core block or such that we'd have to protect :P. But if guttertrash is right (and I hope they are) then maybe we will have oxygen systems.

Link to comment
Share on other sites

It sounds like the devs are already leaning towards a piping system for energy.  I imagine if the performance hit from piping energy around isn't too much trouble then the performance hit for piping oxygen around shouldn't be too bad either.  The real problem comes from checking a given construct for enclosed volumes.  Any time I run a script in Blender to calculate the volume of a mesh it always takes some time to run.  My case is probably a little more extreme than DU since I can model at any resolution I want in Blender but I also am not trying to run volume checks on thousands of ships at once.

 

The best solution I can think of is to program the game to run a sort of simulation whenever a construct is built, modified or damaged and use that model to pre-define pressurized volumes within the ship.  Each volume is defined in a coordinate system relative to the ship rather than the world.  It would also define which doors connect two pressure volumes and which doors connect a pressurized area to space.  That way you can cycle your airlock without having to re-run the whole simulation, just trigger the relevant volume to pressurize or depressurize.  If you cycle the airlock incorrectly (AKA open both doors at once) then the game can quickly detect that the interior volume has an open door connected to the currently depressurized airlock volume.  Any time the ship is modified or damaged the simulation can check which volumes, if any, the change intersects with and re-run the simulation of just the relevant volumes to check for leaks.  To make sure there isn't too much stress when a ship is getting bombarded or built the game could limit each construct to one pressure check every few seconds.  It might result in some weird delays at times, where half the room is blown open and you get five seconds to stare into space before anything happens to you, but I think this would be worth it if it means getting a pressurization system in the game.

 

Of course I still don't know what it actually takes to identify a fully enclosed volume in a voxel game, particularly if people have to be annoying and build some kind of really weird interior geometry.  The game might need a contingency for edge cases where it either ignores an overly complicated geometry or just gives up and declares a ship unfit for habitation if a pressure check takes too long.

Link to comment
Share on other sites

It sounds like the devs are already leaning towards a piping system for energy.  I imagine if the performance hit from piping energy around isn't too much trouble then the performance hit for piping oxygen around shouldn't be too bad either.  The real problem comes from checking a given construct for enclosed volumes.  Any time I run a script in Blender to calculate the volume of a mesh it always takes some time to run.  My case is probably a little more extreme than DU since I can model at any resolution I want in Blender but I also am not trying to run volume checks on thousands of ships at once.

 

The best solution I can think of is to program the game to run a sort of simulation whenever a construct is built, modified or damaged and use that model to pre-define pressurized volumes within the ship.  Each volume is defined in a coordinate system relative to the ship rather than the world.  It would also define which doors connect two pressure volumes and which doors connect a pressurized area to space.  That way you can cycle your airlock without having to re-run the whole simulation, just trigger the relevant volume to pressurize or depressurize.  If you cycle the airlock incorrectly (AKA open both doors at once) then the game can quickly detect that the interior volume has an open door connected to the currently depressurized airlock volume.  Any time the ship is modified or damaged the simulation can check which volumes, if any, the change intersects with and re-run the simulation of just the relevant volumes to check for leaks.  To make sure there isn't too much stress when a ship is getting bombarded or built the game could limit each construct to one pressure check every few seconds.  It might result in some weird delays at times, where half the room is blown open and you get five seconds to stare into space before anything happens to you, but I think this would be worth it if it means getting a pressurization system in the game.

 

Of course I still don't know what it actually takes to identify a fully enclosed volume in a voxel game, particularly if people have to be annoying and build some kind of really weird interior geometry.  The game might need a contingency for edge cases where it either ignores an overly complicated geometry or just gives up and declares a ship unfit for habitation if a pressure check takes too long.

They use a cellular automata system for water. Perhaps a similar system can be utilised for emulating the presence of oxygen and any "leak" off of a ship. Same deal with water. It "fills" the empty space it is connected until it finds a solid 3D object to stop. The airlocks could e the solid object in question for the simulation of air pressure. 

 

 

On the subject of system strain under pressure during combat and delays, the cellular automata system runs on a pre-defined pattern, and given your ship's gravitational orientation, which your player-character, will already have registered on your end if you are on board a ship, it would not be something of a toll on the client side of things. In any case, engineers should operate in an EVA suit just in case. Occupational hazards and all.

 

 

The same way a push can be applied to the player that forces them towards the area ,the cellular physics of the in-ship atmosphere, "detects" it has to go. I don't know if the devs plan on having such a system, or emulate it via negation of gravitational orientation towards the player if an area is depressurised. 

 

 

The point is, such pressurisation "checks" won't be a simulation, but a pre-defined emulation of such physics (with all the troll science possibilities it can have with it). So, I can see an equation of 5 to 7 factors playing in on how "survivable" a depressurisation emulation could be, with time being key in surviving it. 

 

It's not something insane to have, but at this point, it's just garnish on top of the ship-physics' grid.

Link to comment
Share on other sites

It sounds like the devs are already leaning towards a piping system for energy. I imagine if the performance hit from piping energy around isn't too much trouble then the performance hit for piping oxygen around shouldn't be too bad either. The real problem comes from checking a given construct for enclosed volumes. Any time I run a script in Blender to calculate the volume of a mesh it always takes some time to run. My case is probably a little more extreme than DU since I can model at any resolution I want in Blender but I also am not trying to run volume checks on thousands of ships at once.

 

The best solution I can think of is to program the game to run a sort of simulation whenever a construct is built, modified or damaged and use that model to pre-define pressurized volumes within the ship. Each volume is defined in a coordinate system relative to the ship rather than the world. It would also define which doors connect two pressure volumes and which doors connect a pressurized area to space. That way you can cycle your airlock without having to re-run the whole simulation, just trigger the relevant volume to pressurize or depressurize. If you cycle the airlock incorrectly (AKA open both doors at once) then the game can quickly detect that the interior volume has an open door connected to the currently depressurized airlock volume. Any time the ship is modified or damaged the simulation can check which volumes, if any, the change intersects with and re-run the simulation of just the relevant volumes to check for leaks. To make sure there isn't too much stress when a ship is getting bombarded or built the game could limit each construct to one pressure check every few seconds. It might result in some weird delays at times, where half the room is blown open and you get five seconds to stare into space before anything happens to you, but I think this would be worth it if it means getting a pressurization system in the game.

 

Of course I still don't know what it actually takes to identify a fully enclosed volume in a voxel game, particularly if people have to be annoying and build some kind of really weird interior geometry. The game might need a contingency for edge cases where it either ignores an overly complicated geometry or just gives up and declares a ship unfit for habitation if a pressure check takes too long.

I'm hoping it works this way more so, it's like how they program the player relative to the ship as a grid and not the world, making it possible to move about while underway (very important also, considering the potentially epic length of travel)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...