Hello Survivors and Devs The current way oxygen distribution works is... unsatisfying... Imagine you're building a base or a CV and since you don't plan on it being a combat vessel you try to maximize the space inside. So you use those nifty walls that make up only 1/8 or so of a block giving you the ability to place a usable block like a container controller right next to the Block with the wall and still be able to walk next to it and use it. This is all fine and dandy on a world, that has a breathable atmosphere. But in Space or on a planet without breathable atmosphere this means whenever you stand there to use the funcional block, you'll be without oxygen supply and the O2 tank of your armor will slowly drain. This is because different than collision, O2 does not take the shape of the block into account, but only one flag: airtight. If you place a Block, that's defined as airtight, the shape is irrelevant. You can even place a wall with one orientation next to one with another orientation. You can see and walk through the gaps, but they will hold the oxygen without a forcefield because they share the airtight-flag. You can easily see this when pressing N, switch to "debug" and then activating "Show Airtight Blocks" To demonstrate what I mean exactly I'll upload a screenshot of both a situation where there should be oxigen but isn't and one where there is oxygen but shouldn't due to the huge gap in the Wall. I know this will probably be a massive effort, but I think, if something is airtight or not, should be correlated to it's collision. With the exeption of everything that has a forcefield (including Forcefield emitters of cause). I'd appreciate if you'd consider reworking this mechanic. Cheers!
I have more issues with locations that should have oxygen and don’t, like your cargo box, though where I seem to notice it most is around sloped windows. Now I don’t know about you, but I tend to like to construct actual ventilation systems when I build bases, to minimize the number of ventilator blocks I have to use, and yes, I figured out a while ago that partial blocks are still Air Tight, so my ventilation systems all have to be 1x1x1 empty spaces. Not a complete deal-breaker, but it would be great if either: Air could pass through empty spaces, or... We could have non-air-tight versions of partial blocks for the sake of such systems.
I run into these issues so much Drives me batty getting air through tight areas that a player can easily walk through. The o2 system is so basic... its ... painful.
For performance sake it probably needs to be, but I suspect it could take a bit of tweaking to make it a bit more robust without frame rate death.
Oxygen is really hard to get "right" and still be performance friendly. Even SE has it turned off by default for performance reasons.
I think IndigoWyrds Idea with a second set of blocks, thats not Airtight sounds great on first glance, but wouldn't really help in most cases. If I take my screenshot next to that Container Controller, and replaced that wall with a non-airtight version, the room wouldn't be isolated anymore and would lose it's oxygen alltogether. So while that might help in some cases, I fear in most it wouldn't.
They don't need a separate set of blocks. They can do something very specific to flat walls, as follows: IF: The block is a straight thin wall (with 5 open sides), OR... The block is a 2 way corner thin wall (with 4 open sides), OR... The block is a 3 way corner thin wall (with 3 open sides) AND: at least one of the 5/4/3 open sides is adjacent to an oxygenated block THEN: The wall block shall be considered oxygenated Any blocks adjacent to any of the other 5/4/3 open sides also becomes oxygenated Oxygen is not transmitted through any of the 1/2/3 closed sides This change would not require any sort of advanced collision detection, and should be quick to calculate in real time. Same concept would work for half blocks. It should also mostly work for curved thin walls, making the inside of pipes breathable. It would not fix every block perfectly but I suspect it would fix a lot of designs because corridors that are using thin walls would now be able to transmit oxygen through them. They don't need to make it perfect for every strange block shape, but just fixing the 3 straight wall blocks I identified above would make a huge difference. And that should be able to be done without a major performance impact.
What about allowing an option for a block to change the flag on that specific device to be non-airtight? It could be a check box in the control panel. That seems to be a very easy fix.
Specifically, the issue is that there's no concept of directionality to O2 flow through a block, only whether the block is airtight or not. What each block needs is a set of 6 flags to indicate whether oxygen can flow through that side of the block. This would add two additional checks each time a block is checked for O2: whether O2 can flow out of the previous adjacent block, and whether it can flow into the block under consideration. Actually, maybe it'd end up being just one additional check, as the airtightness check would be replaced. The orientation of blocks would matter, though, which would require some additional calculations. Personally, I'd say that improved oxygen handling would be worth an increase in the time that it'd take to compute the oxygenation of a structure.
To do it right is actually not that simple, which is why I suggested a stupid fix for only straight walls. I believe if you fix straight walls, which should be quick and easy, it takes care of ~90% of the problems people have. Then they can spend time doing more important things. It is not really just 6 flags to say whether a particular side can allow oxygen to pass through it. Using a boolean flag approach, you need each combination of "can oxygen flow between side A and side B" of each block. You should see why as soon as you consider a 45 degree angle wall, that is positioned vertically. Oxygen can pass from a side to one of the adjacent sides, but not the opposite side. But that only answers the question, can oxygen get from one side of the block, to another side of that block. But you must also consider whether block M and block N, when positioned in a certain orientation relative to one another, can pass oxygen through that side. For example, oxygen can flow through a half block that is used as a "floor". And oxygen can flow through a half block that is used as a "ceiling". But if you placed those adjacently, there is no airspace between those two blocks. That could be runtime calculated if you have monochrome bitmaps corresponding to the solid faces of block M and N, OR them together, and see if there's any holes. That has to be slow so I think they need to generate a huge offline table with all the combinations precalculated. If they have like 200 block shapes, each of which can be in 24 (!) orientations, and each one can be adjacent to any other one, it is like a million combinations. Which isn't a lot of memory if they precalculate the table. But it suggests "there must be another way to do it". I would wonder if using the "navmesh" type stuff that is used for AI pathfinding would be smarter instead. Basically, generate an invisible "bug" and have it try to find its way outside. If it can't, this place is airtight. Now, try to find the way to the ventilator. If it can, this place has O2. Something like that. There may be better ways to do it, I haven't researched it. Seems like a problem someone must have solved before in an efficient way.
True, I'd forgotten about the angled thin blocks. Well, there may not be anything faster than using a huge lookup table. It might not feel that elegant, but it seems like Empyrion has memory to burn rather than compute time, so it might be the right choice. A possible optimization could be to build a customized table for each structure, though I'm not sure if that would end up saving any memory on a crowded playfield with a diverse set of block shapes in use. I feel like this could end up being quite slow with complicated geometry, as you'd be doing actual collision tests.
Close but not quite. Instead of using boolean flags, use 32 bit Ints. A fully air tight face would have a value of FFFFFFFF). When checking to see if air can pass through a block, the game tests each face of the block and if a face is not air tight, then it compares the adjacent blocks face value with the current face value using a bitwise OR. If the result is FFFFFFFF then air does not pass through, otherwise oxygenate the block and continue. This would be almost as fast as using bool flags but account for any combination of shapes butting up against each other. If 32 bits isn't enough to account for all the block footprints then this code could be easily adapted to use 64 bit ints instead.
However simple the change to a "six sides of a cube" is and the shortcomings it may have... it is still LEAPS beyond the 'is cube airtight' check we have right now. Also, doing a simple six-sides check wouldn't be a monumental amount of time and coding to achieve. As per the mention about how SE does it and why they turned it off... its because they went overboard with it and actually made O2 a "liquid" using the physics engine to flow through a structure like water, and if it leaked out... it leaked out. It was overboard. Ridiculously so. So using it as an example for ANY game is never a good idea.
I do have to wonder though... could a little reworking of the oxygen systems perhaps give us a means to be able to build underwater, if “contained oxygen” displaces water? That is, if a structure is air tight, could that air tightness be used as a qualifier to remove water when oxygen is present? If so, this would be great for allowing the construction of sub aquatic domiciles. At least 1/10 the work of “fill with dirt and remove.”
I think the way water works in Empyrion, that won't be doable. At least not ealily... It would be cool, tho.
Actually his suggestion would basically work - but it does have problems. The problems aren't with the water though, they're with the O2 system. It is simple enough to say, if you are in an oxygenated area, don't show water there. The implementation of water in a 3D game is done by two components: When you're outside the water, you need to see the water boundary. This is a visual mesh, which might be reflective, and might even be dynamic with waves and all that. When you're inside the water, you need to feel "underwater". They do this with a visual effect (stuff looks blue, light is reduced, some distortion) and also with an audio effect (changing the equalization of the sounds, adding a bubbling background noise). They also change the movement (you "swim" and can't use certain items). Simply turning off #2 when in an oxygenated area will immediately make you feel "not underwater". No problem. But you can't get an accurate boundary with the current O2 system. Take a curved wall corner. Assuming it is curved outward, you want the inside part to have O2, and the outside part to not have O2. If you treat the whole cube as not having O2, then if you step into that corner, you're suddenly underwater. If you treat the whole cube as having O2, then there would be a mysterious air pocket outside. To fix this, they need an accurate 3D mesh of the area that is underwater vs. not underwater - which means the oxygen system just has to be more accurate than it is now, it can't just be binary, "this block has oxygen, this one does not". Now, the water system also poses its own issues, but that's more about when you dig, the water does not flow into the newly cut out area. I think they could improve that by making any lakes and oceans actually penetrate the land horizontally for a margin around the lake, and also downward (indefinitely). Then if you dig next to a lake, there's water down there. It wouldn't necessarily allow you to dig infinitely long canals or anything but it would make building next to water more realistic at least.
I was so liking this idea! Then ya had to go and bust my bubble I was all ready to build my fully irrigated mega farm Really without a whole rework of how water works in here, might be some time before we see improvements. I know we have one person waiting to make real floating ships and boats. Which I too would love to see his designs work right on water. We could then, really have that underwater base we all want! ok well some of us.
Actually, making underwater (or partially underwater) bases isn't that hard if you move forward with the idea that oxygenating a structure clears the water out of it, and water is treated like the vacuum of space, in that a "leak" to the outside will de-oxygenate the structure. Digging canals is harder but doable, you'd need to effectively have a "water table" in an area, where if you dig down to that level there's water. They can simplify things a bit by making it so lakes and oceans are basically all at the same elevation (I think they already do this, there aren't mountain lakes). That's your water table. If you dig below that, anywhere, you get water. This is a bit simplistic because it lets you build new lakes in the desert, and stuff like that. I would not bother to allow making manmade canals, but they really need to do something about small-scale building at the waterfront. If I place a block and pick it up later there's now a cube of air in the water - there's odd stuff like that. Boats - that's tough. Would be fun but maybe not worth the effort the physics would require for a game like Empyrion. I'd like roads and train tracks too... but there's way more important stuff to do.
