Miraviel

>they have no farm plots but got seeds Those two ruins have almost as many farming plots as starting seeds, I thought this fix removed some spawners' ability to farm. My idea still stands, they could use compost piles as a non-electrical alternative for the biogenerator (it could just take some time to turn it into useful soil instead of being semi-instant via the biogenerator).

Add a compost pile? The fact you can just whip sandstone out of nowhere (and turn it into farmable plots) is already weird, imo. Which ghost roles are in need of craftable farm plots (aka they have no farm plots but got seeds) but lack a biogenerator?

I could suggest adding a "soil" object with which you could make new soil plots, printable via the biogenerator (it'd be weird to be able to print "sandstone" per se). At least at home it's how we refill our plots - with recycled plants.

Personally, as command, I just fully ignore bridge hobos, they annoy me endlessly. I want to see people walking up and down the hallway but I sometimes just use the shutters so I don't have to see minibar #39851 being built in the middle of a main corridor. As for the phenomenon itself, I think we have bridge hobos because a lot of people love to see the security vs antagonists gameplay in person (and sometimes try to get involved as well, breaching our validhunting rule), and the best places to experience that are 1) the Bridge that is always a hotspot for both RP drama and mechanical conflict and 2) medbay. I think a solution for bridge hobos would be making the bar/other recreational areas more mechanically interesting. Henri's NT recruitment arcade game, for example, lured a lot of people into the arcade / made them install new machines around the station. Some people know how to use cards well and host blackjack games in the bar. We need more of these, and then, I think, people will be less likely to gawk at command, waiting for the free circus, and instead they'd go and make their own fun.

If it only stopped bleeding during surgery, I'd be onboard with it because it'd stop the stupid-looking shower meta against slaughter demons (that medbay has to install showerheads above surgery beds or the slaughter demon will forever camp them). I would not punish people for not using it, apart from the thing we usually have (that is, the patient leaves behind a bloody mess).

RCDs are somewhat necessary now, as Quark said, the alternatives are very clunky. If I were to change anything about it, I would make them slower when it comes to removing things, especially airlocks. Otherwise, I find them fine. If we wanted to make people less of a "we are not building station goals until we get an RCD", I think the alternatives should be made more comfortable to use. The duffelbag change helped engineering a lot, you can now bring a lot of materials on you - it is just not many people know about the slowdown changes (sadly). The usual chokepoint for me when building new places is circuits. They take up too much space in the bag. If there was a box or a satchel for example, that could exclusively hold basic engineering circuits/items (camera assemblies, apc/air alarm/fire alarm circuits, power cells), I'd be more inclined to build things away from cargo/engineering without the magical RCD.

I took 15 minutes to look at some data just to ensure we are not holding this discussion based on emotions and I-feel-likes, because this topic is leading to nowhere. Since 12 January, 300 PRs were handled of which 40 got closed. At maximum, 11 of those got rejected visibly on GitHub, of which 4 did not get a written reply as to why. This is a solid 100 PR / month with a little over 1 getting rejected without an explanation on GitHub (not counting the possible discussion between the PR opener and the maintainers on Discord). PR closed/abandoned by their author for personal/technical reasons or they made an alternative PR (28): https://github.com/ParadiseSS13/Paradise/pull/20417 https://github.com/ParadiseSS13/Paradise/pull/20400 https://github.com/ParadiseSS13/Paradise/pull/20378 https://github.com/ParadiseSS13/Paradise/pull/20377 https://github.com/ParadiseSS13/Paradise/pull/20374 https://github.com/ParadiseSS13/Paradise/pull/20373 https://github.com/ParadiseSS13/Paradise/pull/20365 https://github.com/ParadiseSS13/Paradise/pull/20364 https://github.com/ParadiseSS13/Paradise/pull/20358 https://github.com/ParadiseSS13/Paradise/pull/20355 https://github.com/ParadiseSS13/Paradise/pull/20338 https://github.com/ParadiseSS13/Paradise/pull/20318 https://github.com/ParadiseSS13/Paradise/pull/20317 https://github.com/ParadiseSS13/Paradise/pull/20316 https://github.com/ParadiseSS13/Paradise/pull/20296 https://github.com/ParadiseSS13/Paradise/pull/20292 https://github.com/ParadiseSS13/Paradise/pull/20647 https://github.com/ParadiseSS13/Paradise/pull/20633 https://github.com/ParadiseSS13/Paradise/pull/20624 https://github.com/ParadiseSS13/Paradise/pull/20557 https://github.com/ParadiseSS13/Paradise/pull/20555 https://github.com/ParadiseSS13/Paradise/pull/20510 https://github.com/ParadiseSS13/Paradise/pull/20475 https://github.com/ParadiseSS13/Paradise/pull/20446 https://github.com/ParadiseSS13/Paradise/pull/20269 https://github.com/ParadiseSS13/Paradise/pull/20212 https://github.com/ParadiseSS13/Paradise/pull/20210 https://github.com/ParadiseSS13/Paradise/pull/20186 PR closed by maintainers stating the reason on the PR (5): https://github.com/ParadiseSS13/Paradise/pull/20406 https://github.com/ParadiseSS13/Paradise/pull/20357 https://github.com/ParadiseSS13/Paradise/pull/20272 https://github.com/ParadiseSS13/Paradise/pull/20235 https://github.com/ParadiseSS13/Paradise/pull/20202 PR closed by maintainers without stating a reason on the PR (4): https://github.com/ParadiseSS13/Paradise/pull/20396 https://github.com/ParadiseSS13/Paradise/pull/20386 https://github.com/ParadiseSS13/Paradise/pull/20382 https://github.com/ParadiseSS13/Paradise/pull/20205 Either dev objection on Discord or personal, could not decide (1): https://github.com/ParadiseSS13/Paradise/pull/20370 Dev objection on Discord, not stated on the PR (2): https://github.com/ParadiseSS13/Paradise/pull/20509 https://github.com/ParadiseSS13/Paradise/pull/20178

I'd rather not make any developer more of a target than they are now. The loud minority of the SS13 community is unfathomably toxic. I have been a developer on another server where I constantly got angry as hell PMs for my opinion on major reworks and features that I publicly stated. I was told to kill myself more often as a developer than a moderator. I know for a fact our maintainers have unsavoury people in their DMs as well. This 100%. We can keep banning people, it does not undo the damage of maintainers waking up to literal death threats over a stupid pixel game. We had Discord servers grouping up and harassing developers/maintainers when things did not go their way. Most PRs that get rejected have a very clear reason stated on it. Some only get a "people voted against it, so closing it". It is not perfect, but the devteam handles 20+ PRs a day. In comparison, the company I work at handles about 10 PRs a day, and we are here 8 hours a day for an actual salary. The unfortunate truth is that you cannot expect them to be perfect and professional with each PR, even if it sucks to be on the receiving end. (I know, I have been on the "silently closing" side). Best thing you can do is to ping the closing maintainer and ask for help if they forgot to state a reason. I doubt anyone would turn you away if you asked for constructive criticism.

Accumulating damage sounds like a really good starting point. The slower the triage provided, the more work to do once the heart is beating again. That'd reward good paras/nurses without making mass revival impossible during biohazard rounds.

FBPs would be a very interesting way of revival. Not IRCs - proper FBPs. I've seen it on other servers and it adds weight to late revivals. "Oh god, I am fully synthetic on the outside now?" It is so rarely done here. No, you can choose between life and death. Choosable cloneability decides whether you want to get cloned by a cheap, boring method, or you want the doctors to work for it. (Similar thing kinda once you pick non-cloneable species). If coding was the only issue, I could get help for it - just keep in mind that it was never fully OK'd by the design team. In a hindsight, I am not sure if this was a good idea, either. It feels like a bandaid solution. Medical is not bald because we lack good medical players - medical is bald because the good medical players are not willing to play. You can learn all the ins and outs of how bleeding works, how to effectively use lesser known drugs like atropine or salacid, and the like, it all means nothing in the end when 90% of all bodies that come in just instantly get hurled into the cloner by a random bystander. I firmly believe the "we shouldn't remove cloning because then we will have no medbay!" argument is backwards. People stick with jobs because they present a challenge and they are exciting. A lot of people got bored of security when we had the old stuncombat because all it involved was "hit the antag with the funny yellow bolt and you won" and, similarly, get hit once by the funny stunprod and lose. Now that the handholding was removed from it, it became a way more exciting and thus way more popular job. I sometimes play on Baystation too where medical procedures have a weight and the system itself has a lot of mechanics that actually come into play because there is no one-stop solution for most people - and I stick with it. I don't want to play other jobs. Here, on Paradise, I sometimes play Chemist to see numbers go up, but again, most drugs are never used because why would anyone fix up a body with 300 brute, two IBs, and a fracture when they can just put it into the funny tube and get it back fully healed with full blood? Medical is fun until you figure out how to fix slightly hurt bodies and until you commit surgeries to muscle memory. Afterwards, you just realise cryotubes, two specific drugs, and the cloner fixes almost every case. I agree that permadeath should not be too encouraged on Paradise, we are not that kind of a server. To make it clear: I want cloning to go away, it is cheap, stupid, and boring. But we need a very, very good alternative for it for which I have not yet seen good ideas yet. Making the SR less dangerous is a good step but it is not enough, SR itself needs an overhaul (its recipe is dumb and currently its best use is to field execute changelings). Unfortunately, these topics usually lead to nowhere because these alternatives are not thought through from the gameflow's point of view. If we remove cloning, what is there instead? The 5 min timer to defib, SR, brain transplant, and cyborgification. What alternatives can we offer? If we increase the defib timer to 10 minutes, that can work - or if there was a drug (space formaldehyde?) that extended the timer. If we popularise SR, we will need many more surgeries, for which we might need a third OR, especially during highpop, or a way for medical to print cheap prosthetics. If we popularise brain transplants, we'll inevitably piss off people who play non-standard races (vox and plasmamen are unlikely to revive once they are put into a human body). Cyborgification is currently bugged if you want to make a shell without laws. So, TLDR: If anyone wants cloning to go away, offer alternatives by saying "x could be done which would lead to y but could be fixed by z". This is a good starting point of a discussion. Talking about why cloning should or should not stay will send us into the same loop as it has been doing so for the past 6(?) years.

Discounts can be set on a per item basis, so that is entirely possible!

This is a new feature I have been coding, I am looking for ideas on how to expand it and make it better. The PR in question is here for those interested in its code. Shoppers Card A new item selectable in Character Setup. A loyalty card, a clubcard, whatever you call it IRL - you have a discount card associated with one of the big companies of our world! In Character Setup, you can choose a company (NanoTrasen, Mr. Changs, Donk Co, etc.). Upon spawning in, you get a shoppers card of that company that you can attach to your ID. Every purchase made with this ID will have a whoppin' 10% discount on products associated with your chosen company and make you eligible for a raffle! For example, if you have a Mr. Changs shoppers card on your ID and you purchase a chow mein, you'll get a 10% discount on the price. Mechanics, limitations Similar to guest passes, it can be slapped on and taken off from IDs. One ID can hold multiple shoppers cards. Shoppers cards are not account-bound. If you steal someone else's, you enjoy the same discount as they did before. To avoid metaslavery, YouTool items will not be associated with any company (thanks, Zorazi!) Possible Ideas Have command have an extra, special type of shoppers card, and make it a theft objective? Have all traitors spawn in with a Syndicate shoppers card but also add it to maintenance loot to make metachecking impossible (and for extra swag)? Track number of purchases for a bigger discount or other goodies? Events Lucky Buyer One planned event is being the "Lucky Buyer". The gist of it: Player purchases a discounted item. With a very low chance, this event gets queued up as a "Minor Event". This can get queued only once per round. When triggered, a station-wide announcement appears "Congratulations, [name on the ID], for being the [500.000th / 1.000.000th / semi-random big number here] at [company name]! You have been rewarded with [measly amount of money] for your loyalty." Example: "Congratulations, John Doe, for being the 1.000.000th customer of The Syndicate! You have been rewarded with $50 for your loyalty." This can get alternative rewards. Perhaps a crate sent from CC with something in it? This event gets removed from the possible events pool in the round. More event ideas here are welcome. Products Products are associated with companies on a product level, not the vending machine, so a vending machine can hold multiple companies' goods at once. You can see our existing corporations and factions here and our vending machines here. While chow meins, being in Mr Changs' own vendor is obviously a Mr. Changs' product, what about the others? Which organisation creates Space Twinkies, for example? NanoTrasen? Or is it a Shellguard Munitions product with a hidden agenda? Are crayons truly made for Sol Gov Marines? Here is your chance to come up with ideas. Both serious, hilarious, and out-of-game-reference ideas are welcome. This is a chance to make our little world a bit more colourful!

I meant that if the cyborg gets antag status via MMI/emagging, then the objectives should not automatically transfer; as with the AI, they share a network so the cyborg can instantly download objectives, vs the emag just makes it malfunction. However, I don't mind the objectives being shared if they become antags otherwise, it just did not seem logical to me. If this can be resolved with team antags, then I have 0 issues with them instantly sharing stuff.

Looking for a code solution here, this is what I'd like to request: When a cyborg is synced to a malf AI, inherit its antag status, inherit its objectives. When a cyborg is de-synced from a malf AI or gets synced to a different AI, remove its antag status, remove its objectives, give it a BIG RED TEXT YOU ARE NO LONGER ANTAG. Law 0 should be not touched, it should only be removed via the proper channels (cyborg upload console, new AI syncing). Optional: Rephrase "Accomplish your AI's objectives at all costs." to something like "Accomplish the objectives of the AI you are synced to." The wording is up to you, just include "synced to" in it. Reasoning: Malf AI happens. Cyborgs start rampaging. Robotics removes the AI link. Their zeroth law becomes moot ("Accomplish your AI's objectives at all costs.") Cyborgs still keep killing. Ahelp galore. Cyborgs don't know what the AI's objectives are and yet they are expected to carry them out. This is different from vampire thralling, for example, where you have to obey your master - in the cyborgs' case, the player is expected to do something they are not made aware of. Yes, they can ask on binary, but 50% of the time that results on ";b ok ai so what are your objectives" and the AI's round is pretty much ended due to a newish player messing up. Ahudded people have an easier time to check which cyborgs are up to no good. Bonus points if you can do the same with emagging/syndicate MMI. These methods should NOT share objectives (you cannot see into your mindslaver's head), but it should give the cyborg antag status and a big red text to stop screaming that the janitor is emagging me!!!11 In the case of emagged cyborgs, the only way to get de-antagged is to get put into a new chassis and/or get taken out of a syndicate MMI to my knowledge.

You can set up the solars as a drone. Not even cyborgs can set up the supermatter currently, it is a design choice to ensure silicones to be not completely self-serving.

Exactly, 50% of the original reagents are transferred, you can see it here. /obj/item/reagent_containers/food/pill/patch (...) apply_type = REAGENT_TOUCH transfer_efficiency = 0.5 //patches aren't as effective at getting chemicals into the bloodstream. What you are interested is the very next proc in this (patch.dm) file: /obj/item/reagent_containers/food/pill/patch/attack(mob/living/carbon/M, mob/user, def_zone) if(!istype(M)) return FALSE bitesize = 0 if(M.eat(src, user)) if(user.get_active_hand() == src) user.drop_item() // Only drop if they're holding the patch directly forceMove(M) LAZYADD(M.processing_patches, src) return TRUE return FALSE Here, you basically force-feed people something but since it has zero bitesize, they don't crunch on it. The transfer_efficiency ensures you only gave them 50% of the reagents in it. What you want to look out here for is this: LAZYADD(M.processing_patches, src) Lists like this are usually used in other procs, so let's follow it. Searching for it brings up life.dm, which handles your mob every tick (among other stuff): /mob/living/carbon/Life(seconds, times_fired) (...) if(LAZYLEN(processing_patches)) handle_patches() Looks like our patches are more than "forcefeed and transfer units into the person", it has its own proc. Let's see it: /mob/living/carbon/proc/handle_patches() var/multiple_patch_multiplier = processing_patches.len > 1 ? (processing_patches.len * 1.5) : 1 var/applied_amount = 0.35 * multiple_patch_multiplier for(var/patch in processing_patches) var/obj/item/reagent_containers/food/pill/patch/P = patch if(P.reagents && P.reagents.total_volume) var/fractional_applied_amount = applied_amount / P.reagents.total_volume P.reagents.reaction(src, REAGENT_TOUCH, fractional_applied_amount, P.needs_to_apply_reagents) P.needs_to_apply_reagents = FALSE P.reagents.trans_to(src, applied_amount * 0.5) P.reagents.remove_any(applied_amount * 0.5) else if(!P.reagents || P.reagents.total_volume <= 0) LAZYREMOVE(processing_patches, P) qdel(P) That is a lot of maths and I am bad at maths, so let's substitute some of it with numbers. Let's say we applied a 15 units styptic patch and the mob has no other patches applied. /mob/living/carbon/proc/handle_patches() var/multiple_patch_multiplier = 1 var/applied_amount = 0.35 for(var/patch in processing_patches) var/obj/item/reagent_containers/food/pill/patch/P = patch if(P.reagents && P.reagents.total_volume) var/fractional_applied_amount = 0.0233333333333333 P.reagents.reaction(src, REAGENT_TOUCH, 0.0233333333333333, P.needs_to_apply_reagents) P.needs_to_apply_reagents = FALSE P.reagents.trans_to(src, 0.175) P.reagents.remove_any(0.175) else if(!P.reagents || P.reagents.total_volume <= 0) LAZYREMOVE(processing_patches, P) qdel(P) (Disclaimer: using a number such 0.0233333333333333 will inevitably lead to inaccuracy, but to keep things simple, I'll keep it here). First, it reacts with the mob with the reaction() proc, let's see that. The first half of the proc checks if the applied reagent is too cold or hot, so we can skip that. The second half is what we are interested in: for(var/AB in reagent_list) var/datum/reagent/R = AB switch(react_type) if("LIVING") var/check = reaction_check(A, R) if(!check) continue R.reaction_mob(A, method, R.volume * volume_modifier, show_message) The last line is the only thing that matters in our case. Volume here refers to the original volume of the patch, which is 15, so it becomes this: R.reaction_mob(A, method, 15 * 0.0233333333333333, show_message) This equals to about 0.35, we will use a rounded number here for sanity's sake. This is a deep rabbit hole, let's keep going!! So what do we have in the end? Let's go back to handle_patches(): /mob/living/carbon/proc/handle_patches() var/multiple_patch_multiplier = processing_patches.len > 1 ? (processing_patches.len * 1.5) : 1 var/applied_amount = 0.35 * multiple_patch_multiplier for(var/patch in processing_patches) var/obj/item/reagent_containers/food/pill/patch/P = patch if(P.reagents && P.reagents.total_volume) var/fractional_applied_amount = applied_amount / P.reagents.total_volume P.reagents.reaction(src, REAGENT_TOUCH, fractional_applied_amount, P.needs_to_apply_reagents) P.needs_to_apply_reagents = FALSE P.reagents.trans_to(src, applied_amount * 0.5) P.reagents.remove_any(applied_amount * 0.5) else if(!P.reagents || P.reagents.total_volume <= 0) LAZYREMOVE(processing_patches, P) qdel(P) Now we know that reaction() applies 0.35 per proc, while the P.reagents.trans_to(src, applied_amount * 0.5) transfers 0.175 units. At any given time, the mob will have 0.175 units in their system (you can use a health analyzer to prove this), but an extra 0.35 will be applied every tick. Application and transfer are different, you'll see soon why! We know patches transfer half of their volume, so a 15 units styptic patch will only transfer 7.5 units in the end. 7.5 units are transferred in 0.175 increments, so a 15 units patch transfers its contents 42.85 times. Check what styptic powder does: /datum/reagent/medicine/styptic_powder/on_mob_life(mob/living/M) var/update_flags = STATUS_UPDATE_NONE update_flags |= M.adjustBruteLoss(-2*REAGENTS_EFFECT_MULTIPLIER, FALSE) return ..() | update_flags /datum/reagent/medicine/styptic_powder/reaction_mob(mob/living/M, method=REAGENT_TOUCH, volume, show_message = 1) if(iscarbon(M)) if(method == REAGENT_TOUCH) M.adjustBruteLoss(-volume) if(show_message) to_chat(M, "<span class='notice'>The styptic powder stings like hell as it closes some of your wounds!</span>") M.emote("scream") if(method == REAGENT_INGEST) M.adjustToxLoss(0.5*volume) if(show_message) to_chat(M, "<span class='warning'>You feel gross!</span>") ..() When it ticks inside the body, it heals 2 brute. We know it will tick 42.85 times, so we know the transfer will heal a whoppin' 85.7 brute! But what happened to the applied part? Let's see the reaction_mob() proc. If it is applied via touch, it heals its amount. Its amount is 0.35 (from the reaction() proc from before, remember?) which means we will heal an extra ~14.9975. Or, to make it a bit more simple: from the transfer, it heals 2 brute, from the application, it heals 0.35, so we heal about 2.35 per tick 42.85 times. We lost some precision due to me not being able to use numbers properly, but we should heal about 100.6975 (+ an extra 0.35 when we actually apply the patch, so about 101.0475). Let's spawn a human and deal 150 brute to it, then apply a 15u styptic patch. He went down to 48.95, which means he healed 101.05 brute. That is plausibly close to our expected number (101.0475), so you'll have to take my word for it! What's fascinating is that due to how the apply part is calculated, a twice as big patch does not heal twice as much. The apply part will always heal 0.35 per tick, and the patch will always transfer 0.175 (as long as only one patch is present). So by increasing the volume of the patches, you make it tick for longer, not heal more at each given tick. To prove it, spawn a 30 units styptic patch and deal 100 brute to a mob. Apply to the patch. Every time the mob falls below 20 brute damage, apply another 100 brute damage to it (to avoid getting him into cardiac arrest). In the end, the mob will heal for 202 damage. From our calculations, a 30 u styptic patch ticks for 30 / 2 (remember, half of the volume is transferred) / 0.175 = 85.71 times (roughly), healing 2.35 every tick + an initial 0.35. That's 85.71 * 2.35 + 0.35 = 201.7685. Our maths add up! Frankly, I suck at maths, but I hope it answered your question somewhat!

The original poster took the time and effort to offer suggestions, cherry-picking ones you don't like to then just say "git gud" or "no fun allowed" is really not constructive - it's just you being an ass for no reason. It's fine if you disagree with ideas but let the poster know why it would not be fun, balanced, or reasonable instead of this.

To my knowledge, there is nothing in SOP or law that says that the HoS/Warden should ensure all weapons are returned to the Armory once the situation has been resolved, it is more of a player culture thing. I might be wrong but if I miss it, then it is probably not clear enough that they should be doing it. (It is probably covered by the secoff SOP's "they should carry x (but not lethals)" on these levels, but that doesn't really make it clear for the warden that everything should be back in the Armory, is it...)

Unsure what the goal here is. The title says stun but your post talks about a knockdown? Which one would you like it to achieve? Stun means they fall down and cannot move or interact with items. Knockdown means they fall down and can move around and interact with stuff.

ICly, it is a crime to kill pets (Ian, Runtime, etc.) it falls under "Damage to Station Assets". The difficulty lies in finding a security officer who cares enough to enforce this part of the law.

New colours would be cool. I suggest testing them in the game, give them some regular clothing (right-click -> select equipment -> engineer/doctor/etc.) and see how it looks like. One of the issues with vulpkanin, for example, that it allows for very saturated, very bright colours. If the character doesn't stand out (too much) from its clothing, then the colours are okay, regardless your monitor's calibration!

Having a set amount of charges and self-recharging over time by itself would be great, I think. If you'd tie recharging to a weapons recharger, then I'd suggest having more than only "a few" charges by default, since weapon chargers are not that common - yes, you can break into cargo or the meeting room for it, but I am wary of people "accidentally" moving weapon chargers to more secure places to avoid getting emagged into again. I cannot suggest any actual numbers, though, I have not used emag much. It probably still should have enough charges to be able to quickly emag your way into some critical places like the HOS office and their locker (4 charges), but if you have that many charges, you are inside evidence already. I think this change wouldn't fix the quick and easy evidence raids, that needs another fix (access-locked windoors, for example).

Such situations usually call for admin intervention to end the round, either by the crew requesting it (nuclear codes) or us sending in the deathsquad. Normally, it should be the captain's responsibility to secure and, if necessary, use the nuke when a biohazard takes over, but this is not done much lately. Not sure it is because the nuke doesn't feel like a "win", if command is not aware how to call the codes, or because - and I think this is the most prominent factor -, people just don't know how big the actual blob is. Code-wise, we could announce it if a biohazard grew to a certain point, which would give everyone a very clear indication of how bad things are. A bioscan of sorts, similar to how cult gets halos after converting enough people. That would (hopefully) push command to step up and act before the server grinds to a halt.

I am on the edge about this idea, because I genuinely despise doctors hogging multiple hyposprays/handheld defibs. They were intended to be QoL items in the first place (no need to use epipens then litter with the empty injector), not something to bypass pill timers/patch requirements with. I believe cyborgs have a hypospray with multiple chemicals in it because they are physically unable to use pill bottles/patch boxes or administer pills/patches. Doctors are capable of all of this, and I don't see a situation where one absolutely needs to inject something instantly that is not epi or salbutamol (to keep the patient alive). I am not sure if people are not aware of these pill/patch containers and thus not using them or if chemistry has not enough active players for multihypos becoming the standard. The idea itself is good, cyborgs already have it and it is useful, but I don't think it'd be healthy for the game. People gotta slow down a bit.