Thread Rating:
  • 1 Vote(s) - 4 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Testing the waters - expanding hypospray whitelist with MD access
#16
(10-30-2020, 09:59 AM)vampirate Wrote: some clownery

"other unrelated department has weapons, so the health department having weapons means nothing" is not a helpful or reasonable take. 
There's some fine nuance to balancing things and giving every department the right set of tools and challenges to overcome with those tools. 
Your eVeRyOnE eLsE iS dOiNg It WhY cAnT wE argument really lacks any kind of understanding of that, aside from being kinda rude.
Reply
#17
(10-30-2020, 04:46 AM)BatElite Wrote:
(10-28-2020, 08:15 PM)Frank_Stein Wrote: I think one thing I really wanted to express was the idea that a head unlocking something would be a kind of equivalent to opening the armory, something that is an immediate benefit to a crisis situation for the whole department while being potentially dangerous and loudly announcing it has happened.
I'm curious then what you were thinking of with your idea. Medbay crises tend to be of the explosive nature and there's not much cooperation between doctors. This was also meant to help with that. :P

I think crisis response was what was on my mind, with a medbay flavor. Which isn't an argument against expanding hyposprays if it means you can load them with more risky medicine, just that we should lean towards things that speed up the medical process.

A couple other things that could happen is medical dispensers access levels opening up to be usable by more people, or medical bots becoming more aggressive in their efforts.
Reply
#18
I'm gonna bump this since a recent idea I've had is very similar to this and the ideas in this thread can tie into it.

Instead of a flat MDir-restricted hypo with expanded whitelist, I propose another variant of the Hypospray that will do the following:
A) Refuse to inject if the injection would push any reagents in a patient above a certain limit, usually the OD limit.
B) Have a delay on injection akin to a syringe if the patient is *not* in critical condition.
C) Have an expanded whitelist that includes atropine and other chems (not sure what)

To clarify A; the hypospray would check the reagents in a person, check how much of each reagent the hypospray should be injecting based on what's inside of it and what the doseage is set to. The hypospray then adds the reagents' quantities together, and if even one is above a set value dependent upon the actual reagent, it will refuse to inject. For example, say you have a hypospray of epinephrine that's injecting 5u. A patient has 17u of epinephrine in them. The hypospray sees that if it injects, the amount of epinephrine in the patient will be 23, which is above the OD limit of 20. The hypospray will then refuse to inject, alerting the user that there is too much epinephrine already in the patient.
As another note, the limit of Atropine and other abusable medicines that are whitelisted should be set to a very low amount, such as 5u.

The goal of this is to essentially reduce the abusability of hyposprays if atropine was allowed to be put in (despite its side-effects being only a little more severe than some other whitelisted reagents, even in OD), as well as other medical chems. This would *also* provide a QoL bonus to doctors who don't want to accidentally OD a patient.

As a possible addition, the hypospray could also refuse to inject if the patient is allergic to anything inside the hypospray, but that's just another idea.


TL;DR: Hypospray variant that entirely prevents overdosing and abuse of certain reagents in combat, and adds to the QoL of medical doctors.
Reply
#19
(11-12-2020, 11:28 AM)aft2001 Wrote: I'm gonna bump this since a recent idea I've had is very similar to this and the ideas in this thread can tie into it.

Instead of a flat MDir-restricted hypo with expanded whitelist, I propose another variant of the Hypospray that will do the following:
A) Refuse to inject if the injection would push any reagents in a patient above a certain limit, usually the OD limit.
B) Have a delay on injection akin to a syringe if the patient is *not* in critical condition.
C) Have an expanded whitelist that includes atropine and other chems (not sure what)

To clarify A; the hypospray would check the reagents in a person, check how much of each reagent the hypospray should be injecting based on what's inside of it and what the doseage is set to. The hypospray then adds the reagents' quantities together, and if even one is above a set value dependent upon the actual reagent, it will refuse to inject. For example, say you have a hypospray of epinephrine that's injecting 5u. A patient has 17u of epinephrine in them. The hypospray sees that if it injects, the amount of epinephrine in the patient will be 23, which is above the OD limit of 20. The hypospray will then refuse to inject, alerting the user that there is too much epinephrine already in the patient.
As another note, the limit of Atropine and other abusable medicines that are whitelisted should be set to a very low amount, such as 5u.

The goal of this is to essentially reduce the abusability of hyposprays if atropine was allowed to be put in (despite its side-effects being only a little more severe than some other whitelisted reagents, even in OD), as well as other medical chems. This would *also* provide a QoL bonus to doctors who don't want to accidentally OD a patient.

As a possible addition, the hypospray could also refuse to inject if the patient is allergic to anything inside the hypospray, but that's just another idea.


TL;DR: Hypospray variant that entirely prevents overdosing and abuse of certain reagents in combat, and adds to the QoL of medical doctors.

It would be neat if maybe there were an upgrades that let you program different chems to be injected as needed in relation to the patients health, provided they stay still on the ground.

Essentially plug people with them and have it keep them stable while you do other things. A sort of field version of a sleeper
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)