Jump to content

Miraviel

Retired Admins
  • Posts

    238
  • Joined

  • Last visited

  • Days Won

    17

Posts posted by Miraviel

  1. >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).

  2. 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.

    • Like 3
  3. 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).

    • Like 1
    • derp 1
  4. 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.

    • Like 1
  5. 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

    • Like 6
  6. 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.

    2 hours ago, Spacemanspark said:

    Banning someone does not prevent them from being a toxic twat in the first place. You cannot solve every administrative issue by playing whack-a-mole, and burnout is a very really concern when it comes to being a part of any SS13 community staff team.

    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.

  7. 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.

    • Like 1
  8. On 1/28/2023 at 9:54 PM, Spacemanspark said:

    I've brought up the topic of removing cloning several times within the Para discord, and each time it was a clusterfuck. My (albeit now very irrelevant) opinion still stands; Paradise would do well to remove cloning and strange reagent entirely from the game. Leave defibs, FBPs and borgification as the remaining methods in which someone returns to life. 

    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.

    On 1/28/2023 at 10:14 PM, McRamon said:

    You can already choose to not get cloned

    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).

    On 1/28/2023 at 10:44 PM, Generaldonothing said:

    https://github.com/ParadiseSS13/Paradise/pull/18908

    Mira tried this but couldn't get something technical related down. Was a pretty cool concept though imo

    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.

    On 1/30/2023 at 4:53 PM, TheBadPerson said:

    The rounds are two hours long, and medbay is totally bald about 75% of the time.

    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.

    On 1/30/2023 at 8:58 PM, CinnamonSnowball said:

    As for whether we even need revival to be common - I'm fairly certain the answer is 'yes'. People have raised points about some antags we have like blob, which almost requires a steady supply of crew to fight it otherwise it tends to snowball out of control, but even besides that - there are people who can't devote much time in their day to the funny spessmen game of which rounds each take 2 hours on average, and it doesn't make for a very fun playing experience to be completely removed from the round because nobody found your body in 5 or even an extended 10-15 minutes after some antag happened to shank you and hide your body early on.

    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.

    • Like 5
  9. 2 hours ago, Sadhorizon said:

    Question, would discounts also apply to drip?
    Having discounts per type of clothing would be cool, so one company takes care of berets, other of winter clothing, other (NT most likely) of /rank jumpsuits, other maybe of basic shoes etc.

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

    • fastparrot 1
  10. 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.

    image.png.a7304deb2addca3c16f29dee8bdcac1d.png

    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:

    1. Player purchases a discounted item.
    2. With a very low chance, this event gets queued up as a "Minor Event".
      • This can get queued only once per round.
    3. 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?
    4. 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!

    • Like 9
  11. On 1/20/2023 at 3:41 PM, SteelSlayer said:

    You say in the beginning of your post that borgs should inherit the AI's objectives, but later on say "These methods should NOT share objectives". Can you clarify: do you want the borg to be able to have these objectives in its notes?

    My initial thought it to use an antag team (/datum/team) which will simplify things quite a bit, however team members share objectives.

    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.

     

  12. Looking for a code solution here, this is what I'd like to request:

    1. When a cyborg is synced to a malf AI, inherit its antag status, inherit its objectives.
    2. 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.
    3. Law 0 should be not touched, it should only be removed via the proper channels (cyborg upload console, new AI syncing).
    4. 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.

    • Like 1
  13. On 11/14/2022 at 5:36 PM, Im99%SureThatIm1%Unsure said:

    I've been code diving for medical shit and still can't figure out how patches work. From what the wiki says, a 30u styptic patch should apply 15u (half efficiency), and those 15u will heal 15 brute damage (heal brute equal to volume). But that's not what happens, and for some reason you can heal around 100 brute with a single mini-patch (15u).

    Just want a way to know exactly how much damage a specific volume of patch will heal, since it feels kind of random.

    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!

    • Thanks 2
    • eyes 1
    • fastparrot 1
  14. 19 hours ago, Vilshen said:

    >Remove hydro from Cyborg Hypospray 
    tfw there are no robotics, so you, armless, have to do surgery without a painkiller
    > and its cultist soul stones, as wizard you are unable to use them, you can only do it if you are cultist wizard... should it be this way? why wizard can't use them?
    Wizard has a spell specifically to let him use them
    >GPS upgrade
    The biggest problem with this is that it sounds like a pain to implement, especially with how the space loops on itself
    > Make Mining Hardsuit don't restrict movement on lavaland
    I don't know if the code even allows it, but *all* crew hardsuits have the slowdown, why do miners get to be special (especially considering how they already have a lot of gamer gear). 
    >Ability to "struggle" free from goliath tentacles, when there are 2 goliaths or watcher with goliath, you get owned quickly, it would be nice if there was item to counter it and was avaliable at vendor
    Git gud. It's not that hard to dodge goliaths, so if you get in that situation, well...mistakes get punished. I could see letting you at least use your hands while stunned, but that's a different topic.
    >Removing Floor Painter from it and make as upgrade, so people playing them dont make eye hurting floors.
    "NO. FUN. ALLOWED!"
    >Remove RCD, its very advanced tool what make other tools have less use, can be obained as upgrade.
    Same thing, just making a borg's life harder for vague balancing reasons.

    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.

     

  15. 9 minutes ago, Coolrune206 said:

    I think a far better way to address this all would be stricter handling of armory weapons. Once the threat that caused them to be distributed is addressed, they should be recalled much sooner than they often are - as of present, if the armory is opened it's rare for all the guns to be back in it by the end of the round, let alone the end of the threat. 

    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...)

  16. 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.

  17. 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!

  18. 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).

  19. On 9/26/2022 at 8:33 PM, WingedYordle said:

    Throwing this out here. Is there a way the round ends if mid blob gets way to big, like as big as blob round? The game gets unplayable after it reaches to certain point. My FPS was gone with 5300ms.

     

    Yes I understand that this is mid round event and having this could ruin the main round but I feel like this is needed and if antags/crew can’t work together to kill blob, then it’s a well deserved red text as blob wins. If not I’d ask we remove it from the mid round spawn.

     

    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.

  20. 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.

    • Like 2
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Terms of Use