-
Notifications
You must be signed in to change notification settings - Fork 542
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bluespace pipe caps #36581
Bluespace pipe caps #36581
Conversation
Might be worth making it capacitor upgrade in the dispenser instead of manips since those are available round start from engi plasma doesnt seem as much as work as slimes. Engineering also is the department with the most value with capacitors so it kind of fits the theme. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditch the color-specific subtypes and implement a way to change the color (maybe a multitool menu) instead of having to have multiple entries in the RPD. Also, please make pipe crawlers teleport between these (or at least have some fun interaction like it sending them to a random length of pipe).
/obj/machinery/atmospherics/unary/cap/bluespace/blue | ||
color=PIPE_COLOR_BLUE | ||
|
||
/obj/machinery/atmospherics/unary/cap/bluespace/cyan | ||
color=PIPE_COLOR_CYAN | ||
|
||
/obj/machinery/atmospherics/unary/cap/bluespace/green | ||
color=PIPE_COLOR_GREEN | ||
|
||
/obj/machinery/atmospherics/unary/cap/bluespace/pink | ||
color="#ff66cc" | ||
|
||
/obj/machinery/atmospherics/unary/cap/bluespace/purple | ||
color=PIPE_COLOR_PURPLE | ||
|
||
/obj/machinery/atmospherics/unary/cap/bluespace/red | ||
color=PIPE_COLOR_RED | ||
|
||
/obj/machinery/atmospherics/unary/cap/bluespace/orange | ||
color=PIPE_COLOR_ORANGE |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's much more preferable to just limit it to /obj/machinery/atmospherics/unary/cap/bluespace and have a default color new caps will use unless they're changed. I don't see any benefit in making these unique items since you already distinguish between them via the color var.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, each one connects to same-color caps, right? Seems useful to use a subtype for that instead of checking the color var, because color can be changed by other happenings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, the code currently checks for the color
var. I think that's a bad idea that might lead to jank if, say, Colorful Reagent shows up, or a wizard uses Color Change, or if something else happens like an admin
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Best approach would be to just have an ID var and match that. You could generate a color procedurally based on the ID if you wanted to provide visual feedback.
while the codersprites are SOVL, it doesn't really feel bluespacey, can you add the blinking blue lights from bluespace beakers or stasis beakers? |
for(var/obj/machinery/atmospherics/unary/cap/bluespace/bscap in bspipe_list) | ||
if(!main_network && bscap.network && (src.color == bscap.color)) | ||
main_network = bscap.network | ||
continue | ||
if(main_network && bscap.network && (src.color == bscap.color)) | ||
main_network.merge(bscap.network) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for(var/obj/machinery/atmospherics/unary/cap/bluespace/bscap in bspipe_list) | |
if(!main_network && bscap.network && (src.color == bscap.color)) | |
main_network = bscap.network | |
continue | |
if(main_network && bscap.network && (src.color == bscap.color)) | |
main_network.merge(bscap.network) | |
for(var/obj/machinery/atmospherics/unary/cap/bluespace/bscap in bspipe_list) | |
if(bscap.network && (src.color == bscap.color)) | |
if(!main_network) | |
main_network = bscap.network | |
continue | |
else | |
main_network.merge(bscap.network) |
I'd like blithering's, it looks fancy as hell and does properly give the vibe of gases being teleported and shit. |
I don't think something like this that removes all the logicistic requirements of atmos is healthy for the game unless it's locked behind something rare like having to put a flawless bluespace crystal into your RPD to use them. Things that completely trivialize mundane tasks should be a nice once in a blue moon sort of thing, rather than something you can reliably get most rounds. |
Should also say, this will be powergamed extremely hard if easy to acquire. You could put a bluespace pipe in any gas miner room and now you have a quick gas flood method that fits in your bag |
While I share the sentiment, gating it TOO hard also makes it yet another neverfeature, natural bluespace crystals would be better in my opinion. Rare enough that it doesn't really happen that often, but not rare enough that it only gets used once a month, if lucky. |
Then it shouldn't be added. This is one of those things that is so incredibly unbalanced and powerful that it either should be locked behind a once a month special thing or not added at all in my opinion. |
I don't like it |
Strong enough that it should be locked behind tier 4 parts and only from the machine, rather than the rpd. It's cool though, and I like blithering's sprites from the bunch |
An idea we had was that, to counter unstoppable floods with this thing, the atmos console should point to the exact coordinates of each bluespace pipe. So while you CAN use it to flood, it is also pinpointing exactly where your flood comes from. |
if the CAC map worked properly I would be more on board with this particular idea. This is just a ridiculously powerful item and even with that I feel like the balance is completely off |
I still remain of the opinion that it should either be locked behind something very rare or not exist. Even if you make it easy to locate, an instant plasmaflood with minimal pipes is incredibly broken inherently. Not to mention all of the other things it trivializes for non-antag atmos techs. |
true |
This is absurdly powerful for antagging. Hide a plasma miner on another z-level, use the caps to hook into distro in a bunch of hidden places... then good luck stopping the plasma. This really will need restrictions, though the qol would be nice. I'm surprised I didn't realize the potential of how bad this would be while you talked about coding it before. Ideas:
Even if you get the thumbs down, this is a cool idea. As-is though, I really doubt we should merge it without some more gate keeping, unless you really like to have unstoppable plasma flooding. |
i like tge original sprite |
The only idea I can think of that would make this not (as) abuseable is to only let the gas jump a 1 tile gap and angle the intended use to allowing atmos techs to not have to deconstruct walls while piping through them. I'm also not really a fan of any ideas to balance it being in the realm of "make it require a lot of power" or "let people locate it on a computer" because at the end of the day, people are still gonna walk into a populated room and instantly plasmaflood with something they had in their backpack. |
you don't have to deconstruct a wall to pipe through it, just click the wall with the RPD |
You can already pipe through walls, just stand next to it and use the RPD on it. |
Oh, well then yeah just don't add this in any capacity. That's the only thing I could think of to make it seem balanced |
Planned nerfs:
|
yeah, 100% disallow multi-z shit, that's MUSTARD GAS in many levels |
for all the screaming you're doing about how this can do UNSTOPPABLE FLOODS!!!! concerns about multiZ are also a bit overblown desu, just have to be careful about the derelict crabs |
West sprite is misaligned |
this isn't needed it will just make our atmos techs even more lazy with no desire to put actually effort into their piping |
Rambling here read ahead if you dare. I'm seeing a lot of knee-jerk responses to this item which matched what my initial response was but I think there's a lot of reasons that these thoughts when examined a little further aren't as accurate as they seem. To start with addressing the idea of the "unstoppable" flood. Unstobbable is to atmos as possible is to asmiov ai, which is to say totally irrelevant the only measure a flood should be compared by is how recoverable it is because this determines if you have to leave the station. On that note it's worth mentioning here that you can flood the entire station to an unrecoverable state within the first five minutes of the round using nothing but four straight pipes (which also fit in your backpack for whatever that's worth) and an AAC. This uses the entire output of the miner faster than it can produce plasma and these pipecaps would add zero different functionality to this. So now we know it's not any more dangerous than the default state of atmos we can look at how powerful it is or more accurately "will it make our atmos techs lazy?". Honestly as far as I can tell, no? The most powerful tool for refilling a station is already the stations default distro because it reaches everywhere, this doesn't give you any more access to that so all it would allow you to do is refill specific areas of the station from a network not connected to it's current distro. Which we already have a tool for: The Portable Air Pump. There's a reason these are outside engi for the public they are by far the most effective tool to refill a specific room or area of the station an overpressure air pump will always be the fastest way to refill a room even with these implemented. The only situation I can even concieve of that would functionally make use of this would be instead of overpressuing that pump you instead overpressure a pipe into a pipe cap so you can make an incredibly ugly 5 layered vent into pipe cap setup in any station room to refill it which again would still be slightly slower and prone to releasing more air than you want because vents are stupid making the only benefit not dragging the air pump behind you for all of 5 seconds to get to the room you want to refill. Realistically the only reason I could see anyone using this is to pressure an area that they don't want to keep moving back and forth between or to set up a burn chamber in the bar or something equally stupid without having to pipe over the whole station and I see nothing wrong with that. Yes it could end rounds but it's worse than the current way to use the exact same medium (gas) anyway so what should it matter? Should we gatekeep round ending to people autistic enough to keep a vent script or learn how to use the CaC? The same person could just blow up a shard or release a sing and be done with it anyway, all that matters is that this adds enough interesting to the game that people can do things with it to justify that it might occasionally be used to end the game too and I think it does that. For what its worth I also thing its original implemetation barring pico manipulators was fine people really overrestimate how often cross department interaction happens because it seems really easy to say on paper but even with a consistent xenobio player on recently I can count on one hand the amount of times people have asked for slime cores. And it's not as though a mechanic is going to upgrade the dispenser by default anyway so why make someone jump through hoops because there's a "possible" threat of someone maybe ending a round because they feel like it. |
#36581 (comment) |
Initial implementation is done and ready for review |
6b4f49f
to
e2d47ec
Compare
|
||
/obj/machinery/atmospherics/unary/cap/bluespace | ||
name = "bluespace pipe endcap" | ||
desc = "A bluespace endcap for pipes." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This description doesn't say a lot for the function of the device, especially since it's not really obvious at first glance.
much more on board with it after the proposed changes pico manipulators is easily obtainable, but raising this to femto manipulators might be a huge ask though it could make for much better interdepartmental interaction |
My current stance after sitting on it without looking at things for like 24h is that I've been successfully negotiated down. With the suite of nerfs, it'll start off in a better spot (vs powercreeped super easy to get). It's an interesting tool for engineers to work with in order to make bizarre things. In the worst case and it actually does get used for the worst case antaggery, we can further nerf it/admin only it. "But muh power creep once it's loose it won't be able to get put back in the box" yes it can if it's that bad. I see the raw power in the flooding this can do and not be stopped with, but I'm gonna point out: current state of the game you can make some really nasty floods that can't be cleaned out so easily. This just makes the worst floods even harder to remove. But that doesn't exactly matter when most players can't stop an automated valve and script AI flood. I'm still concerned over the potential, but it's whatever. Let the engineer get some new toys for once. Votes are currently roughly even as of this post. 9-8 with bonus confusions. We do not follow emojicracy anymore but the caring audience is mixed - It's worth a try. Unless things change between now and when code review is complete, this looks mergable. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only minor nits, looks pretty good - thanks for all the effort in addressing feedback. Worth merging and if it's being abused consistently we can revert it after a month or so. People will inevitably abuse it for a week or so, so don't fret when that happens.
if(istype(O,/obj/item/device/multitool)) | ||
var/list/choice_list = pipe_colors | ||
|
||
var/choice = input(user,"Select a colour to set [src] to.","[src]") in choice_list |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
colour
color (not just nitpicking, it's for consistency)
@@ -202,11 +205,18 @@ var/list/bent_dirs = list(NORTH|SOUTH, WEST|EAST) | |||
else | |||
src.pipe_type = pipe_type | |||
src.dir = dir | |||
if(src.pipe_type == PIPE_BSCAP) | |||
src.w_class = W_CLASS_LARGE | |||
bspipe_item_list.Add(src) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably unnecessary since you already add it in New()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there are 2 lists: bspipe_list and bspipe_item_list, one tracks the caps in item form and the other in machinery form
What this does
Adds bluespace pipe caps which all share the same network so you can teleport gasses between them.
The pipes can be made in a pipe dispenser by upgrading its two manipulators to at least pico-manipulators (probably too low a requirement but it can be easily changed later).
There is a max of 20 bluespace caps per world.
You can recolor the caps with a multitool so you can have different bluespace networks defined by color.
bspipes.mp4
2024-05-25.14-09-17.mp4
Why it's good
Allows you to build large interconnected systems without having to build every single pipe.
TODO
Changelog
🆑