Large gas reservoirs and filled pipe mapping

[IProduceWidgets]

requires space-wizards/RobustToolbox#5414

About the PR

Also adds large static gas reservoirs which can be de/constructed, but not unanchored and moved.

Probably most impactfully, this PR adds save / load support for PipeNets via the PipeFill component & system.

Why / Balance

Having immovable gas reservoirs allows us to dramatically increase the stored gas on the station. By being immovable they are much harder to grief with than other sources of gas storage.

Similarly, the ability to map pre-filled PipeNets dramatically increases the roundstart gas available to the station for distro (and in a way that scales very seemlessly with station size!), and combined these two changes may allow us to move away from gas miners.

Technical details

Media

Requirements

• I have read and I am following the Pull Request Guidelines. I understand that not doing so may get my pr closed at maintainer’s discretion
• I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

Entities with NodeContainers which have a Pipe node should also have the - type: PipeFill component. It will be added automatically at runtime, but it may cause tests to fail if you have a prototype with a Pipe node that does not have it.

Changelog

🆑

• add: huge gas reservoirs which cannot be moved.
• tweak: distro or other pipenets may now start with gas in them.

[slarticodefast]

You might have to rebalance the grand lottery for this since the frezon canister should be worth around 60k spesos now.

[ImRenQ]

Can't large gas canisters be not a replacement, but just an additional option?

[Ilya246]

some criticisms:

• this is WAY overtuned, they should probably at most ever contain 2500L
• the new prices for the canisters are also way overtuned; also remember that, out of the cost, 1000 spesos are actually for the canister

[slarticodefast]

this is WAY overtuned, they should probably at most ever contain 2500L

For comparison, a single environment tile has a volume of 2500L. It is a little weird for the canister to fit more gas than the tile it standing in. But maybe it's bluespace tech.

[deltanedas]

10m^3 would make sense for a bluespace canister not a random plasteel one

[EthanQix]

Maybe I'm minsunderstanding the mole/volume/pressure mechanics, but couldn't you just increase the default pressure in the air canisters in order to fit more moles in the same volume ? So it would pressurize more tiles with one canister ?

[IProduceWidgets]

Maybe I'm minsunderstanding the mole/volume/pressure mechanics, but couldn't you just increase the default pressure in the air canisters in order to fit more moles in the same volume ? So it would pressurize more tiles with one canister ?

yes, but theres no easy way to pressurize anything over 4.5kkpa. Also they eventually break I think?

[EthanQix]

Maybe I'm minsunderstanding the mole/volume/pressure mechanics, but couldn't you just increase the default pressure in the air canisters in order to fit more moles in the same volume ? So it would pressurize more tiles with one canister ?

yes, but theres no easy way to pressurize anything over 4.5kkpa. Also they eventually break

yeah, my point here is why is there a hardcoded 4.5MPa maximum ? And why that specific, somewhat low number ? Is it an atmos engine limitation ?

[deltanedas]

you can trivially make it 9mpa with a volpump, also there is no breakage mechanic you can have a 10gpa can and its fine

[EthanQix]

you can trivially make it 9mpa with a volpump, also there is no breakage mechanic you can have a 10gpa can and its fine

ah so the air canisters can be set to 10x as many moles with the same volume and there won't be a problem ? ^^

[slarticodefast]

ah so the air canisters can be set to 10x as many moles with the same volume and there won't be a problem ? ^^

That means the pressure in the canister would be 10x as high. With that you could easily overpressurize a room to the point where it damages players. Also with the pump limit being at 9kPa there would be no way to refill them. For the future there is however a softclogging change for pumps planned, giving them an efficiency curve instead of a hard maximum limit.

[EthanQix]

True but now this PR should be as easy as just modifying the default mole value in air canisters instead of modifying every canister volume stat ^^

[github-actions]

RSI Diff Bot; head commit 81e1a54 merging into c6d2919
This PR makes changes to 1 or more RSIs. Here is a summary of all changes:

Resources/Textures/Structures/Piping/Atmospherics/statictank.rsi

State	Old	New	Status
air			Added
green			Added
greyscale			Added
icon			Added
nitrogen			Added
nitrousoxide			Added
oxygen			Added
pipe			Added
plasma			Added
valveOff			Added
valveOn			Added
white			Added

Edit: diff updated after 81e1a54

[IProduceWidgets]

update: I added large gas reservoirs

[Sarahon]

I don't mind this tbh. Air alarms are kinda slow as hell at times and there's a risk when you max out distro just to fix spacing. Allowing us to utilise canisters more would fix this obvious do or die scenario. Giving us a reason to create more reservoirs without having to dismantle and rebuild atmos and more.

A situation you can run into is that spacing isn't fixed fast enough. I usually set distro itself to 500kpa so it still has a lot of gas in the pipes. I rarely set up a reservoir because there's really just not enough space for them (oasis reservoir is an example of how big they'd need to get, and even then it's not that useful in terrible spacing). But if you set the pipe pressure to max, you can space the whole of distro - or overpressure a room if you forget to turn off the fill option(while also leaking distro). It could be fun! Not sure.

Would definitely get me out of the atmos department more.

[Partmedia]

You may be able to find discussion about this before from this old PR: #11242

Why is the GasPipeFill component and system included in this PR? This feels like a different issue that is better split into a separate PR per our pull request guidelines.

[IProduceWidgets]

You may be able to find discussion about this before from this old PR: #11242

Why is the GasPipeFill component and system included in this PR? This feels like a different issue that is better split into a separate PR per our pull request guidelines.

Its soap, but yes, I appear to have buried the lead here on what has become PipeNet save/load support.

[Partmedia]

Its soap, but yes, I appear to have buried the lead here on what has become PipeNet save/load support.

What do you mean that "its soap?" These sound like separate changes to me, and it would be easier to discuss, merge, and back out if something goes awry if these are separate PRs per our pull request guidelines. Thanks in advance.

[IProduceWidgets]

Its soap, but yes, I appear to have buried the lead here on what has become PipeNet save/load support.

What do you mean that "its soap?" These sound like separate changes to me, and it would be easier to discuss, merge, and back out if something goes awry if these are separate PRs per our pull request guidelines. Thanks in advance.

I had to support being able to fill pipes to fill the pipes.

[Partmedia]

I would prefer if the gas canister change and the gas reservoir/filled pipe changes were split into separate PRs. This is better aligned with our pull request guidelines and will make it easier to get through design and code review. If you want to keep them together expect a longer review time. Thanks.

[IProduceWidgets]

Split the canister changes to #31667 since it wasn't much trouble.

I also addressed the cargo lottery stuff on that PR by reducing the odds of the valuable cans. Im going to move all conversation about canisters, except as it pertains to mapping them as a way to (somewhat poorly) fill pipenets to that PR.

Thanks.