# MAINTAINER - USE THE BUTTON THAT SAYS "MERGE MASTER" THEN SET THE PR
TO AUTO-MERGE! IT'S MUCH EASIER FOR ME TO FIX THINGS BEFORE THEY SKEW
RATHER THAN AFTER THE FACT.
## About The Pull Request
Hey there,
This took a while to do, but here's the gist:
Python file now regexes every file in `/code` except for those that have
some valid reason to be tacking on more global defines. Some of those
reasons are simply just that I don't have the time right now (doing what
you see in this PR took a few hours) to refactor and parse what should
belong and what should be thrown out. For the time being though, this PR
will at least _halt_ people making the mistake of not `#undef`ing any
files they `#define` "locally", or within the scope of a file.
Most people forget to do this and this leads to a lot of mess later on
due to how many variables can be unmanaged on the global level. I've
made this mistake, you've made this mistake, it's a common thing. Let's
automatically check for it so it can be fixed no-stress.
Scenarios this PR corrects:
* Forgetting to undef a define but undeffing others.
* Not undeffing any defines in your file.
* Earmarking a define as a "file local" define, but not defining it.
* Having a define be a "file local" define, but having it be used
elsewhere.
* Having a "local" define not even be in the file that it only shows up
in.
* Having a completely unused define*
(* I kept some of these because they seemed important... Others were
junked.)
## Why It's Good For The Game
If you wanna use it across multiple files, no reason to not make it a
global define (maybe there's a few reasons but let's assume that this is
the 95% case).
Let me know if you don't like how I re-arranged some of the defines and
how you'd rather see it be implemented, and I'd be happy to do that.
This was mostly just "eh does it need it or not" sorta stuff.
I used a pretty cool way to detect if we should use the standardized
GitHub "error" output, you can see the results of that here
https://github.com/san7890/bruhstation/actions/runs/4549766579/jobs/8022186846#step:7:792
## Changelog
Nothing that really concerns players.
(I fixed up all this stuff using vscode, no regexes beyond what you see
in the python script. sorry downstreams)
## About The Pull Request
Fixes#74326
Did a little uwupsie in #74227 - While writing up the PR body, I moved
around some tested code to better follow the logic flow of the procs.
And in the process that tested code was now in an untested position.
Parent call from `/obj/item/organ/internal/brain/Insert()` to
`/obj/item/organ/proc/Insert()` calls the
`/obj/item/organ/proc/on_insert()` proc.
This proc moves the organ to nullspace immediately.
So one of my commits moving the brain loc check from pre-parent call to
post-parent call meant the entire system broke, because the brain was
moved to nullspace and lost any reference to its former head.
Since `on_insert()` is the proc that handles moving the brain to
nullspace, and is a proc only run when an insert is successful, I can
sneak the code moving the brainmob from the head bodypart back into the
brain on the brain's `on_insert()` before the parent call.
This broadly makes the order of operations:
Attempt to insert brain, calling `Insert()`
If successful, call `on_insert()` as parent of parent proc call chain.
In `on_insert()`, set the brain's state up for the brainmob properly.
Back up the chain for the brain's child proc of `Insert()` all the code
now works properly because the brainmob's state was set up from
`on_insert()` which has to have been called already to reach this point.
The rest of that code still needs to sit in
`/obj/item/organ/internal/brain/Insert()` for now. This is because the
key transfer portion has to be preceded by the "is the target body a
ling?" code. This code relies on the bespoke `no_id_transfer` param on
`/obj/item/organ/internal/brain/Insert()` and fussing around with adding
a brain-specific param to the base
`/obj/item/organ/proc/Insert(mob/living/carbon/receiver, special =
FALSE, drop_if_replaced = TRUE)` proc is OOP gone wild.
Honestly, the entire thing needs a refactor but don't nobody got the
time to do that.
In testing I sheared a person's head off and reattached it via surgery a
few times. It worked. Ghosted out before surgery and could re-enter
body. DC'ed after having head cut off and could still re-enter body.
Seems to work.
## Why It's Good For The Game
Feeeeeeeeex.
## Changelog
🆑
fix: Actually fixes re-attaching heads unintentionally sending brains to
the gem room this time. For realsies.
/🆑
Added in #44764
Removes the code that allows a human to be cremated by high burn damage
and being on fire
🆑
del: removes being cremated from high burn damage and being on fire (yes
this was in the game but has been broken for probably a very long time)
/🆑
### Why this is good for the game
This was added about 4 years ago, but never really worked (or broke
pretty quickly afterwards) because of a rounding error in the burn
damage code. GoldenAlpharex actually stumbled upon this when working on
a downstream and explained how it broke, and I kind of agree that it
doesnt fit that well into the game anymore
This was added when cloning was still a thing and being husked didn't
mean much if the cloner was upgraded. With the removal of cloner, being
husked is enough punishment in my opinion and we dont need to add
cremation. We've also gone without this feature for quite a while and I
haven't missed it
EDIT: Oops, just talked with something and I need to point out it does
work on species that have increased burnmods. Plasmamen self-cremating
themselves is actually a thing that happens in-game
## About The Pull Request
### The Rifle:
-The Sniper Rifle is now a bolt action. This replaces the 4 second fire
delay on the sniper rifle. This overall will improve the fire rate if
you're good at racking the bolt, but it will also feel less like you're
in a weird limbo of inaction while using the sniper rifle, since the
fire delay can be quite confusing to players not used to it. This can be
tweaked, like reducing the speed of the racking action, if it seems like
it is too much.
-The scope component now goes up to 50 tiles (or so), which allows you
to gain a significant sightline over an area. The reasoning for this is
simple. The component actually nerfed the overall range of the sniper
rifle's scope, so this should hopefully restore that somewhat. And
having such a huge sightline makes it much easier to utilize the
impressive range of the rifle. Currently, it's really only ideal for
extremely close range fighting.
-The normal sniper rifle, the one that syndicate base scientists get,
can be suppressed. I don't know why it was different.
### The Ammo:
Normal .50 BMG: Does much more object damage, and on top of that deals
additional damage to mechs, but not by much more. Now, when it
dismembers a limb, it also deals its damage to the chest. This ensures
that you didn't straight up lose out on dealing a killing blow because
you took their limb off, and makes the dismemberment property of .50 BMG
a significant upside rather than a immense detriment.
Marksman: Gains a lot of the above benefits, but has much lower range.
Why this nerf? It's actually because of some funny nonsense with how
ricochet works. Which can cause....accidents to happen. To you. Consider
that firing down a straight line and missing could be quite embarrassing
when the bullet has 400 tiles of range.
Soporific: Now called Disruptor ammo. Works as it did before, putting
humans to sleep for 40 seconds (seriously, 40 seconds). Also deals some
stamina damage, if...that's relevant. But now also causes an EMP effect
and a boatload of added damage to both mechs and borgs, allowing it to
be an excellent anti-mech and anti-borg ammo type, as well as scrambling
any pesky suit sensors, energy weapons and so on in an area around the
impact. Useful for support fire.
Incendiary (NEW!): Causes a massive firebomb to go off where it impacts
(no explosion, so this isn't a stun). Also sets the target on fire,
which is always fun. Good for shooting into groups of people with
impunity. Also deals burn damage instead, since I think nukies could use
more methods for direct fire damage.
Surplus (NEW!): It's .50 BMG but it lacks most if not all the upsides.
No armour penetration, no dismemberment, no paralysis. It still deals a
lot of damage to objects, so not a bad option for simply removing
structures from afar. So what's the point in this ammo? You can buy 7
magazines for the price of one. I want to introduce 'Surplus' as an idea
for nukies to invest in if they want to be able to keep shooting but
they're really on a budget, like most non-warop nukies tend to be. This
is definitely subject to change (like a damage decrease on top of
everything else).
Pricing and Capacity: Normal ammo and surplus costs 3 TC. Every special
ammo costs 4 TC. Every special ammo also has the same ammo capacity as
the normal magazine. It's kind of weird how most of the subtypes had 5
shots rather than 6, but then soporific had...3? I don't get it. This
would probably cause a good deal of confusion, especially if you are
swapping ammo types and weren't aware of this particular oddity.
Anyway, 6 shots.
### Minor Addition
Gets rid of the cheap suppressor. It lies to players, tricking them into
thinking this is a low quality suppressor. Newsflash, it isn't. There is
no distinct difference between that suppressor and the normal
suppressor.
## Why It's Good For The Game
The sniper rifle, unfortunately, sucks a lot except for very specific
use cases. It got a big nerf with the scope component in terms of range,
even if the functionality is way cooler. And, at a baseline, there was
some counterintuitive functions attached to it. Dismemberment was cool,
but it also caused a loss in overall damage due to how limbs contribute
to core health. On top of this, the cool ammo types were...not much
better? Penetrator was almost always the best option, even if it lost a
lot of damage as a consequence.
So, what was it good for? X-ray + Penetrator. Pretty much, that's it. It
has some other uses but if I had to be entirely honest, there wasn't
much that other weapon couldn't do as well.
Hopefully this helps things going forward, and I want to mess with this
as well down the line in case its a bit too much of a boost in power.
Absolutely please rip this PR apart.
## Changelog
🆑
balance: Makes the syndicate sniper rifle a bolt-action rifle.
balance: Sniper rifles have a scope range of roughly 50 tiles.
balance: Sniper rifle ammo, if it dismembers your limbs, does damage to
the chest.
balance: All the various syndicate sniper rifle magazines have
consistent casing quantities (6 shots). They also have more consistent
pricing. 3 for normal and a box of surplus, and 4 for every other type.
balance: Reduces the range of Marksman ammo to 50 tiles. Not because it
is strong, but because you might accidentally shoot yourself if you're
not watching where you're shooting. Ricochets are no joke.
add: Replaces Soporific with Disruptor ammo. Works like soporific, but
also EMPS things it hits.
add: Adds Incendiary .50 BMG. Causes a combustion to erupt from the
struck target, as well as setting targets on fire. Great for parties.
add: Adds Surplus .50 BMG. It sucks, but you get a lot of them! Quantity
over quality, baby.
remove: The suppressors in the bundle are of standard quality. The
apparent 'cheap suppressor' that came bundled with the C-20r and sniper
rifle were found to actually be 'fine'. Trust us.
/🆑
## About The Pull Request
Fixes forced gravity not updating a mob (trait was added too early,
before hook signals are registered)
Fixes spawning a mob in space not causing floats (default grav was 0, so
== null was wrong)
Runs shake_everyone() (Our gravity gen reaction hook) AFTER gravity
changes, ensuring mobs hook into it
## Why It's Good For The Game
Closes#74271Closes#74272 (Caused by being in nograv but not floating)
Closes#74274
## Changelog
🆑
fix: Fixes a bunch of minor gravity bugs, report em if you see more
yeah?
/🆑
## About The Pull Request
This PR adds a new helper proc which returns a list of all items
_visible_ on a human and then applies it to phobias in place of "all
items equipped on any slot of a human".
This excludes pockets at all times, and other slots if you are wearing
items which cover them up.
If you have a clown phobia and the CE is storing a bananapeel in their
pocket and is wearing a clown suit under their deployed MODsuit then you
will not be afraid of them as there is no reason you would be aware of
these facts.
As soon as they remove the banana peel from their pocket to their hands,
or undeploy their suit to reveal their secret baggy pants, the terror
will strike.
## Why It's Good For The Game
Phobias are annoying and debilitating by design, but they should at
least only be triggered by objects which have a visible and identifiable
source.
## Changelog
🆑
fix: Players with phobias will no longer be frightened by items equipped
to players in slots which are not considered to be visible.
fix: Players with a phobia of the supernatural won't be spooked by void
cloaks which are currently invisible.
/🆑
## About The Pull Request
Refactors regenerate organs to be slightly more intelligent in handling
organ changes and replacements.
Noteably:
- We don't remove organs that were modified by the owner; such as
changing out your heart for a cybernetic
- We early break out of the for loop if they aren't supposed to have an
organ there and remove it
- We check for the organ already being correct, and just healing it and
continuing if it is
Also changes the names of some of the organ helpers into snake_case
### Mapping March
Ckey to receive rewards: N/A
## Why It's Good For The Game
## Changelog
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
## About The Pull Request
Fixes https://github.com/tgstation/tgstation/issues/71636
Fixes https://github.com/tgstation/tgstation/issues/60927 - same issue,
has since been fixed and may be closed.
## Why It's Good For The Game
Podpeople were not replenishing blood because their `handle_chemicals()`
proc was not calling parent. Added `SHOULD_CALL_PARENT(TRUE)` to this
proc to prevent this issue from cropping up in the future.
## Changelog
🆑
fix: giving a podperson a blood transfusion by injecting them with
water/whatever their exotic blood happens to be will now work.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
This is a continuation of
https://github.com/tgstation/tgstation/pull/74085 - I announced in the
comments there that this would be my next PR, and this is it.
Removes SSnetwork, ``/datum/ntnet``,
``/datum/component/ntnet_interface``, ``var/network_root_id``, the
network unit test, and a lot of other things related to networks.
- NTNet circuits now check for an Ntnet relay, and uses signals to
operate.
- Logs in Wirecarp is now only for PDA and Ntnet Relay things, so you
can no longer see what ruins exist using it (why should Wirecarp know
that Oldstation spawned? The flavor is that they dont know its there).
- Removed it from MULEbots entirely, I don't think it even did anything
for them? Botkeeper seems to work without it, so it's possibly there
from pre-tgui PDAs.
- Moves assigning random names to a base proc instead of being tied to
network, this is things like random-naming scrubbers/vents. The behavior
hasn't changed at all.
- Makes Ntos work for consoles when relays are down, as the comments
said they're supposed to (because they're wired). I think this was an
accidental change on my part, so this is a revert of that.
## Why It's Good For The Game
Ntnet is ancient code that hasn't given us much that we can't do with
already existing alternatives, we've been slowly moving away from it for
init times, and though a large portion of that was limited to airlocks,
I still don't think this is a system worth keeping around.
It's way too complex to expect feature coders to do anything with it,
and too old with better alternatives for anyone to want to improve any
of it.
## Changelog
🆑
fix: Computers are now properly connected to Ethernet, and can use Ntos
when Relays are down.
refactor: Removes Ntnet and Ntnet interfaces, which was only used by
Ntnet circuits (which now directly checks for a Relay to work) and
MULEbots, which did nothing with it.
balance: Wirecarp no longer tells you what ruins spawned in a round,
instead it's limited to PDA logs, and tells you the source too. This
means the RD can catch someone running illegal programs if they don't
make any attempt at hiding it.
qol: Wirecarp logs is now set to save 300 at once, instead of 100 and
being increased to 300 by the RD during the round. This is pretty
insignificant, since there's no reason to NOT want as many logs as
possible.
/🆑
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
## About The Pull Request
### How things work
As things currently stand, when a mob breaths several things happen
(simplified to focus on the stupid)
We assert the existance of all possible breathable gases, and pull
partial pressures for them
Then we walk through all possible interactions lungs could have with
these gases, one by one, and see if they're happening or not
As we go we are forced to cleanup potential alerts caused by the
previous breath, even if those effects never actually happen
At the end we clear out all the unused gas ids, and handle the
temperature of the breath.
### What sucks
There's I'd say 3 different types of gas reactions.
- You can "need" a gas to survive. o2, n2 and plasma all fall into this
category
- A gas can do something to you while it's in your system. This applies
to most gas types
- Variation on the previous, some gases do cleanup when they're not in
your system, or when there isn't much of them in the first place
The main headache here is that second one, constantly cleaning up
potential side effects sucks, and fixing it would require a lot of dummy
variables
There's other suckage too.
Needing to constantly check for a gas type even if it isn't there is
stupid, and leads to wasted time It's also really annoying to do
subtypes in this system.
There is what amounts to a hook proc you can override, but you can't
override the reaction to a gas type.
It also just like, sucks to add new gases. one mega proc smells real
stupid.
### Improvements
In the interest of speed:
- I'd like to build a system that doesn't require manually checking for
gas
- Reacting to gas "disappearing" should be promoted by the system,
instead of being hacky.
- I would like to avoid needing to assert the existence of all possible
gases, as this is slow on both the assert and the garbage collect.
In the interest of dev ergonomics:
- It should be easy to define a new gas reaction
- It should be easy for subtypes to implement their own gas reactions.
The current method of vars on the lung is all tangled up and not really
undoable as of now, but I'd like to not require it
- It should be possible to fully override how a gas is handled
### What I've Done
Lungs have 3 lists of proc paths stored on them
Each list handles a different way the lung might want to interact with a
gas.
There's a list for always processing on a gas (we use this for stuff
that's breathed), a list for handling a gas in our breath, and a list
for reacting to a gas previously being in our breath, but not any more.
Lungs fill out these lists using a helper proc during Initialize()
Then, when it comes time to breath, we loop over the gas in the breath
and react to it.
We also keep track of the previous list of partial pressures, which we
calculate for free here, and use that to figure out when to call the
loss reactions.
This proc pattern allows for overrides, easy reactions to removals,
lower indentation code and early returns, and better organization of
signal handlers
It's also significantly faster. Ballpark 4x faster
### Misc
Removes support for breathing co2, and dying from n2 poisoning.
They were both unused, and I think it's cringe to clutter these procs
even further
Added "do we even have oxyloss" checks to most cases of passive
breathing.
This is a significant save, since redundant adjustoxy's are decently
expensive at the volume of calls we have here.
Fixes a bug with breathing out if no gas is passed in, assigning a var
to another var doesn't perform a copy
Rewrote breathe_gas_volume() slightly to insert gas into an immutable
mix stored on the lung, rather then one passed in
This avoids passing of a gas_mixture around just to fill a hole.
I may change my mind on this, since it would be nice to have support for
temperature changing from a hot/cold breath.
Not gonna be done off bodytemp tho lord no.
Uses merge() instead of a hard coded version to move the gas ids over.
This is slightly slower with lower gas counts but supports more things
in future and is also just easier to read.
## Why It's Good For The Game
Faster, easier to work with and read (imo)
Profiles:
[breath_results_old.txt](https://github.com/tgstation/tgstation/files/11068247/breath_results_old.txt)
[breath_results_pre_master.txt](https://github.com/tgstation/tgstation/files/11068248/breath_results_new.txt)
[breath_results_new.txt](https://github.com/tgstation/tgstation/files/11068349/breath_results_new.txt)
(These profiles were initially missing #73026. Merging this brings the
savings from 16% to 12%. Life is pain)
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
Followup to #74189
What it says on the tin. This is the last time I will ping you on a
blood-deficiency related PR, I swear! @san7890
About lizards--they have a special bloodtype that isn't compatible with
the generic O- that gets sent to everyone else, which I am just now
realizing.
I also realized that there is never a situation when `on_species_loss`
gets called without `on_species_gain` so there is no reason to call
`update_mail_goodies` in each of those. I deleted the extra proc calls
in `on_species_loss` to save on performance.
Also cleans up some single letter vars in the lizard species file.
## Why It's Good For The Game
Fixes an oversight, cleans up some code.
## Changelog
🆑
qol: lizards with blood deficiency now receive the type 'L' blood packs
instead of an unhelpful type 'O-' one.
/🆑
## About The Pull Request
Right now, each time life processes we need to run has_gravity, and
check its output against a bunch of thresholds.
We could save off that second bit by caching the previous value, but
we'd still be only updating this every 2 seconds.
This potentially delayed updating leads to really janky feeling behavior
around transition points too (like when moving on/off the sand on tram
station)
So instead of doing this updating off life(), let's make it event based.
We'll decompose has_gravity, and take all the values it relies on, and
check for them changing ourselves.
That way we get instant response, and can save all the wasted
has_gravity calls.
This constant checking on movement adds a few signal registrations, a
connect_loc, and some logic on living/Moved
The Moved logic increases Moved's self by 50%, roughly 1 second a round
at worst.
Don't have concrete numbers for the connect_loc
(new self / old self)
In constrast, handle_gravity is currently on average maybe 15 seconds.
I could JUST save maybe 13 seconds and not spend the 1 by storing the
previous gravity value, but I think this is worth the ux changes. It
does add some extra resistance to change, but s much nice.
Moved some functions around too, and removed now redundant
update_gravity calls
## Why It's Good For The Game
Snappier gravity, faster Life()
## Changelog
🆑
qol: Human gravity will react to changes instantly, instead of waiting
for the next process tick. Hopefully this feels better and not worse
/🆑
## About The Pull Request
Fixes#74126
Hi vsauce, Timberpoes here!
Brains are being sent the gem room. But why???? *musical sting*
Issue was caused by #73026
This early return added to brain Insert is the root cause.
Let's have a butcher's at some code, eh?
Here we have a parent call in `. = ..()` and then a check for brains and
brainmobs to do some special snowflake stuff before
`brain.Insert(new_head_owner)`.
This causes a problem. But WHY???????
Well... The parent call already inserts the brain, but without any
snowflake stuff done.
The parent call returns and the child proc
`/obj/item/bodypart/head/try_attach_limb()` which mashes the brainmob
into the brain and slams the `brain.Insert()` proc a **second** time.
This is a bug. But it worked despite being a bug, because the brain's
Insert proc would still do logic even if the Insert was technically not
successful.
But... We come back to this again:
If the new early return for the parent call is FALSEy, it stops all that
wonderful brainmob code from being executed.
... And ITS parent call is FALSE because `owner == receiver` is now
TRUE, as it was set the first time `Insert()` was called all the way
back in `/obj/item/bodypart/proc/try_attach_limb()`.
So the first `brain.Insert()` call in the parent
`/obj/item/bodypart/proc/try_attach_limb()` succeeds, but brainmob
related code isn't executed because the head bodypart hasn't set up the
brain's state correctly at this point.
And the second `brain.Insert()` call in the child
`/obj/item/bodypart/head/try_attach_limb()` which occurs after the
brain's state is correctly set, now fails because of an early return
when the insertion fails (the owner is already the receiver).
So, the old code only worked because it was bugged. Fixing the bug where
it worked, created a bug where it didn't.
But wait, why the gem room?
Well, since all the code that handled qdeleting the brainmob failed, it
persisted in the brain **even after the brain was inserted into the
body**. Where does the body store all of its organs? That's right, it
transfers them all to ~~the balls~~ nullspace!
And what is the brainmob? A mob! And what did it have? A client! And
what happens when cliented mobs find themselves in nullspace when a
Life() tick happens? A vacation to the gem room!
I have opted for a very simple fix. I've moved the code into
`/obj/item/organ/internal/brain/Insert()`. It now checks to see if it's
in a head when it's inserted into the new brain_owner. If it is, the
brain handles setting up its own state so it can successfully transfer.
`brain.Insert()` only gets called once instead of twice and the
snowflake behaviour is no longer controlled by the head.
In my testing of shearing off heads of guest clients and reattaching
them, this fixes the bug without any gem room errors on the other
clients.
## Why It's Good For The Game
Feex.
## Changelog
🆑
fix: Having your severed, brain-filled head reattached to a body no
longer teleports your brain to the mythical Gem Room.
/🆑
## About The Pull Request
I was looking over https://github.com/tgstation/tgstation/pull/74143 one
last time as I tend to do with merged PR's and noticed a couple of
nitpicky comment formatting things that will grate on me. Sorry about
this @san7890
Edit: Then even worse I found a bug. Roundstart species with blood
deficiency should now get the appropriate blood pack mail goodies sent
to them. I had completely forgotten about ethereals. Code is a bit
cleaner too.
## Why It's Good For The Game
Fixes bug, dmdoc formatting
## Changelog
🆑
fix: fixed blood deficiency quirk sending the wrong blood pack to
roundstart species who have exotic blood
/🆑
## About The Pull Request
Fixes#74208
One line change woo yea. How did we have this in place for vampires but
not ethereals? That's wild. Yeah yeah, I tested it. Everything is nice
and shiny, all works good.
## Why It's Good For The Game
So it turns out ethereals do not have AB- and what I just did is called
"malpractice".
## Changelog
🆑
fix: The intern who was recording Etheral crewmembers' bloodtypes as
random human bloodtypes has been replaced with an intern who has seen
the example made of the previous one.
/🆑
## About The Pull Request
It looks like this task has fallen to me.
The reason this was originally removed was threefold:
- Having your brain replaced would ghost you.
- Having your lungs replaced would often instantly kill you in a way
that people would take a long time to notice.
- Several abstract or otherwise inappropriate organs could end up inside
someone.
I have solved all three of these problems using a blacklist.
Lungs are simply never touched. Brains, sadly, are also never touched.
We _can_ modify your brain without ghosting you and originally I
implemented it that way, but the fact of the matter is that having your
brain scrambled is essentially irreversible except via DNA infuser, if
you had your brain replaced with a monkey brain which renders you unable
to use complex machinery (or worse, a Psyker brain) there is very little
that can be done about it.
If people think that this is good to have anyway I can put it back in
but it's probably for the best to leave it off.
I moved the code that the DNA infuser used to safely implant a brain
into a proc on organs when I originally expected that brain replacement
would be a feature of this PR, but I've left it there in case anything
else wants to do convenient brain replacement in the future (or already
does and can be updated to use this method).
The reason I didn't use a _white_list is because it seems like this list
would easily become incredibly long and nobody would maintain it. A
blacklist is slightly less safe, but reviewing the list it generates it
seems fine.
I also noted that the anomaly and the armour both implemented exactly
the same code in two places, so I moved that into a proc on `carbon`
instead. Now you don't need to apply changes in two places, and if
anything else needs to do this in the future once anyone adds literally
any items which use a bioscrambler core as material then it's easy for
them too.
Finally I scrubbed all cybernetics from the list and also made the
anomaly not affect cybernetics.
No strong reason for this one, just seemed like how it should work given
that it's also blocked by bio armour.
## Why It's Good For The Game
The bioscrambler in its current state doesn't do a whole lot, half of
the things it changes are invisible under your clothes and often won't
come up as a mechanical change unless you have developed chunky fingers
or a sunlight allergy.
This makes them somewhat more potentially dangerous and means people who
are negatively effected might turn up at medbay asking for new eyes or a
new stomach.
Like the Dimensional anomaly it also introduces somewhat of a gamble
feature. Some of the things on the list are _good_, and standing next to
it might help you rather than harm you. Or more likely, both. As the
infuser mechanic continues to add new organs with benefits and downsides
it also makes this anomaly more interesting.
Finally this gives the bioscrambler reactive armour a purpose, because
now it means that people attacking you have a chance to spontaneously
grow cat ears or snail eyes.
## Changelog
🆑
add: Bioscrambler anomalies will once again swap your organs with other
organs.
balance: Bioscrambler anomalies no longer affect synthetic parts.
/🆑
## About The Pull Request
This is a followup PR to
https://github.com/tgstation/tgstation/pull/73866
Fixes https://github.com/Skyrat-SS13/Skyrat-tg/issues/19991
I had suspected the nutrition loss slimes experience alongside blood
regen might necessitate some tweaks down the line and here we are. This
PR has two parts.
---
**PART I:** _Reworking the blood deficiency quirk backend_
As it is, blood drain from the blood deficiency occurs in the quirk's
subsystem process() call asynchronously to Life(), where the blood regen
occurs.
This results in the blood volume fluctuating constantly, making it
difficult to really make sense of readings and potentially introducing
race conditions. This PR changes that.
The blood deficiency quirk no longer processes and instead has a proc,
`lose_blood(delta_time)`, which is called in the `handle_blood()` proc
at the same time blood gets regenerated.
Added a `get_quirk` proc to help with this, so that we only have to
iterate through the quirks list once for each mob (rather than calling
has_quirk, then locate in quirks... etc).
Added a `TRAIT_BLOOD_DEFICIENCY` to further optimize the code.
---
**PART II:** _Some fine tuning of the slime blood deficiency quirk_
Slime regen works a bit differently than humans such that if they lose
-any- blood whatsoever, they will also lose nutrition. This means that
even if hooked up to an IV they will still become starving rather
quickly. A bit -too- quickly.
Instead, now the hunger does not kick in until `blood_volume` reaches
550. This means that if a slime with the blood deficiency quirk is
hooked up to an IV with say, welding fluid, and has over 150 nutrition,
they will regen blood faster than they lose it from the blood deficiency
quirk. Once they get to over 550 `blood_volume`, they will stop losing
hunger (from blood regen, anyway--normal hunger rate still applies).
So essentially this just allows slimes with the blood deficiency quirk
to be able to function so long as they stay hooked up to their IV's (or
chug welder fluid/some other toxin), which is the intended purpose of
the quirk.
Edit: As a bonus I added new blood bags for the exotic blood types, and
added a proc `update_mail_goodies` which updates the blood deficiency
quirk's mail goodies accordingly (crewmembers with blood deficiency get
sent blood bags, now they will get the correct type if their species
changes). While I was in these files I changed any immediate single
letter vars I could find and cleaned up what I could.
<details>
<summary>The new blood packs</summary>
</details>
## Why It's Good For The Game
-This is arguably a more performant option than before, and fixes race
conditions from `Life()` and `quirk/blooddeficiency/process()` fighting
with one another.
-Adjustments to slime blood deficiency will enable it to function as
intended.
-It is now easier to read health analyzer blood volume readings for
blood deficient mobs.
-Now the correct blood packs are sent in the mail.
## Changelog
🆑
qol: adjusted the blood deficiency quirk for slimepeople to not cause
excessive hunger as long as blood volume is kept above 550 via an IV
drip (or other means of getting welding fluid/some other toxin etc into
the bloodstream, e.g. ingestion)
qol: speciees with exotic blood types will now receive the correct blood
bag in the mail from having the blood deficiency perk
add: adds new blood bag types: TOX (slimepeople), H2O (podpeople), S
(snail)
fix: fixed blood deficiency quirk causing wild fluctuations in blood
volume on the analyzer, giving more accurate readings
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
Firstly, this var was on `/mob`, even though only `/mob/living` and
`/mob/dead` could have ever used it, so who knows how much needless
memory it was consuming on stuff such as `oranges_ear` that would never
ever ever use something like this.
Edit: okay instead of memory it just polluted variable edit windows for
all /mob when it didn't need to. I like having a slim VV window
Secondly, it's a technical improvement over the previous system as we
are able to "track" where a suicide originates from, and how we can
track that from mob-to-mob-to-mob. Previously, the boolean `suiciding`
would only inform us if they had ever been connected to a mob that had
ever committed suicide, but now we are able to precisely determine which
mob gave them the trait that they must now apparently bear until the
round restarts.
## Why It's Good For The Game
Less memory usage, more indepth ability to track suicides in case you
really need that dexterity. Currently no implemented code could benefit
from using it, but it would be pretty neat if someone could figure out a
way to have someone be guilt-tripped whenever they look into a mirror
and seeing the reflection of their past life? This PR won't actually
help you code that and it'll probably require a bit more work, but it's
a possibility of some cool interactions you can do when you have this
information available to you.
## Changelog
🆑
refactor: Some aspects of how we track suicides from your living mob to
your observer have changed- please do let us know if anything has broken
via a GitHub Issue Report.
/🆑
There's probably some technical improvements that can be made in some
parts of the code I reworked to accommodate this change, do let me know
if you spot any easy ones (or fuckups). a lot of excess comes from the
fact that any step in the TRAIT framework trusts that you are passing in
a valid datum (or subtype) so that's a thing
## About The Pull Request
Adds wirebrush to janitor vendor, ability to put it in janitor belt and
adds it for janitor borg.
Just though that if it's in-game then why is it just in autolathe.
It won't be used so rarely and it'll be obtainable not just by
autolathe.
When the NODISMEMBER trait check was passed, it would return without
calling the rest of AttackingTarget and not actually follow through with
dealing the damage. Now, the early return calls parent and completes
normally.
## About The Pull Request
- Tram crossing signals now call process() much less often
- Tram crossing signals don't turn amber/red needlessly
- Tram destination landmarks are more generic to accommodate future
maps, like Birdshot
- Renames to_where and from_where, because those vars didn't always
match tram position to/from
## Why It's Good For The Game
Tram works better, uses less processing
## Changelog
🆑 LT3
code: Tram crossing signal/platform logic improvements
/🆑
## About The Pull Request
Fixes#73830Fixes#74107
There seems to be a problem when the map template reloads for full
bright areas, but only for thunderdome specifically. Very strange and my
fix feels like a band-aid but it's a niche bug report.
Also deleted an area that was not used anywhere in the codebase.
## Why It's Good For The Game
Silly bug go bye bye.
## Changelog
🆑
fix: Fix not being able to read in full bright areas
/🆑
## About The Pull Request
Fixes#73154
Includes human height in icon render key.
The logic here is that if two mobs share the same icon render key they
probably grab the same icon and thus a tall person would grab a "short
person icon".
## Why It's Good For The Game
Melty bad
## Changelog
🆑 Melbert
fix: Fixes rare human arm melting condition
/🆑
## About The Pull Request
This PR adds a new unit test for all organs, a new unit test for lungs,
and includes improvements for the existing breath and organ_set_bonus
tests. Using the tests, I was able to root out bugs in the organs. This
PR includes an advanced refactor of several developer-facing functions.
This PR certainly represents a "quality pass" for organs which will make
them easier to develop from now on.
### Synopsis of changes:
1. Fixed many fundamental bugs in organ code, especially in
`Insert()`/`Remove()` and their overrides.
2. Added two new procs to `/obj/item/organ` named `on_insert` and
`on_remove`, each being called after `Insert()`/`Remove()`.
3. Added `organ_effects` lazylist to `/obj/item/organ`. Converted
`organ_traits` to lazylist. 2x less empty lists per organ.
4. Adding `SHOULD_CALL_PARENT(TRUE)` to `Insert()`/`Remove()` was very
beneficial to stability and overall code health.
5. Created unit test `organ_sanity` for all usable organs in the game.
Tests insertion and removal.
6. Created unit test `lungs_sanity` for
`/obj/item/organ/internal/lungs`.
7. Improved `breath_sanity` unit tests with additional tests and
conditions.
8. Improved `organ_set_bonus_sanity` unit tests with better
documentation and maintainable code.
---
### Granular bug/fix list:
- A lot of organs are overriding `Insert()` to apply unique
side-effects, but aren't checking the return value of the parent proc
which causes the activation of side-effects even if the insertion
technically fails. I noticed the use-case of applying "unique
side-effects" is repeated across a lot of organs in the game, and by
overriding `Insert()` the potential for bugs is very high; I solved this
problem with inversion-of-control by adding two new procs to
`/obj/item/organ` named `on_insert` and `on_remove`, each being called
after `Insert()` and `Remove()` succeed.
- Many organs, such as abductor "glands", cursed heart, demon heart,
alien hive-node, alien plasma-vessel, etc, were not returning their
parent's `Insert()` proc return value at all, and as a result those
organs `Insert()`s were always returning `null`. I have been mopping
those bugs up in my last few PRs, and now the unit test reveals it all.
Functions such as those in surgery expect a truthy value to be returned
from `Insert()` to represent insertion success, and otherwise it
force-moves the organ out of the mob.
- Fixed abductor "glands" which had a hard-del bug due to their
`Remove()` not calling the parent proc.
- Fixed cybernetic arm implants which had a hard-del bug due to
`Remove()` not resetting their `hand` variable to `null`.
- Fixed lungs gas exchange implementation, which was allowing exhaled
gases to feedback into the inhaled gases, which caused Humans to inhale
much more gas than intended and not exhale expected gases.
### Overview of the `organ_sanity` unit test:
- The new `organ_sanity` unit test gathers all "usable" organs in the
game and tests to see if their `Insert()` and `Remove()` functions
behave as we expect them to.
- Some organs, such as the Nightmare Brain, cause the mob's species to
change which subsequently swaps out all of their organs; the unit test
accounts for these organs via the typecache `species_changing_organs`.
- Some organs are not usable in-game and can't be unit tested, so the
unit test accounts for them via the typecache `test_organ_blacklist`.
### Overview of the `lungs_sanity` unit test:
- This unit test focuses on `/obj/item/organ/internal/lungs` including
Plasmaman and Ashwalker lungs. The test focuses on testing the lungs'
`check_breath()` proc.
- The tests are composed of calling `check_breath` with different gas
mixes to test breathing and suffocation.
- Includes gas exchange test for inhaled/exhaled gases, such as O2 to
CO2.
### Improvements to the `breath_sanity` unit tests:
- Added additional tests for suffocation with empty internals, pure
Nitrogen internals, and a gas-less turf.
- Includes slightly more reliable tests for internals tanks.
## Why It's Good For The Game
**Organs and Lungs were mostly untested. Too many refactors have been
submitted without the addition of unit tests to prove the code works at
all.** Time to stop. _Time to get some help_. Due to how bad the code
health is in organs, any time we've tried to work with them some sort of
bug caused them to blow up in our faces. I am trying to fix some of that
by establishing some standard testing for organs. These tests have
revealed and allowed me to fix lot of basic developer errors/oversights,
as well as a few severe bugs.
## Changelog
🆑 A.C.M.O.
fix: Fixed lungs gas exchange implementation, so you always inhale and
exhale the correct gases.
fix: Fixed a large quantity of hard-deletes which were being caused by
organs and cybernetic organs.
fix: Fixed many organs which were applying side-effects regardless of
whether or not the insertion failed.
code: Added unit tests for Organs.
code: Added unit tests for Lungs.
code: Improved unit tests for breathing.
code: Improved unit tests for DNA Infuser organs.
/🆑
On the tin, doing it like this means we can reduce our overall line
fingerprint whenever we have to add two or more traits from the same
source on the same target. Especially helps when we get to the 4+ range
of traits, a breath of fresh air even.
Doesn't mean we have to do for loops, as that's already handled within
the define as well. I replaced some of the checks with `length()`
checks, let me know if I should switch it over to something else (maybe
`islist()`)? We stack_trace whenever we're not passed a list reference
on purpose, and sometimes var/lists are null by default (or just empty,
making this redundant).
## Why It's Good For The Game
I commonly feel the urge to write "use `AddTraits()`" or something in
reviews, then am sad when I remember it doesn't exist. I will no longer
be sad.
Can ensure a lot more trait safety as well by using static lists- when
both ADD_TRAIT_LIST and REMOVE_TRAIT_LIST re-use the same list, you are
confident (from a static point of view) that everything that you want to
be adding/removing works.
I may have missed a few things where this could be used, but both macros
implemented in this PR still use the same framework that was being used
in the last four years- so stuff won't break if left untouched. Just a
nifty new tool for developers.
also fixed up some code in the area, numerous bugs were found and
exploded
## About The Pull Request
regenerate organs never removed invalid organs when regenerating
## Why It's Good For The Game
Fixes https://github.com/tgstation/tgstation/issues/73640
adds a unit test to prevent regressions in the future
## Changelog
🆑
fix: Plasmamen don't have hearts, again
/🆑
## About The Pull Request
Gives admins the ability to customize the spawn location of the cow and
the wisdom that it grants.
## Why It's Good For The Game
Wisdom cows lack any sort of customization at present, this allows
admins to set what type of wisdom which is granted which may be thematic
for events and adding positional spawn support for them is a pretty easy
addition.
## Changelog
🆑
admin: Admins can now customize the wisdom cow event.
/🆑
## About The Pull Request
fumbled around while investigating #74047 and turns out there's other
organs that have the same issue as the reported alien organs in that
issue. went around and replaced parent calls where applicable
(cursed/demonic hearts, flashlight eyes, alien organs, abductor glands)
## Why It's Good For The Game
Fixes#74047
Considerably less ghost internal organs, hopefully less unreported jank
on removing organs
## Changelog
🆑
fix: fixed a few internal organs acting wonky on inserting/removing
(some xenomorph organs, abductor glands, flashlight eyes, demon/cursed
hearts)
/🆑
## About The Pull Request
This updates Regal Rats to now check for a user's combat mode when
determining whether to lick or scratch a living target (Lick = combat
off, and Scratch = combat on). It also Closes#68621.
Additionally, it allows for player movement during the licking
interaction to properly cancel that action. Previously, it would attempt
a lick, the player would cancel it, and then the player would attack
their target instead (this was due to an oversight in the code).
Edit: It now also prevents NPC Regal rats from licking entirely, and
fixes their logic so that they move on to a new target after completing
a kill.
## Why It's Good For The Game
It allows players to control what their Regal rat does according to
their combat mode, which matches the behavior for other
player-controlled creatures (such as humans). Plus, this allows Regal
rats control over when to harm living creatures, making them much less
vulnerable than they were before.
Edit: As for NPC Regal rats, it allows them to be a bit more dangerous,
since they'll now only attack creatures that are alive. Moreover,
removing the ability to lick from NPCs helps avoid the strange scenario
where players could belong to a faction which is led by an NPC. (How can
one serve a King that lacks a sentient mind? Spacemen aren't ready for
that type of philosophical dilemma.)
## Changelog
🆑
fix: Player-controlled Regal Rats now lick or claw based on their combat
mode.
fix: NPC Regal rats now properly claw at enemies, moving on to new
targets after completing kills.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
There's a couple of open issues which fix places where only simple
animals were considered, but they are doing it piecemeal.
I decided to just go through every instance of `isanimal` or
`subtypesof(mob/living/simple_animal)` I could find, identify which
should also affect basic mobs, and fix them.
I left out the two others which are already in PR, I'm not stealing your
GBP.
Fixes https://github.com/tgstation/tgstation/issues/68881
## Why It's Good For The Game
Consistency, mostly.
As far as I can tell all of these things _should_ have effected basic
mobs, but didn't.
This fixes a fair number of bugs but also they're bugs that nobody
noticed or reported.
There are a couple of places I did not update which will need updating
in future. These are:
- Dextrousness checks, because basic mobs don't have that yet.
- The Charge cooldown action, because frankly I couldn't tell what it
was trying to do.
alright here goes
## Changelog
🆑
fix: Carp will once again be healed from being near carp rifts
fix: Sepia slime cores and the rewind camera now work on Ian
fix: Sapient ridden carp (or cows) can throw off their riders by shoving
them, or by performing the spin emote.
fix: Giant Spider AI will be disabled by the timestop spell
fix: Ian can eat envirochow
fix: Mice, Frogs, and Cockroaches will no longer set off bear traps
fix: You can put a macrobomb implant into Cayenne (or Ian)
fix: Ian will now recognise that being squeezed by a cyborg is a nice
hug
fix: The player panel will tell admins if you're currently a corgi
fix: The staff of storms deals massive damage to Bileworms and Giant
Spiders
fix: Ian will whimper if forced to scream
fix: Slimes can consume space carp
fix: Mice can be captured in xenoballs
fix: You can use pacifying potions on Giant Spiders
fix: Sgt Araneus can be fitted with a xenobiological radio implant
fix: Sapient corgis no longer count as living players for the purpose of
highlander escape objectives
fix: The random sentience event can now target corgis and sergeant
araneus
add: The random sentience event can target a wider array of farm animals
fix: Petsplosion wizard event can target corgis
add: Petsplosion wizard event will now target farm animals and
mothroaches
fix: The colossus possession crystal can now actually possess the
cockroach it spawns, does not kill you instantly upon ending possession
/🆑
## About The Pull Request
Unregisters status panel signal if the robot model item is deleting
## Why It's Good For The Game
Fixes#73594
## Changelog
🆑
fix: Borg synthesizers will no longer remain on the status panel if a
borg changes modules
/🆑
## About The Pull Request
If you planted a bomb as an explosive holopara it would do a stack_trace
cause it was using RegisterSignal instead of RegisterSignals
So, literally just changed RegisterSignal to RegisterSignals
## Why It's Good For The Game
Fixes#73854
## Changelog
🆑
fix: Explosive holoparasites no longer runtime if they plant bombs
/🆑
## About The Pull Request
Things like pens weren't giving any feedback messages when you put them
on someone else, and I ran into this while working on another PR so I've
dealt with that
Renames `worn_dangerous` to `show_visible_message` as it was only used
to confirm if there would be visible messages or not
The `DANGEROUS_OBJECT` clothing flag is a trait now, so it can be put on
non-clothing items too
Removing non-clothing items from someone has been unchanged.
## Why It's Good For The Game
People should be able to identify that someone is putting something on
them, and recognize what that is if they pay attention.
This means that a player cannot reverse pickpocket a grenade onto
someone else without giving any indication of doing so
## Changelog
🆑
balance: Putting a non-clothing item onto someone else creates a visible
message the same way a clothing item would.
/🆑
## About The Pull Request
Code changes:
- Fixes#73946 , Ice Slipping not going forever as intended
- Detailed in the issue report. Ice slide slip was replaced from a stun
to a knockdown, but it relied on it being a stun to function. I replaced
it back with an immobilize and incapacitate, reduced to 1 second to
prevent cheese.
- Refactors noslip mechanics
- Changes noslip and noslip_ice from a clothing flag to a clothing
trait, as the trait already existed and was used by MODsuits. Also added
noslip_slide, which prevents all sliding from slips like lube.
- Refactors magboots
- Refactored and modernized magboot code. Mostly cleanup, like using
base icon state, updating appearance, etc.
- Fixes speed potioned magboots not maintaining the speed boost after a
toggle
- Adds a helper for adding or removing clothing traits from existing,
(potentially) worn items.
- `TRAIT_NEGATE_GRAVITY` now always updates gravity on signal, no longer
requiring a manual call after.
Balance change:
- Magboots now prevent sliding on permafrost (outside icebox).
- This is mainly to give them more of a purpose on Icebox.
- Magboot snow prevent sliding on ice (or lube). You will still slip.
- Slipping over ice or lube will knock you down as before, but will not
send you across the room.
- See https://tgstation13.org/phpBB/viewtopic.php?t=33217.
## Why It's Good For The Game
Magboots justification:
This makes Magboots much less of a "noob trab" for engineers
fire-fighting in the Supermatter room. Most engineers believe themselves
to be completely save to the Supermatter's pull with magboots, however
"wet ice" will still send you flying into the crystal.
I think it is an inconsistency, seeing as it protects you from other
forms of forced movement like gravitational pulls. However making them
pure no-slip seemed a bit too far to me, so the knockdown still occurs.
## Changelog
🆑 Melbert
balance: Magboots will now protect you from sliding on ice. It will not
stop the slip, though.
fix: "Ice sliding" (from patches of permafrost ice) will now correctly
slide you until you reach a non-ice patch.
fix: Speed potioned magboots maintain their speed booster after toggling
them
refactor: Refactored magboots.
refactor: Refactored noslip mechanics.
/🆑
Internal_organs now also contains external organs, so the naming was
incorrect
Requested by @tralezab in #72734
Also removed some now incorrect 'as anythings' that assumed everything
in the internal_organs list was an internal_organ (which is a lie since
I put extorgans in there which means runtimes and unintentionakl
behaviour
🆑
fix: fixes deadly harvesting just taking harmless extorgans
code: renames internal_organs to organs now that it can also contain
external_organs
/🆑
## About The Pull Request
Slimepeople were not being affected by the blood deficiency quirk due to
having `TRAIT_NOBLOOD`:
0426f7ddba/code/datums/quirks/negative_quirks.dm (L73-L74)
Additionally, the rate at which slimes regenerate blood is not the same
as the rate for humans.
I added a new species var, `blood_deficiency_drain_rate`, to allow for
variable drain rates that can be customized on a species basis.
Currently the only species with varying regen rates seem to be
slimepeople and vampires. In the case of vampires, they already lost
blood over time but it will now just happen slightly faster.
One thing to note for posterity: as a side effect of this, slimes with
this trait will have a pretty impressive appetite due to this:
afe6ecc353/code/modules/mob/living/carbon/human/species_types/jellypeople.dm (L63-L66)
If you find some way to keep your blood volume higher than
`BLOOD_VOLUME_NORMAL` then you can prevent the nutrition loss entirely.
Easier said than done though! Could lead to some interesting
shenanigans.
Fixes https://github.com/Skyrat-SS13/Skyrat-tg/issues/15447
## Why It's Good For The Game
Fixes a quirk being broken for some species. Code changes to allow for
better handling of such cases as variable species blood regen rates in
the future.
## Changelog
🆑
fix: slimepeople and vampires are now affected by the blood deficiency
quirk
/🆑
## About The Pull Request
I'm a bit sad about the state of trashbags.
They're very clunky to use, so they almost never get touched. S
depressing. Let's try and fix that.
Let's make em fit in the belt slot (again), but as a tradeoff we'll make
it harder to pull one thing from your bag.
We'll give it a say, 1.5 second delay, so you can't quickdraw from em.
If you try and dump them out into something else, we'll throw any
spillover on the ground below you
I'm also doing some general code cleanup here. Making procs more
readable, vars more direct, removing some old legacy stuff.
I've added a remove_single proc to hook into via subtype, which takes a
mob as input. this has required placing extra requirement on some helper
procs, but fortunately it's not something they're unable to meet.
My hope is this will make garbage bags usable without being stupid.
## Why It's Good For The Game
I don't see these get used at all, cause they're a pain to carry around.
They got gimped because people were using them as infinite storage for
shotgun shells and other small items.
I've made using them for this sort of thing hard and slow, so I think we
oughta be fine. If not I'll do some more touching, maybe give the
autodrop a delay.
## Changelog
🆑
balance: The janitor's trashbag now fits on his belt. In exchange,
taking something out of it sends a visible message, and has a delay.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
These changes re-implement the functionality for Physical and Mental
Statuses, which used to be present in Medical Records (visible via
medical filing cabinents, medical records consoles, and MED-HUDs). These
Physical/Mental statuses can once again be updated through examining a
crewmember (while wearing a Med-HUD), or through the new TGUI interface
for medical records consoles.
## Why It's Good For The Game
Primarily, this resolves the bugs mentioned in [Issue
#73477](https://github.com/tgstation/tgstation/issues/73477), and
restores functionality which appears to have been accidentally removed
via [PR #72725](https://github.com/tgstation/tgstation/pull/72725).
Additionally, the re-implementation of these statuses allows for more
in-depth medical RP (and bureaucracy), especially in regards to the
Psychiatrist role and managing crewmember sanity.
## Changelog
🆑
fix: Re-implements physical and mental statuses in crewmember medical
records.
fix: Re-implements changing a crewmember's physical/mental status via a
Med-HUD.
/🆑
Edit: Image of the new TGUI buttons which now handle Physical/Mental
statuses.
Closes#73477
## About The Pull Request
Hate having your cables eaten by mice? Nanotrasen have heard your
complaints and settled on a natural, _organic_, and eco-friendly
solution.
When this station trait is active, roundstart and event mouse spawns
have a chance to instead be replaced with duct spiders (both will exist,
it doesn't remove mice).
Duct spiders are largely harmless to humans, actively hunt other
maintenance creatures (such as mice), and have only one _tiny_ downside.
These mobs can also sometimes be spawned by a minor scrubber clog event.
As a side note, all spider basic mobs with AI (except Araneus) will now
try to automatically fill a small area around them with webs.
Also I made it so that mobs will ignore their random_walking behaviour
if they're engaged in a `do_after`, just in case.
## Why It's Good For The Game
Adds a little bit of variety to things which can slightly annoy you in
maintenance.
Spiders will automatically make places they live in look like spiders
live there.
## Changelog
🆑
add: A station trait which sometimes populates maintenance with small
spiders. You can wear them as a hat if you wanted to have a spider on
your head for some reason.
add: Spider mobs will automatically start webbing up their environment.
/🆑
## About The Pull Request
- Juggernaut and Rust Walker projectiles were subtyped off of magic,
which is `nodamage`.
- The juggernaut actually had a copy+paste error with their type
`on_hit` which caused none of their special effects on hit ("relative
patching catches this")
- Then I realized projectiles have this var `nodamage` which is, for all
intents and purposes, just `damage > 0`. it's not checked for pacifism,
it's just that. This is dumb. So very dumb, so I removed it.
- There are, however, a few situations which used it in a unique way,
such as the blast wave cannon. This is why I replaced it with a proc,
`is_hostile_projectile`, for certain situations to actually find out if
the projectile is damaging. Projectiles can override this on a per type
basis by default, damaging projectiles = hostile.
- This has a chance to break some things, but I ... kinda doubt it will.
Fixes#73756
## Why It's Good For The Game
Projectiles that act as they should, less dumb vars
## Changelog
🆑 Melbert
fix: Fixes Juggernaut / Rust Walker projectiles doing zero damage
fix: Fixes Juggernaut projectiles not doing bonus damage to nearby
structures
code: Removed projectile nodamage var, replaces it with just checking
for damage
/🆑
## About The Pull Request
The gist is that people thought that this was a boolean value, which was
fucked up. It's not a boolean value, it accepts anything between 0 and
2. So, let's re-arrange the checks and framework, give it some
descriptive defines, just so people know what the fuck "2" actually
does. `DOOR_DEFAULT_CHECKS` (0) does stuff normally,
`DOOR_FORCED_CHECKS` 1 typically just checking if we aren't emagged shut
or something (i suppose it could happen), and `DOOR_BYPASS_CHECKS` (2)
means that we just get the fucking door open if it isn't physically
sealed shut/open somehow.
I don't know if `forced` has ever _been_ a boolean, but for some reason
people thought it was.
I also enforced boolean returns instead of passing back null. This did
not matter for close() but i think it's silly to have a TRUE/null
dichotomy so that was also touched up.
## Why It's Good For The Game
Much better to read, less confusing, less stupid. It's been irritating
me for a while now, so let's just implement it now. Had to make a few
awkward concessions in order to fit this into the current code
framework, but it should be a lot nicer. I also shuffled the order of
some code around because certain placements didn't make any sense (early
returns not being in the right spot for an early return).
## Changelog
Nothing that should concern players.
## About The Pull Request
Might be a bit low, but part of that is because it's kinda bad at
figuring color, rgb isn't really balanced in that respect
Fixes not being able to see stuff under the light of a lamp
Overlay lights don't set lumen, which leads to stupid when you try and
check with ONLY it
It worked before because the mob has THEIR luminosity set, which then
"glowed" out
That doesn't work here cause yaknow I removed our uses of byond lighting
(except for errant view() calls) so this is the best I've got
## Why It's Good For The Game
Closes#73548
## Changelog
🆑
fix: Examining in the dark is less wonk now, sorry bout that
/🆑
## About The Pull Request
Lost feature when they were moved to basic mob
## Why It's Good For The Game
The intended feature is now back again !
## Changelog
🆑
fix: Corgis show their ID on examine.
/🆑
## About The Pull Request
- Add Component was supposed to use a named arg, quick fix
- While testing the fix I noticed it doesn't properly remove the
appearance when the item is lost, cuts the overlay on failures
## Why It's Good For The Game
Mothblox said this broke things (it was making a weakref of a callback
on accident)
## Changelog
🆑 Melbert
fix: Luminsecent slime actions correctly update their appearance when
integrating or ejecting slime cores
/🆑
## About The Pull Request
Fixes https://github.com/tgstation/tgstation/issues/73765
Also adds some warnings and description to bread/breadslice so you can
more easily notice that something is wrong.
Not much to discuss i think.
## Why It's Good For The Game
You can get normal bread from butchering bread dog. And potentially less
issues with bread in future.
## Changelog
🆑
fix: fixed butchering bread dog spawning error bread.
/🆑
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
Refactored how eggs growing into chicks is implemented, and
how the number of chickens and chicks are tracked. It's now possible for
admins to make anything into an egg.
- Instead of the "fertility" of an egg being whether or not it's
processing (along with the ugliness of adding a variable to a item
defined in another file), fertile eggs are now implemented via
components.
- The number of chickens in the world, and the number of chicks hatched
from egg throwing are now global variables, rather than static variables
on the class.
I've tried very hard to keep these changes completely feature freeze
compatible, any variation in the old behaviour is non-intended (at this
point).
## About The Pull Request
Okay, I had fun with the alert system. Simply, this just adds 2 meat to
the butcher completion of regal rats. It's a pretty low amount of meat
considering that they look like this.
I chose a low number for the meat considering that players will still be
able to get a massive influx of meat from butchering the small rats.
## Why It's Good For The Game
Regal Rats are often dragged to the kitchen immediately upon being
killed, leaving confused chefs/assistants wondering why they only
received a crown upon successful butchering. Hopefully, this change will
leave people less baffled by the lack of meatiness from the huge
creatures.
## Changelog
🆑
qol: Regal Rats produce meat on butchering, reducing player confusion.
/🆑
