Add pipe pressure damage #20931
Add pipe pressure damage #20931
Conversation
|
I have a TEG setup that has a peak pressure of about 1600 kPa that's generating >250 kW to power the whole station, so this pressure limit is actually workable.
|
|
This impl will break the entire pipenet at the same time. Can you make it so the damage is randomly spread out through the pipes so ruptures don't occur everywhere at once? I'm thinking of distro getting overpressurized and needing to replace all of distro. |
|
An additional thing could be making pipes just leak, instead of breaking entirely, when they are partially damaged. That way this doesn't repeatedly split a large pipenet. |
|
Yes, it would be good to avoid a whole-distro explosion. What I could suggest is for me to randomize damage in this PR, and in the separate related PR #20928 make the pipes leak contents to prevent repeated splitting. |
|
i'd say somewhere around 12 MPa for 1-steel pipes, and potentially have 2-steel pipes which are much more resistant |
|
imo a new plasteel pipe should have higher resistance since currently engi has very little use for plasteel |
|
There's no pressure bypass valves or any form of automated pressure management, meaning this will exponentially increase the learning curve for a role that's already the hardest role to learn in the game. I think this is a good idea to implement once there's more tools available to regulate pressure and some form of automation is added. However, currently it's a bad idea to implement and this implementation is very rudimentary. As for what the pressure limit should be: All pipes share the same volume, regardless of shape, which doesn't make sense in reality as a junction should logically have a higher volume than a straight pipe. Current pipe volume: 200 L // 200 000 000 mm3 Now to get the diameter of our pipes:
Now the only question remains, how thick are the pipe walls? This is represented by "schedule" in the specification table. What happens to gas from ruptured pipe(s)? It should blow into environment at place of rupture, proportionate amount to the amount required to lower pipe pressure below damage threshold. What kind of pipes can burst? Can connectors burst? Can pumps burst? If not, you know that players will just replace all pipes with pumps. Can valves/filters/mixers burst? If not, players will just replace all pipes with these. Can injectors/vents burst? Can canisters burst? Can machines such as a thermomachine burst? Why yes and why not? How do you identify a damaged pipe? How do you repair a damaged pipe? Can you reference a design document for atmospherics? |
this role barely needs pressures high enough to cause pipes to burst, this is fine as is and we don't need perfect realism (see also pipenets are a single giant gasmix as currently implemented, gas moves instantly inside of them, so trying to account for stuff like slight volume differences or exact pipe thickness with realistic values is small potatoes) I'm not making the PR author fill out ur questionnaire, sorry. |
|
The threshold probably shouldn't be below 9Mpa to not make vol pumps useless. I think being able to utilize the vol pump's max outlet pressure is a feature, not misuse. And plasteel pipes could be made to withstand higher pressures than that for more specific applications. It sounds good to have rupturing also apply to mixers, filters, pumps, etc. maybe vents too. Randomized damage sounds like a good solution. |
I see, so all the edge cases I listed are not relevant? You realize that as is, this will be completely ignored by clever usage of pipes and devices as I mentioned. but you're free to assume it's a "questionnaire". |
Canisters currently CANNOT explode. |
|
Concerning some of @AJimmyU s concerns:
As far as damage identification, effect and repairs go, that is explained and handled in #20928 . Personal opinion: I'm also pro pressure damage, but would keep it from destroying the pipe and just make it leak. |
Some of these I had concerns about as well. When doing a burn for gas synthesis, how is the gas then handled? Once it's above a certain temp/pressure, the only way we have of affecting these variables is inside of pipes. The gas has to enter a pipe to get cooled, etc. And so, do passive vents take damage or explode? Now we move on to a potential repair scenario: what does a broken pipe look like? Is it easy to find as an atmosian to fix? Stations can have miles of pipes for distro/waste, in the event one of the systems gets overpressurized how does an atmosian find the break? And is there any counter play? Any way to stop a leak or a break from occurring? Or any kind of timer or other signifier(doesn't break instantly, gives some kind of audio/visual cue that it's about to burst) Not opposed to the idea fundamentally I'm just not certain this is an optimal implementation. |
|
Re: Burn chambers |
|
making all pipes volume-leak would probably be a lot better, maybe merge gas tank explosion code but with different constants? |
Partmedia
added
the
S: Awaiting Changes
|
Responding to @AJimmyU :
I think there's some physics misunderstanding here. Pressure is force divided by area, so maximum pressure does not depend on volume (or length of pipe). Only the cross-section matters, as the linked article shows.
Your calculations suggest a 20" diamter pipe. If you look at the "STD" column, which is a reasonable assumption since NanoTrasen is cheap, the maximum allowable pressure per your linked article is 6337 kPa. Which happens to be very close to the number I proposed. So it sounds like you're fine with this number.
Unclear, please leave your thoughts in the related PR: #20928
Only straight, bent, T, and 4-way. We can adjust this as needed.
No.
No. And they won't because they require power and reduce flow rate. Of course we can make pumps burst if you want.
See above.
No.
Yes. See "maxcap".
No. See above.
You can't. You're welcome to PR a pipe analyzer.
Depressurize it, unwrench it, and replace it with a new one.
What do you want to see there? To respond to @Cheackraze : I understand your concerns. At the same time, there shouldn't be no limit whatsoever. I'm planning on updating the breakage to also not break the entire pipenet at the same time. These numbers are also defined in YAML (pipe breakage is disabled by default in code) so are easy to remove. It would help if you could suggest a specific number to increase the limit to. 10 MPa? 100 MPa? 100000000000000 MPa? There have been suggestions for 10-12 MPa. The realism suggestion from above agrees with the 6.5 MPa I PR'd. I'm inclined to up the number to around the 10-12 MPa range and keep bursting behavior. |
|
maxcaps explode tanks not canisters |
|
It would also be trivial to add a sort of "weak pipe" that can burst first, to protect the rest of the pipes like distro. As @daerSeebaer pneumatic valves can already function as over-pressure release valves. If only one pipe bursts (instead of the whole pipenet bursting) I don't think leaking matters.
This would only require YAML changes to add. Maybe we should flip this around and make pumps/filters/etc burst way before pipes do, so that pipenets are protected in a sense? |
|
in a burn chamber passive vents wouldnt burst since its high pressure on inside and outside, probably fine to let them burst also an issue with making pipes under walls immune is that it will be the new meta to just wall/window up everything to handle infinite pressure |
|
That sounds ok tbh, think of it as reinforcing the pipe, except it is very expensive and inconvenient. |
|
@Partmedia i concur, they shouldnt be magically immune, im just concerned about making burn chambers (the intended synthesis method for now) impossible to actually operate, or other unintended knock-on effects. I think that, the combination of 1 pipe section breaking + having that section then leak its contents to 'relieve' the pressure out of both sides would be more optimal. In this fashion, you not only have simply 1 pipe break and not the whole net, but the leaking of pressure means that the pipenets (now 2) themselves have an outlet for the resulting pressure (which may still be too high above the threshold, meaning simply a cascade of pipe failures) |
|
along with that however, the broken pipe sprite should be made much more high contrast and obvious to casual passers by (even non-atmosians should be able to spot a broken pipe IMO) and probably render above the floor tiles after they've broken |
|
I think the algorithm going forward is going to randomly damage all pipes, then preferentially damage already damaged pipes so that in practice damage will get focused on one pipe, and then leaking out the gas after breakage to prevent cascading failures. Alternatively, we might just decide to make pipes basically indestructible but instead make pumps/valves/filters/other things burst at high pressure. |
There's no misunderstanding, the chart takes pipe diameter and schedule, and tells you recommended max pressure. The calculation was to determine SS14 pipe diameter and compare it to the chart.
Again, CANISTERS CANNOT burst or explode or anything of the sort, and will at most leak all contents when destroyed by damage. A handheld TANK can rupture if a burn reaction occurs inside of it or extreme temperatures meet. Maxcap is referring to tanks, not canisters.
More than 1 person deciding the fate of the whole system, such as was the case with radiators where only you got to decide. If there's a document to reference, then there can be consistency and an argument can be made. Any feature people add there's an immediate request for a design document when it's a larger feature, I don't see why atmospherics is an exception for this.
The thing is that if you do not make it burst, then some time later someone will decide that using pumps/valves in such a way is an exploit just like it was decided that stacking scrubbers is an exploit. So I'd prefer thinking ahead about the consequences of a pressure induced burst and how players will certainly try to bypass it. |
|
This will need some discussion as engineering is known for having a lot of volumes in pipes. Allowing pipes to rupture also adds a new way to grief - purposefully popping pipes to grief. |
keronshb
added
the
S: DO NOT MERGE
|
A lot to unpack here:
It was stated: "As for what the pressure limit should be... All pipes share the same volume... which doesn't make sense in reality as a junction should logically have a higher volume than a straight pipe." But volume has nothing to do with the pressure limit.
You're right, I said "canister" when I meant "tank." Sorry. ADDRESSING IT IN ALL CAPS MAKES IT BETTER.
Everyone discussing this here and on Discord are part of the conversation in "deciding the fate of the whole system". Most people agree that there should be a limit somewhere, and the question is where that limit should be.
And that's why we have this discussion process. Thank you for bringing up your concerns. Do you have any suggestions to move forward instead of "you didn't have answers to all my questions so this is bad?"
Every new feature allows opportunities to grief. As we've discussed, there are plans to adjust the algorithm so that only one pipe (instead of the whole pipenet) bursts. There are also discussions to add weak pipes that act like fuses to protect the rest of the pipe net to limit the opportunity for griefing. And at the end of the day, there are many ways to grief, like bomb arrivals, smash windows to space, etc. Why hasn't every possibility for griefing been axed? |
There's no other value besides volume in SS14 pipes. They do not have length or diameter, hence why I used volume to calculate an estimation of diameter to make the chart applicable.
I asked most of those questions because they are important in terms of exploiting the proposed system and show where it needs refining. Knowing that only pipes burst for example, it would be trivial to ignore the game mechanic by utilizing purely gates/valves and passive vents for any junction variant. |
ArtisticRoomba
added
T: Balance Change
|
damn imagine how this would work with the space wind |
|
I wish there was a better way to collaborate on branches -- but if you want to try to implement some of this, give me the URL and branch of a repository to pull from, and I'll collect changes here. |
|
is this still breaking all pipes in the network? if so, laughs maniacally Distro pipes gonna be wishing I hadn't been gifted chamberless burn. |
|
Pipes that burst will release more pressure than normal, so the idea is that when a pipe bursts, the pressure in a system will significantly lower below the point of bursting in order to prevent a station-wide failure of a pipe network. I'm sure that you can mess up the station really good if you think (or don't think) hard enough, so... This will also prevent cheesy solutions to gas storage and flow rate to distro problems. Atmospherics will have to come up with intuitive solutions that maximize flow rate while preventing overpressure (the intuitive solutions being like, two things, but hey, it's cool). |
|
Aye, I wasn't actually under the impression the whole system would burst, was merely cracking a joke at the video. I do absolutely look forward to this. I think it'd be neat too if pipes that break (or don't have something on the end of them) release gas into the environment acting like a passive vent. Thatd probably go against gameplay design or something or other though. |
|
With the current state of the code in this PR, the net tends to still entirely disintegrate (even if not all at once). This is quite the experience, as bursting pipes have a sound associated with them and there are a lot of pipes on a station. I'm not yet entirely sure whether we should go with leaking some extra pressure on each break, or leaking continuously from a broken pipe. The latter approach feels a bit more organic and more robust as far as unintended gameplay consequences go. One scenario I imagine is having a source of high pressure connected to a length of pipe The pipe breaks somewhere in the middle and leaks enough pressure to stop the cascade This however doesn't stop the source from pressurizing the pipe, so it overpressures in a different cascade: I don't think this is necessarily the way we want it to happen. In that vein I started exploring broken pipes to continuously vent some pressure. For this to work well we need to 1. have proper broken pipes, which connect to the rest of the network and 2. leak gas out of them. Both of those can exist in the game without pressure damage and will have their own gameplay consequences, so I think they can be developed in separate PRs. In particular I drafted a somewhat working prototype of no. 1 in #35028 . Those changes don't introduce wildly novel behaviors so I don't expect them to be prohibitively hard to implement, but given that I have limited time to devote to this (I expect this to be a weekend thing) and I'm not too experienced with the codebase, this might take some time. Any help or feedback is appreciated as always. |
Ah, that is a good catch, and would lead to the extra broken pipes as you describe. I agree that having open pipes leak is the more sensible approach. But this represents a pretty big change in how pipes work, which will likely hurt some feelings and take some fighting to get through :) |
|
Gonna require a bit more thought than my pee brain is capable of putting out. I really wanna see it happen, but having distro leak out through a broken pipe in a post gas miner world is potentially shift ending. No amount of recycling is gonna help you there. And having a pipe device to seal a breach when it happens just brings us back to square one with bursting pipes. |
I don't see how a distro leak to atmosphere would be round-ending. In Flowmos the overpressure would actually be automatically handled by the pressure bound on the air scrubbers quite well. The gas would simply go in a loop from distro, to exposed atmosphere, to waste, to gas tank, to distro, until atmos fixes it. |
A bomb takes out say the HoP line, punches a hole through the subfloor and breaks a few pipes in distro net. If we're assuming broken pipes, and not just burst pipes are leaking air, we'd be dumping large amounts of the reserves into space. |
|
Also off topic, but is there any progress to flowmos? That'd be a nice to have too. Having air recirc just kinda makes sense. |
The Flowmos PR works very well from my testing, it just needs review. See #33380. One issue that was raised was the potential of bad performance, however in my testing I observed no meaningful performance dip at all (I could have easily been reading dotTrace wrong, so be careful). The primary blocking change is the design document being re-evaluated and merged, as well as me personally mapping air mixing chambers and setting up distro and waste for Flowmos on all maps, which is a long, long process. On some maps I would also have to remap vents and scrubbers in a specific way for Flowmos. So it's a lot of work for me. If these aren't mapped, Flowmos has the potential to do more harm than good, so a balance has to be made. |
Yeah that would do it. Can't really think of anything but to make sure that atmos fixes stuff quite fast. In terms of Flowmos, if it's not in the ddoc already, gas miners won't be completely removed, rather their output will be significantly tuned or the cost of running them will be at great expense to the station, and it can be in multiple different ways. For example mined gas can come out too hot for general station life, so it'll have to be temperature-controlled before it enters the main air recirculation loop. |
One idea thats been floated previously is to split the distro network into subnetworks, much like how power is handled. That way if a section of pipe is blown up, only that part of the network is effected. Atmos just needs to turn the shut off valve for the reservoir feeding it until repairs are complete. Would require a lot of mapping work though |
Could also add rate or pressure-limited gates around the distro network, or signal valves with pipe sensors. I do wonder if we should add 'plasteel pipes' or something to allow for high pressures or something. Also pipes should 'jitter' when pressure starts getting too high imo. |
That is an issue, yes. I have to admit I wasn't entirely aware of the push to deprecate miners and engaging with such a potential design instead of the current state of the game would be more challenging. Just to make sure we're on the same page, we're discussing a system, where it would be recoverable to vent the amount of gas that gets spaced under a normal HoP bombing scenario, but not recoverable to keep venting the contents of distro net until the holes get plugged. Without more testing I'm not yet sure how much do these scenarios differ. Let's also assume the crew employs the following counterplay:
Under such a scenario the atmos system seems quite fragile in general. It feels like all it would take to suffocate the crew (or make them use internals) is for someone to break a window to space in a secluded room and connect a passive vent to the distro in said room, which is a method of sabotage that doesn't employ broken pipes at all (as those are quite similar in nature to passive vents). My hope is, that whichever way the miner proposal addresses the issue would apply to leaky pipes as well. That being said, implementing broken pipes as passive vents is not the only way to implement leaky pipes. One solution would be for broken pipes to still be able to hold some pressure, and only make them leak pressure above a certain threshold. Natural choice for this threshold would be the overpressure limit, but it could also scale between some two endpoints with damage to the broken pipe or something similar. The difference between a broken and damaged pipe becomes a bit ambiguous at that point, which feels reasonable.
This was my knee-jerk reaction as well. I don't think that pneumatic valves are quite ergonomic enough to be used for this purpose right now, but some kind of an overpressure valve between, say, departments would probably be an effective and adjustable way to counter general gas leakage (including passive vent sabotage) as soon as the distro pump gets turned off. Such an item would however have a nontrivial effect on both the game in its current state as well as this PR. |
Do note that as discussed previously I'm planning on amending my push to remove gas miners, instead gas miners might draw a lot of power and produce hot gas that needs to be temperature-controlled. But the pipe bursting mechanic should be designed in mind to the removal of gas miners just to make atmos' life easier.
It is! Atmospherics has a lot of tools to intervene with sabotage, but when it comes to preventative measures, there's not really much in the book. I wish that people who weren't wearing magboots would be thrown against a wall and break all of their bones if they tried to unwrench a 1 MPa pipe, but we don't have that behavior right now. Right now the current dynamic is just "pray that Atmos sees it on the network monitor or alerts computer and knows how to fix it".
I agree with this form of pipe leaking... it's much better than potentially leaking everything to space. Rather atmos will only leak gasses above something like 101.325 kPa or maybe 300 kPa.
I'd really like it if Atmos could do remote damage control. This is turbo bikeshedding, but:
The work behind this solution would be enormous though. |
|
Another idea would be to introduce deliberately weak pipes (call them 'breakpoint pipes' or whatever) with a pre-installed pipe sensor, which will rupture and leak at lower pressure before other pipes rupture first. This would introduce damage control and warn atmos techs that the network is starting to buckle. |
|
A pressure relief valve (seperate from the pneumatic) needs to be made in order to enable emergency venting of the distro and wastenet to space, just as a common thing. Gives antags another thing they have to sabotage before they can start prodding at atmos sabotage. I know you can do this with a gas pipe sensor and signal valve... however it would be nice as a purely mechanical device. |
what about a pipe device that you set a pressure on. and it opens when pressure exceeds its set limit. We could use this to feed overpressure back into the recycler net. |
I realize now that I literally just regurgitated what you said. |
That exists in ss13, dunno if we ported it here. Last time I checked we were still missing a handful of atmos devices from 13. |
|
After some more testing I realized that update order induced pressure spikes happen way too often even on accident and would probably cause pipes to burst inexplicably. I attempted a fix in #35211 . |
About the PR
This adds pipe pressure damage, which damages pipes when the internal pressure exceeds some threshold. In other words, pipes now explode from pressure.
Why / Balance
It doesn't make sense that pipes can hold an infinite amount of pressure without bursting, especially because canisters can explode. Most people agree that pipes should have an upper limit, so the rest of this is dedicated to discussing what that limit should actually be.
The pressure chosen in this PR is intended to demonstrate this code (see screenshots below), and not as the final number. For the final number, we turn to the community for feedback. Please contribute to the discussion by commenting below.
The number chosen in this PR is 1.5 ×
Atmospherics.MaxOutputPressure. This means that pressure pumps can never cause a pipe to burst, but misusing a volume pump will. This adds risk to using the volume pump. I didn't think to hard about this number since we're leaving this number to be determined by the community.Technical details
Adds a pressure check to all pipe nodes in a
PipeNetafter eachPipeNetUpdate(). Deal damage that scales exponentially with pressure.Media
out-2023-10-11_15.20.01.mp4
Changelog
🆑 notafet