Due to the "cool-factor" of building in space and the bonus solar power daylight time, building a base in a space station dimension is a good option. Solar power is expensive but essentially the lowest TPS (ticks per second) option for late game power-gen in GTNH. Transporting the energy through an AE singularity however leads to a net loss over just using solar panels on earth.

At the moment, there are only two options for sealing oxygen in a space station: GC oxygen bubble distributor and GC oxygen sealer. The oxygen bubble distributor only has a radius of about 8 blocks which is not really usable for a base. Let me talk about some of the problems using the oxygen sealer:

• GC's Bounding polytope algorithm is high computational complexity and needs to run on many chunks, getting called frequently on block updates.
• They only support about 1000 blocks each, which if using most of the vertical height available in the space station dimension is sort of unrealistic to do on a large scale.
• All connecting cables to the oxygen sealers need to be chunkloaded, which means an enormous amount of oxygen collectors and oxygen providing blocks.

So I was thinking maybe we could have a GT++ multiblock that functioned similarly to the oxygen bubble distributor except there is no hard limit on bubble size, so we can have a very large (eg. 2000 block radius) bubble that does not need to check for a bounding polytope / bounding volume and also only requires only one chunk to be loaded. Its parts could be something like this:

• Anti-vacuum controller
• Fluid hatch for liquid O2 from GT or compressed O2 from GC, maybe also normal oxygen cells with reduced efficiency. Consumption determined by bubble size.
• Configuration bus or something that lets you specify a sphere size in a wide range of numbers
• Muffler hatches used to emit the oxygen bubble - possibly have the bubble size limited by the number of mufflers used
• Energy hatches, with consumption determined by bubble size (truncated by world height limits), needs to scale to large numbers so they are realistically achievable given the number of hatches used.

Misc Info

•    Using GT:NH/GT:New Horizons?
•    Single Player?
•    Multi Player?

I doubt I can do anything better, the overhead from being in a dimension without oxygen isn't worth the cool aesthetics space bases give. As every block of 'space void' is a ticking tile iirc.

GC code as a whole is trash and I'm generally not fond of supporting it at all.

I've had a look at the GC code regarding oxygen, starting from where the player takes oxygen damage. Here's a manual stack trace:

test for OxygenUtil.isAABBInBreathableAirBlock
test for OxygenUtil.isInOxygenBlock
test for OxygenUtil.testContactWithBreathableAir
test for GCBlocks.breatheableAir
assigned to breatheableAirID in makeSealGood in ThreadFindSeal.java

It looks to me like makeSealGood and makeSealBad is where ScheduledBlockChange is getting called for all TileEntityOxygen. It should be easy to add a conditional overload for those functions that stops scheduling the block changes, but even then they will still get a lot of updates so that would take a lot of work to fix.

So, something else I would say to look at is what the oxygen distributor does, which only needs a radius. It also looks to me like tileEntityOxygenDistributor is one tileEntityOxygen that covers the area of multiple blocks, so it would only need to update once for the entire area. Using a new version of tileEntityOxygenDistributor should work.