* No roundstart playable MULEs / Trampling requires hacking (#76837)
## About The Pull Request
Prevailing feedback has been:
- The player base cannot be trusted to control MULEbots.
- It should be clearer what bots can and can't do.
The former is easy to fix.
The latter is sort of a matter for policy but I'm going to investigate
giving bots a rudimentary laws system. Plus that sounds much more
controversial than this so I am going to atomise this outside of that
PR.
MULEbots can still be set to allow sentience by cargo technicians, but
don't start that way.
ADDITIONALLY this PR just changes it so that MULEbots do not crush
people unless:
- They have been emagged.
- Their safety wire has been cut.
Either means works, so it's not too hard to access for nefarious
purposes, but hard to do to yourself.
Otherwise they just slow down for a few seconds instead.
Also fixed an unrelated name bug while I was there.
Closes#76926
## Why It's Good For The Game
Players would take them, not deliver any cargo, and repeatedly ask
people to lie down in front of them.
Plus Tram has 5 of the things which is frankly too many to be wandering
around the bar.
## Changelog
🆑
balance: You can't possess a MULE as soon as the round starts, someone
will have to give you permission.
balance: MULEbots no longer crush prone characters unless they have been
hacked (or emagged).
fix: Bots can put numbers in their names, what with being robots.
admin: Adds attack logging when certain wires are cut (for instance:
MULEbot safeties)
/🆑
* No roundstart playable MULEs / Trampling requires hacking
* add missing arg
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
Co-authored-by: Pinta <68373373+softcerv@users.noreply.github.com>
Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com>
* Add healing boost to organs while mob is sleeping (#76679)
## About The Pull Request
This adds the healing bonuses from sleeping effects (mood, pillow,
sleeping in darkness, etc.) and applies it to organs natural healing
regeneration. The regen rate is very low, so I added a heavy x5
multiplication rate to all the sleep bonuses for organs specifically.
If an organ is dying or robotic then the effects don't apply.
## Why It's Good For The Game
More benefits to sleeping after injuries. This encourages patients to
rest properly after revival or major surgery.
## Changelog
🆑
add: Add healing boost to organs while mob is sleeping (does not apply
to robotic or dying organs)
/🆑
* Add healing boost to organs while mob is sleeping
---------
Co-authored-by: Tim <timothymtorres@gmail.com>
Co-authored-by: Bloop <vinylspiders@gmail.com>
* Refactors mind language holders into non-existent, fixes new languages being deleted on species swap + tests
* Fixing merge conflicts
* don't forget to ctrl+s!
* Another forgotten file
* urgh
* gets rid of vestiges of update_atom_languages()
and mind language holders
* No longer needed
* Fixes some modular grant_language calls
* Deprecated code
* This was up here before..
* Fixes failing unit tests, refactors silverscale lizards language a bit removing the need for skyrat edits
Removes some no longer needed code
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: Pinta <68373373+softcerv@users.noreply.github.com>
Co-authored-by: Giz <vinylspiders@gmail.com>
* Fix Too Slowing people with high fives (#76277)
## About The Pull Request
At some point with the refactors to offering it was made so that
dropping the item stops the offer, unfortunately too slowing people with
high fives relied on this behavior (dropping not stopping the offer).
Restores that behavior with a bit more code tweaking.
## Why It's Good For The Game
How can I be too slow?
## Changelog
🆑 Melbert
fix: You can once again "too slow" someone with a high five
/🆑
* Fix Too Slowing people with high fives
* d'oh!
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: Pinta <68373373+softcerv@users.noreply.github.com>
* [s] Knocks the lights out of Tinea Luxor (#76295)
## About The Pull Request
So, we've a problem where the lights from Tinea Luxor can be staked up
indefinitely, because someone thought it was a brilliant idea to use
expose_mob rather than on_mob_metabolize.
## Why It's Good For The Game
This will close#76263. Aaaand yes, this is a webedit PR.
## Changelog
🆑
fix: Fixes the lights from Tinea Luxor being stackable to the point of
crashing the game for others.
/🆑
* [s] Knocks the lights out of Tinea Luxor
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
* Lighting object oddities (#76009)
## About The Pull Request
Fire stacks status effect no longer uses a weakref for the mob light, I
am pretty sure there was no real reason to use a weakref there.
Deleted weird luminescent glow dummy, now it just uses the standard
moblight obj.
Put all /obj/effect/dummy/lighting_obj together in a single file and
added a comment explaining why they exist.
(I severely dislike the /obj/effect/dummy typepath, but I am very much
unsure if just replacing all of them with /obj/effect/abstract would
break shit)
## Why It's Good For The Game
Code organization good
* Lighting object oddities
* Update kindle.dm
---------
Co-authored-by: ChungusGamer666 <82850673+ChungusGamer666@users.noreply.github.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
* Refactors the worst list ever, Stun Absorptions, into status effects + makes status flags more accurate (making certain mobs more vulnerable to incapacitations?) (#76000)
## About The Pull Request
- Refactors the stun absorption list into a status effect
- Does a fair bit of cleanup around stun code
Weird thing involved in this.
Check out this define.
`IS_STUN_IMMUNE(source, ignore_canstun) ((source.status_flags & GODMODE)
|| (!ignore_canstun && (!(source.status_flags & CANKNOCKDOWN) ||
HAS_TRAIT(source, TRAIT_STUNIMMUNE))))`
Notice anything odd about it?
It only checks for `CANKNOCKDOWN`.
What does this mean?
Well, *every single* one of the stun procs used this macro for checking
stun immunity. Which means every method of stun checked the
`CANKNOCKDOWN`.
This means that, say you have a mob which has `CANSTUN` but not
`CANKNOCKDOWN`.
Intuitively this means that the mob cannot be knocked down, but can be
stunned.
But instead, this means the mob can't be stunned either.
This doesn't affect humans, they have all the status flags, but it does
affect some other mobs.
Alien adults (not queens) have `CANUNCONSCIOUS|CANPUSH`. Before, they
didn't have `CANKNOCKDOWN`, so they were fully immune to stuns and
sleeps. But now, they can be knocked unconscious.
However, overall it doesn't change much, as most mobs that flipped off
`CANKNOCKDOWN` flipped off the others too.
For consistency though it makes sense for these flags to work as they
imply.
- `incapacitate` didn't have a signal, now it does
## Why It's Good For The Game
More consistent, better code? I may use this in the future.
## Changelog
🆑 Melbert
refactor: Refactored Stun Absorptions (Bastard Sword, His Grace)
refactor: Refactored Stun Immunity. Note this means that some mobs
which, prior, were immune to all forms of incapacitation are now
vulnerable to some. Notably, adult non-queen xenomorphs are now
vulnerable to falling unconscious.
/🆑
* Refactors the worst list ever, Stun Absorptions, into status effects + makes status flags more accurate (making certain mobs more vulnerable to incapacitations?)
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Stops particle holders from appearing on context menu (#76006)
## About The Pull Request
Basically, due to carbons using KEEP_TOGETHER, particles were appearing
on the context menu which is annoying. I have no idea why it behaves
like this.
Buuut, giving particle holders the KEEP_APART flag does fix this.
closes https://github.com/tgstation/tgstation/issues/75641
## Why It's Good For The Game
Bugfix good
## Changelog
no
* Stops particle holders from appearing on context menu
---------
Co-authored-by: ChungusGamer666 <82850673+ChungusGamer666@users.noreply.github.com>
* The destabilization of your eigenstate can no longer be paused by stripping naked (#75982)
## About The Pull Request
The destabilization of your eigenstate can no longer be paused by
stripping naked.
## Why It's Good For The Game
one of the stages of the eigenstasium od's status effect is causing your
items to teleport off of you
this early returned out if you had no items to teleport off of yourself
and it did this before the line of code that increments the status
effect's progress counter
so if you had no items to teleport, you'd never progress to the later
stages of the status effect
## Changelog
🆑 ATHATH
fix: The destabilization of your eigenstate can no longer be paused by
stripping naked.
/🆑
* The destabilization of your eigenstate can no longer be paused by stripping naked
---------
Co-authored-by: ATH1909 <42606352+ATH1909@users.noreply.github.com>
* Fixes mind traits (Curator, Miner, Clown) (#75593)
## About The Pull Request
Tower of Babel (Curator), Naive (Clown), and Storm detector (Shaft
Miner), are all traits that are given to your mind upon taking these
jobs.
However, we have been checking the body for these traits, not the mind.
This meant that Shaft miners werent alerted of ice storms, Clowns didnt
have their unique examine text, and Curators were affected by Tower of
Babel.
This fixes all those issues.
Naive and Tower of Babel realistically should only be on the mind, so I
changed all instances to check the mind. Storm detection is something
you can get through analyzers, so I left it as a check for both your
body and mind traits.
Clown's Naive:
Tower of Babel:
## Why It's Good For The Game
Fixes several bugs for 3 jobs all at once. I don't see any issue reports
on any of these, but they existed.
## Changelog
🆑
fix: Shaft Miners are now alerted of Icemoon storms, Clowns are naive,
and Curators are immune to the Tower of Babel again.
/🆑
* Fixes mind traits (Curator, Miner, Clown)
---------
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
* Drunk slurring scales based on how drunk you are (#75459)
## About The Pull Request
The strength of the slurring effect drunkness applies on you now scales
based on how drunk you are.
Being "a little" drunk still changes your saymod, and makes you
occasionally slur your words...
But being "a lot" drunk kicks it up to 11
Additionally, drunk slurring was separated into "generic slurring" and
"drunk slurring", the former which does not scale but less closely
resembles drunkness. Generic slurring is used in places such as
concussions, so this is an added bonus.
As a result of the split, I had to update mind restoration. Now it heals
all types of slurring, which does include cult slurs.
## Why It's Good For The Game
I, and many other people, always found it very annoying when you became
completely illegible from taking one sip of a drink. This seeks to amend
that by making low levels of drunkness still for the most part be
legible and sane. Average drunkness is roughly the same / equal to the
old slurring effect, while "very drunk" is even more illegible and silly
(which I find funny).
This has the added bonus of separating out "drunk slurring" and "generic
slurring", allowing effects to slur your words without going full ham on
drunkness (burping and "huhh"s).
## Changelog
🆑 Melbert
add: When you are drunk, the strength of your slurring now varies based
on how drunk you are. Being "a little drunk" only rarely slurs your
words, being average drunk is the same as the old effect, while being
very drunk now slurs your words even more.
add: Some non-alcohol sources of slurring, such as concussions, now give
"generic slurring" rather than "drunk slurring", which less resemble
being drunk (ie, no burping).
add: Mind restoration now heals ALL slurring, rather than only drunk
slurring (which includes cult / heretic slurring).
/🆑
* Drunk slurring scales based on how drunk you are
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Makes genetic damage gorillas work (#75398)
## About The Pull Request
Moves the genetic damage status effect's `qdel()` after making the
status effect's owner a gorilla.
Basically un-fucks the interaction, as it was accidentally fucked in
#74799, see
https://github.com/tgstation/tgstation/issues/74981#issuecomment-1546140751
## Why It's Good For The Game
Fixes#74981
## Changelog
🆑
fix: made gorilla transformation when affected by excess amounts of
genetic damage work
/🆑
* Makes genetic damage gorillas work
---------
Co-authored-by: Sealed101 <cool.bullseye@yandex.ru>
* Refactors genetic damage component to be a status effect (#74799)
## About The Pull Request
The genetic damage component looked like a status effect, swam like a
status effect, quacked like a status effect, but wasn't a status effect.
Irradiated component is also guilty of this, but it has the excuse of
also getting applied to items. This one only applies to mobs though,
so...
## Why It's Good For The Game
Easier to maintain code, that's about it.
## Changelog
Not player facing.
* Refactors genetic damage component to be a status effect
---------
Co-authored-by: ChungusGamer666 <82850673+ChungusGamer666@users.noreply.github.com>
* Optimizes particle holders (#74524)
## About The Pull Request
It isn't really an issue now, but these will be used more in future, so
let's start off strong.
There's a lot of work going on here that doesn't really need to be
happening, mostly off not knowing a trickTM.
Biggest one is vis_locs and vis_contents are linked lists, being in one
requires being in another. Atoms clear out their vis_locs on Destroy, so
we do not need to "own" references to things that have us in their
vis_contents.
This combined with knowing our old loc's loc off Moved made the use of
weakrefs here unneeded. Similarly, atoms inside atom movables qdel on
when the upper layer is deleted, so most cases of the qdeleting signal
were unneeded.
Also, we only cared about movement if we were an item (speaking of
which, I swapped out the isitem stuff with a flag that gets passed into
the new() call)
## Why It's Good For The Game
Speed
* Optimizes particle holders
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* [no gbp] Simple animals can't catch on fire (#74736)
## About The Pull Request
Fixes#74633FIxes#74739
I probably broke this when I refactored spiders and it became apparent
because someone added particles to it.
Simple animals didn't really do anything as a result of being on fire
except perhaps invisibly pass it on to other people, but it was wasteful
to apply the status effect.
## Why It's Good For The Game
No mostly-invisible fire hazards.
## Changelog
🆑
fix: Renault and other simple animals are now correctly fireproof.
/🆑
* [no gbp] Simple animals can't catch on fire
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
* Adds pillow bonus for sleeping. (#74349)
## About The Pull Request
There is bedsheet bonus, but no pillow bonus.
## Why It's Good For The Game
Healthy sleep.
## Changelog
🆑
add: Sleeping with a pillow restores more health.
/🆑
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@ users.noreply.github.com>
* Adds pillow bonus for sleeping.
---------
Co-authored-by: Helg2 <93882977+Helg2@users.noreply.github.com>
Co-authored-by: MrMelbert <51863163+MrMelbert@ users.noreply.github.com>
* Minor typo fixes (#74317)
## About The Why It's Good For The Game Pull Request
Immersion
## Changelog
🆑 Tattle
spellcheck: fixed a few typos, mostly around breathing
/🆑
Co-authored-by: tattle <article.disaster@ gmail.com>
* Minor typo fixes
---------
Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com>
Co-authored-by: tattle <article.disaster@ gmail.com>
* Nightvision Rework (In the name of color) (#73094)
Relies on #72886 for some render relay expansion I use for light_mask
stuff.
Hello bestie! Night vision pissed me off, so I've come to burn this
place to the ground.
Two sections to discuss here. First we'll talk about see_in_dark and why
I hate it, second we'll discuss the lighting plane and how we brighten
it, plus introducing color to the party.
https://www.byond.com/docs/ref/#/mob/var/see_in_dark
See in dark lets us control how far away from us a turf can be before we
hide it/its contents if it's dark (not got luminosity set)
We currently set it semi inconsistently to provide nightvision to mobs.
The trouble is stuff that produces light != stuff that sets luminosity.
The worst case of this can be seen by walking out of escape on icebox,
where you'll see this
Snow draws above the lighting plane, so the snow will intermittently
draw, depending on see_in_dark and the luminosity from tracking lights.
This would in theory be solvable by modifying the area, but the same
problem applies across many things in the codebase.
As things currently stand, to be emissive you NEED to have a light on
your tile. People are bad at this, and honestly it's a bit much to
expect of them. An emissive overlay on a canister shouldn't need an
element or something and a list on turfs to manage it.
This gets worse when you factor in the patterns I'm using to avoid
drawing lights above nothing, which leads to lights that should show,
but are misoffset because their parent pixel offsets.
It's silly. We do it so we can have things like mesons without just
handing out night vision, but even there the effect of just hiding
objects and mobs looks baddddddd when moving. It's always bothered me.
I'll complain about mesons more later, but really just like, they're too
bright as it is.
I'm proposing here that rather then manually hiding stuff based off
distance from the player, we can instead show/hide using just the
lighting plane. This means things like mesons are gonna get dimmer, but
that's fine because they suck.
It does have some side effects, things like view() on mobs won't hide
stuff in darkness, but that's fine because none actually thinks about
view like that, I think.
Oh and I added a case to prevent examining stuff that's in darkness, and
not right next to you when you don't have enough nightvision, to match
the old behavior `see_in_dark` gave us.
Now I'd like to go on a mild tangent about color, please bare with me
You ever walk around with mesons on when there's a fire going, or an
ethereal or firelocks down.
You notice how there isn't really much color to our lights? Doesn't that
suck?
It's because the way we go about brighting lighting is by making
everything on the lighting plane transparent.
This is fine for brightening things, but it ends up looking kinda crummy
in the end and leads to really washed out colors that should be bright.
Playing engineer or miner gets fucking depressing.
The central idea of this pr, that everything else falls out of, is
instead of making the plane more transparent, we can use color matrixes
to make things AT LEAST x bright.
https://www.byond.com/docs/ref/#/{notes}/color-matrix
Brief recap for color matrixes, fully expanded they're a set of 20
different values in a list
Units generally scale 0-1 as multipliers, though since it's
multiplication in order to make an rgb(1,1,1) pixel fullbright you would
need to use 255s.
A "unit matrix" for color looks like this:
```
list(1, 0, 0, 0,
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1,
0, 0, 0, 0
)
```
The first four rows are how much each r, g, b and a impact r, g, b and
well a.
So a first row of `(1, 0, 0, 0)` means 1 unit of r results in 1 unit of
r. and 0 units of green, blue and alpha, and so on.
A first row of `(0, 1, 0, 0)` would make 1 red component into 1 green
component, and leave red, blue and alpha alone, shifting any red of
whatever it's applied to a green.
Using these we can essentially color transform our world. It's a fun
tool. But there's more.
That last row there doesn't take a variable input like the others.
Instead, it ADDS some fraction of 255 to red, green, blue and alpha.
So a fifth row of `(1, 0, 0, 0)` would make every pixel as red as it
could possibly be.
This is what we're going to exploit here. You see all these values
accept negative multipliers, so we can lower colors down instead of
raising them up!
The key idea is using color matrix filters
https://www.byond.com/docs/ref/#/{notes}/filters/color to chain these
operations together.
Pulling alllll the way back, we want to brighten darkness without
affecting brighter colors.
Lower rgb values are darker, higher ones are brighter. This relationship
isn't really linear because of suffering reasons, but it's good enough
for this.
Let's try chaining some matrixes on the lighting plane, which is bright
where fullbright, and dark where dark.
Take a list like this
```
list(1, 0, 0, 0,
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1,
-0.2, -0.2, -0.2, 0
)
```
That would darken the lighting a bit, but negative values will get
rounded to 0
A subsequent raising by the same amount
```
list(1, 0, 0, 0,
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1,
0.2, 0.2, 0.2, 0
)
```
Will essentially threshold our brightness at that value.
This ensures we aren't washing out colors when we make things brighter,
while leaving higher values unaffected since they basically just had a
constant subtracted and then readded.
You may have noticed, we gain access to individual color components
here.
This means not only can we darken and lighten by thresholds, we can
COLOR those thresholds.
```
list(1, 0, 0, 0,
0, 1, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1,
0.1, 0.2, 0.1, 0
)
```
Something like the above, if applied with its inverse, would tint the
darkness green.
The delta between the different scalars will determine how vivid the
color is, and the actual value will impact the brightness.
Something that's always bothered me about nightvision is it's just
greyscale for the most part, there isn't any color to it.
There was an old idea of coloring the game plane to match their lenses,
but if you've ever played with the colorblind quirk you know that gets
headachey really fast.
So instead of that, lets color just the darkness that these glasses
produce.
It provides some reminder that you're wearing them, instead of just
being something you forget about while playing, and provides a reason to
use flashlights and such since they can give you a clearer, less tinted
view of things while retaining the ability to look around things.
I've so far applied this pattern to JUST headwear for humans (also those
mining wisps)
I'm planning on furthering it to mobs that use nightvision, but I wanted
to get this up cause I don't wanna pr it the day before the freeze.
Mesons are green, sec night vision is red, thermals orange, etc.
I think the effect this gives is really really nice.
I've tuned most things to work for the station, though mesons works for
lavaland for obvious reasons.
I've tuned things significantly darker then we have them set currently,
since I really hate flat lighting and this system suffers when
interacting with it.
My goal with these is to give you a rough idea of what's around you,
without a good eye for detail.
That's the difference between say, mesons, and night vision. One helps
you see outlines, the other gives you detail and prevents missing
someone in the darkness.
It's hard to balance this precisely because of different colored
backgrounds (looking at you icebox)
More can be done on this front in future but I'm quite happy with things
as of now
I have since expanded to all uses of nightvision, coloring most all of
them.
Along the way I turned some toggleable nightvision into just one level.
Fullbright sucks, and I'd rather just have one "good" value.
I've kept it for a few cases, mostly eyes you rip out of mobs.
Impacted mobs are nightmares, aliens, zombies, revenants, states and
sort of stands.
I've done a pass on all mobs and items that impact nightvision and added
what I thought was the right level of color to them. This includes stuff
like blobs and shuttle control consoles
As with glasses much of this was around reducing vision, though I kept
it stronger here, since many of these mobs rely on it for engaging with
the game
<details>
<summary>
Technical Changes
</summary>
filter transitions.
Found this when testing this pr, seemed silly.
This avoids dumbass overlay lighting lighting up wallmounts.
We switch modes if some turfflags are set, to accomplish the same thing
with more overhead, and support showing things through the darkness.
Also fixes a bug where you'd only get one fullscreen object per mob, so
opening and closing a submap would take it away
Also also fixes the lighting backdrop not actually spanning the screen.
It doesn't actually do anything anymore because of the fullscreen light
we have, but just in case that's unsued.
Needs cleanup in future.
color with a sprite
This is to support the above
We relay this plane to lighting mask so openspace can like, have
lighting
vision goggles and such
Side affect of removing see_in_dark. This logic is a bit weak atm, needs
some work.
It's a dupe of the nightvision action button, and newly redundant since
I've removed all uses of it
trasnparent won't render
These sucked
Also transparent stuff should never render, if it does you'll get white
blobs which suck
</details>
Videos! (Github doesn't like using a summary here I'm sorry)
<details>
Demonstration of ghost lighting, and color
https://user-images.githubusercontent.com/58055496/215693983-99e00f9e-7214-4cf4-a76a-6e669a8a1103.mp4
Engi-glass mesons and walking in maint (Potentially overtuned, yellow is
hard)
https://user-images.githubusercontent.com/58055496/215695978-26e7dc45-28aa-4285-ae95-62ea3d79860f.mp4
Diagnostic nightvision goggles and see_in_dark not hiding emissives
https://user-images.githubusercontent.com/58055496/215692233-115b4094-1099-4393-9e94-db2088d834f3.mp4
Sec nightvision (I just think it looks neat)
https://user-images.githubusercontent.com/58055496/215692269-bc08335e-0223-49c3-9faf-d2d7b22fe2d2.mp4
Medical nightvision goggles and other colors
https://user-images.githubusercontent.com/58055496/215692286-0ba3de6a-b1d5-4aed-a6eb-c32794ea45da.mp4
Miner mesons and mobs hiding in lavaland (This is basically the darkest
possible environment)
https://user-images.githubusercontent.com/58055496/215696327-26958b69-0e1c-4412-9298-4e9e68b3df68.mp4
Thermal goggles and coloring displayed mobs
https://user-images.githubusercontent.com/58055496/215692710-d2b101f3-7922-498c-918c-9b528d181430.mp4
</details>
I think it's pretty, and see_in_dark sucks butt.
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and it's effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
add: The darkness that glasses and hud goggles that impact your
nightvision (think mesons, nightvision goggles, etc) lighten is now
tinted to match the glasses. S pretty IMO, and hopefully it helps with
forgetting you're wearing X.
balance: Nightvision is darker. I think bright looks bad, and things
like mesons do way too much
balance: Mesons (and mobs in general) no longer have a static distance
you can see stuff in the dark. If a tile is lit, you can now see it.
fix: Nightvision no longer dims colored lights, instead simply
thresholding off bits of darkness that are dimmer then some level.
/🆑
* modular edits
* see_in_dark
* [MIRROR] Adds a unit test to detect double stacked lights [MDB IGNORE] (#19564)
* Adds a unit test to detect double stacked lights
* we really need to get that night vision pr done
* lints fixes
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Paxilmaniac <paxilmaniac@gmail.com>
* Update augments_eyes.dm
* Update augments_eyes.dm
* eeee
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: SkyratBot <59378654+SkyratBot@users.noreply.github.com>
Co-authored-by: Paxilmaniac <paxilmaniac@gmail.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
* Makes arms regrown by the Rod of Asclepius the correct color (#73152)
## About The Pull Request
When an arm holding an activated Rod of Asclepius is cut off, the arm
grows back with the rod held in it. However, due to an oversight, the
arm that grows back is always the "default" color - the albino skintone
for humans/felinids, and grey for everyone else. This PR makes the
regenerated arm have the proper skintone instead.
## Why It's Good For The Game
There's no good reason that a magical doctoring rod should drain all
color from your arm, probably.
## Changelog
🆑
fix: Corrected the skintone on arms grown back by the Rod of Asclepius
/🆑
* Makes arms regrown by the Rod of Asclepius the correct color
---------
Co-authored-by: lizardqueenlexi <105025397+lizardqueenlexi@users.noreply.github.com>
* STAY IN THE LIGHT: Adds terrify Nightmare spell, terrified status effect, and a reason to mind the shadows (#72282)
Adds the Terrify spell, and its associated status effect, Terrified.
This new spell is given to antagonist nightmares, as a part of their
brain. The spell only works in those surrounded by darkness, and will
apply the Terrified status effect if successful. Upon being Terrified,
victims will passively gain **Terror Buildup** if they remain in the
dark. As buildup increases, so do the negative effects, including tunnel
vision, panic attacks, dizziness, and more.
There are two primary methods for mitigating terror buildup. The first
is moving into the light, which will reverse the passive terror buildup
and eventually make it go away. The other method is by getting a hug
from a friendly hand, which will reduce buildup significantly.
Getting a hug from an UNfriendly hand (a nightmare, for instance) will
cause the victim to freak out and be briefly knocked down. This can be
spammed on targets who are caught alone in the dark, keeping them in an
unfavorable position (sideways) and adding to the victim's terror
buildup considerably. Escape into the light as soon as possible, or
you'll be pushed to MAXIMUM TERROR BUILDUP.
To what end? Heart failure. Past the soft terror cap (which limits how
much passively generated terror you can make) exists the hard terror
cap. Bypassing that threshold will cause a stress induced heart attack
and knock you unconscious (embarrassing!)
* STAY IN THE LIGHT: Adds terrify Nightmare spell, terrified status effect, and a reason to mind the shadows
---------
Co-authored-by: Rhials <Datguy33456@gmail.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* Converts blindness and nearsightedness to status effects, scratches some VERY dumb blindness handling that resulted in mobs becoming "incurably" blind
* Fixes the conflicts and makes shit compile!
* Fixes other things that didn't show up because I hadn't updated
* Fixes the lints.
* Okay NOW it's ready (please don't add anything else that touches blindness I beg you)
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* Fixes an edge case where you can get incurable plasma damage, & fixes healing sources that don't have biotype restrictions not working if the mob doesn't have the MOB_ORGANIC biotype (#73017)
## About The Pull Request
Fixes#72962
The plasma river applies toxins damage to a mob as it transforms
individual limbs into plasmaman ones.
Once all limbs have been transformed, the mob's species changes to
plasmaman.
This currently leads to incurable toxin damage as antitoxin drugs do not
work on plasmamen. Made it so that upon transforming fully, the toxin
damage is cleared.
Also fixed an issue where healing sources that do not have a
required_biotype parameter (e.g. `adjustToxLoss(-5)` vs
`adjustToxLoss(-5, required biotype=whatever)`) will not work on mobs
that do not have the `MOB_ORGANIC` biotype (e.g. plasmamen) due to it
defaulting to `MOB_ORGANIC`. For now those use the `forced` param to
accomplish this.
## Why It's Good For The Game
Incurable damage is no good.
## Changelog
🆑
fix: fixed getting incurable tox damage when fully transformed into a
plasmaman via plasma rivers
fix: fixed rod of asclepius/medibeam etc not being able to heal tox
damage despite not having biotype restrictions
/🆑
* Fixes an edge case where you can get incurable plasma damage, & fixes healing sources that don't have biotype restrictions not working if the mob doesn't have the MOB_ORGANIC biotype
---------
Co-authored-by: Bloop <vinylspiders@gmail.com>
Being wet no longer causes you to be EXTRA flammable (#72843)
Being wet no longer causes you to be even more flammable, and instead
properly lets you dry up instead of catching on fire even faster when
receiving fire stacks.
What caused this was that there was some double-negatives happening,
which meant that both fire and wet stacks would be increased together
when both were present at once, rather than both being reduced and one
of the two cancelling out the other.
Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com>
* Refactors memories to be less painful to add and apply, moves memory detail / text to memory subtypes. Adds some new memories to demonstrate. (#72110)
So, a huge issue with memories and - what I personally believe is the
reason why not many have been added since their inception is - they're
very annoying to add!
Normally, adding subtypes of stuff like traumas or hallucinations are as
easy as doing just that, adding a subtype.
But memories used this factory argument passing method combined with
holding all their strings in a JSON file which made it just frustrating
to add, debug, or just mess with.
It also made it much harder to organize new memories keep it clean for
stuff like downstreams.
So I refactored it. Memories are now handled on a subtype by subtype
basis, instead of all memories being a `/datum/memory`.
Any variety of arguments can be passed into memories like addcomponent
(KWARGS) so each subtype can have their own `new` parameters.
This makes it much much easier to add a new memory. All you need to do
is make your subtype and add it somewhere. Don't need to mess with jsons
or defines or anything.
To demonstrate this, I added a few memories. Some existing memories had
their story values tweak to compensate.
Makes it way simpler to add new memories. Maybe we'll get some more fun
ones now?
🆑 Melbert
add: Roundstart captains will now memorize the code to the spare ID
safe.
add: Traitors will now memorize the location and code to their uplink.
add: Heads of staff winning a revolution will now get a memory of their
success.
add: Heads of staff and head revolutionaries who lose their respective
sides of the revolution also get a memory of their failure.
add: Completing a ritual of knowledge as a heretic grants you a quality
memory.
add: Successfully defusing a bomb now grants you a cool memory. Failing
it will also grant you a memory, though you will likely not be alive to
see it.
add: Planting bombs now increase their memory quality depending on how
cool the bomb is.
refactor: Memories have been refactored to be much easier to add.
/🆑
* Modular!
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: Funce <funce.973@gmail.com>
* Fixes scientists & the RD not being able to reach the Ballmer peak. (#72687)
🆑 ShizCalev
fix: Drunk scientists & the RDs rejoice! You can now reach the Ballmer
peak!
admin: Fixed a bunch of liver traits not being assignable.
/🆑
* Fixes scientists & the RD not being able to reach the Ballmer peak.
Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com>
* Fixes a neck slice runtime (#72582)
## About The Pull Request
The neck slice status effect didn't remove or react properly in tick,
and kept going after deleting itself. Adds some returns. Also adds an
examine message since i'm here.
## Why It's Good For The Game
Less runtime
## Changelog
🆑 Melbert
fix: Fixed a runtime from neck slices on headless mobs.
qol: Neck sliced folk now have an examine message saying as much.
/🆑
* Fixes a neck slice runtime
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Converts drowsy and eye blur to status effects, striking yet another two carbon level status vars
* merge conflicts
* adjust_eye_blur and set_eye_blur_if_lower
* adjust drowsiness overdoses
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: tastyfish <crazychris32@gmail.com>
* *hand, or That /One/ Emote You Always Felt Was Missing (#71600)
## About The Pull Request
It's happened to me _repeatedly_ that I'd see someone down on the floor,
and wanted to just, give them a hand, so they could take it and get up
that way, without just, directly clicking on them, since that's a little
bland. I've also wanted to just, offer my hand to someone so they could
grab it, so that I could pull them alongside me, rather than just
targeting one of their arms and ctrl-clicking them.
I've had this idea for a _long_ time, and only just decided to do this
today.
Now, I know what you might say. "Golden, that's a lot of code for
something this simple!" You're not wrong. _However_. I decided to go
along and to give some more love to the `/datum/status_effect/offering`
status effect and the offering-related alerts, to make them a lot more
versatile and a lot less hardcoded. Hence the whole "refactoring" part
of this.
Of course, when I add something, I don't do it half-way. So, the way the
emote works is much like the `*slap` emote, except that:
- When you click on someone, it does the exact same as if you were
offering the item to them, except that it's targeted (much like
ctrl-shift-click).
- If there's nobody directly adjacent to you, it won't do anything.
- If there's at least one person lying down around you, you will offer
them your help to get up. Should they take your hand and let you help
them up, you will both receive a simple memory about being helped up (or
helping up), as well as a 45-seconds-long small mood buff, because it
feels nice to be on either end of such a friendly gesture. If they get
up, they automatically get disqualified from being offered some help
standing up, and likewise, if you lie down, that offer goes away as
well.
- If there's at least one person around you, you will instead extend
your hand in their direction, for them to grab onto it. Should they do
so, you will then grab them by their arms and pull them.
I reworked the offering status effect to no longer have a hardcoded
`can_hold_items()` check, so that kisses and the hand offering would no
longer need you to have free hands to complete. The logic here is that
you can still pull someone even with both hands filled, so I figured I'd
leave it this way.
Note: If anyone would like to give the item a better sprite, by all
means, go ahead, that'd be amazing. I'm just not really a great spriter
and couldn't be bothered to waste hours making a very _meh_ hand.
## Why It's Good For The Game
It's fluff, and nice fluff at that. It makes it easier for people to be
nice to one-another without having to necessarily spend so long writing
up an emote that the person on the floor will already have gotten back
up. I'm sure the MRP folks will like it, and I'm certain the HRP
downstreams will love it too ;)
## Changelog
🆑
add: Added the *hand emote, which you can offer to someone standing up
in order to give them the possibility to grab onto your hand and let you
drag them away, or to someone lying down to help them back up, which
always makes everyone involved a little happier!
refactor: De-hardcoded and genericized a lot of the offering status
effect and alert code, to make it require a lot less copy-paste to
handle new cases.
fix: Offering a kiss no longer requires the receiver to have free hands
to accept said kiss!
/🆑
* *hand, or That /One/ Emote You Always Felt Was Missing
Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com>
* Fix: Robotic Damage / Reagents Refactor (#71937)
This PR is a continuing refactor of and fixes bugs introduced by my
prior PR #71864
Due to many functions in reagents having been implemented on top of
prior buggy code, their new behaviors are not as expected in-game, and
as a result reagents damage/heal robotic/cybernetic bodyparts/organs
when not appropriate; bugs like healing robotic arms with Libital is
currently possible.
To fix the errant behaviors in the newly debugged code, I have added
three variables to `datum/reagent` which are used throughout reagent
code, mainly inside of `on_mob_life` etc:
- `affected_bodytype = BODYTYPE_ORGANIC` - Used if the reagent
damages/heals bodyparts (Brute/Fire) of an affected mob.
- `affected_biotype = MOB_ORGANIC` - Used if the reagent damages/heals
generic damage (Toxin/Oxygen) of an affected mob.
- `affected_organtype = ORGAN_ORGANIC` - Used if the reagent
damages/heals organ damage of an affected mob.
The diff is large, and I have refactored the readability/maintainability
around the sections of code I was modifying. At one point I chose to
perform a quality pass on reagents because I found it quite hard to
maintain reagents code in its current state. This PR also replaces many
single-letter variables with more descriptive and readable variable
names. I also found and fixed a stray tab which was located in the
flavortext of `proc/item_heal_robotic`
Due to an old bug being fixed recently by PR #71864 a lot of
healing/damaging reagents now have an effect on robotic bodyparts. This
PR corrects the issue and changes reagents to explicitly define the body
type, bio type, and organ type which they can affect with
helaing/damage. This PR replaces a lot of single-letter variable names
with more descriptive names. I also fixed a small typo in
`item_heal_robotic` which was inserting an extra tab.
🆑
fix: Fixed a stray-tab typo in "item_heal_robotic"
fix: Fixed reagents and other effects which were inappropriately
affecting robotic limbs.
code: Refactored all of reagents code to be more readable and
maintainable.
/🆑
Co-authored-by: Time-Green <timkoster1@hotmail.com>
* Modular!
* More Modular!
Co-authored-by: Dani Glore <fantasticdragons@gmail.com>
Co-authored-by: Time-Green <timkoster1@hotmail.com>
Co-authored-by: Funce <funce.973@gmail.com>
