* Removes more NTNet from Tablets and removes a ton of dead code (#74085)
## About The Pull Request
Removes NtNet softwaredownload/communication because they did nothing,
so this also removes the feature to shut them off from Wirecarp
I removed tablets from being added to networks, Tablets already generate
logs for actions they do, which is already enough for the effects it has
in-game (just being visible to Wirecarp), once NtNet is deleted from
everything else then we can move it to ModPCs and limit logging to only
ModPC actions.
Fixes shutting off ntnet relays from Wirecarp, now you can properly shut
off Ntnet, and the warning that it kicks you out of the program is now
true.
Gives the Holodeck it's own network root define and fixes Syndicate
network showing up on Wirecarp
Wirecarp's PDA logs now shows the source of an action
## Why It's Good For The Game
Moves ModPCs further from NTNet so we can move towards deleting it
entirely
Makes Wirecarp more responsible and trustworthy
Removes useless stuff that never gets used, simplifying a overthought
overcomplicated system.
## Changelog
🆑
balance: Wirecarp now properly shuts off NtNet remotely.
balance: Wirecarp now shows the source of a PDA that does an action.
fix: Wirecarp can no longer be used to see if Nukies exist through their
networks.
del: Removes Software downloading and communication Ntnet networks, as
they were pretty worthless.
/🆑
* Removes more NTNet from Tablets and removes a ton of dead code
---------
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
* Stabilized gold extracts can now summon basicmobs (#74020)
## About The Pull Request
Stabilized gold extracts can now summon basicmobs,
Also, summoned familiars become friendly to the owner, which stops stuff
like mice running away.
## Why It's Good For The Game
They can now make cool basicmob carp and stuff
Fixes#74008
## Changelog
🆑
fix: Stabilized gold extracts can now spawn basicmobs
/🆑
* Stabilized gold extracts can now summon basicmobs
---------
Co-authored-by: jimmyl <70376633+mc-oofert@users.noreply.github.com>
* Fix: DNA Infuser & Unit Tests, Organs Bugfixes (#73003)
>_"I don't remember buying tickets to Mutants on Ice."_
>-Duke Nukem
This PR is (hopefully the final) part of a series of my continuing
refactors of the DNA Infuser. This PR represents a "quality pass" which
should also iron-out the rest of the most impactful bugs.
Granular list of changes:
- This PR adds unit tests for the DNA Infuser organs and
`/datum/status_effect/organ_set_bonus` as recommended by @AnturK
- I noticed that the base `/datum/infuser_entry` was being used in the
machine for the Fly and "rejected" infusions, whereas usually we would
expect it to be a base type used only as a development template. I
corrected this issue and created `/datum/infuser_entry/fly` to be used
for that use-case instead.
- Added `/mob/proc/can_mutate()` and `/mob/living/carbon/can_mutate()`
to replace a few copied lines across several files. The proc is normally
used in the context of mutating a Human via their DNA.
- I fixed a ton of typos in organ-related code, specifically where
"receiver" was typo'd as "reciever". There are far more of those typos,
but I limited the scope of my changes to organs.
- I noticed a bug in `/datum/species/proc/regenerate_organs` wherein a
race condition caused an organ to remove itself before it's done
inserting itself. This happens because the Fly organ set bonus runs
`regenerate_organs` which calls `Remove` on the organ while `Insert` is
still in the call-stack. I added `INVOKE_ASYNC` as a workaround, and
also changed the order the signals are emitted to prevent future bugs.
This bug primarily only impacted the flyperson species transformation,
which was part of the DNA Infuser's flyperson infusion organ set bonus.
- In my last refactor PR #72745 I also introduced a bug in
`/obj/machinery/dna_infuser/proc/infuse_organ` wherein I forgot to add
the usage of `new` when attempting to implant new organs, and this PR
fixes the erroneous code.
- Fxed a bug which causes the organ set bonus to activate when mixing
organs from different sources, which is caused by a developer oversight
wherein all `/datum/status_effect/organ_set_bonus` had identical IDs.
- Added a cleaner `replacetext`-based way of handling pronouns in
`/datum/element/noticable_organ/proc/on_receiver_examine`, using custom
macros `%PRONOUN_S` and `%PRONOUN_ES` as advised by @MrMelbert
- This PR also fixes#72767
With the changes in this PR the machine will finally work as we expect
it to. By adding unit tests we will also be able to ensure that it works
as expected from now on. I feel confident saying that the completeness,
algorithmic correctness, and code health of the DNA Infuser is much
better than it was before.
🆑 A.C.M.O.
fix: Fully fixed the DNA Infuser, which will now infuse organs as
expected.
fix: Fixed flyperson species transformation and organ set bonus, which
was throwing a runtime.
fix: Fixed many typos in organ-related source code.
/🆑
---------
Co-authored-by: Time-Green <timkoster1@hotmail.com>
* *shrug
* Uncommented the line Gandalf wanted uncommented
* Properly fixes CI on this one, hopefully.
---------
Co-authored-by: Dani Glore <fantasticdragons@gmail.com>
Co-authored-by: Time-Green <timkoster1@hotmail.com>
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* Splits mutant_bodyparts.dmi into several subfiles. (#71408)
Splits the `mutant_bodyparts.dmi` file up, as was suggested, but not
implemented, in #69302.
The following new files were created in the `icons\mob\species` folder,
containing the listed sprites:
- `lizard\lizard_misc.dmi`: Snouts, horns, frills, and body markings.
Anything I didn't feel needed an entire file to itself.
- `lizard\lizard_spines.dmi`: Lizard spines, both animated and not.
- `lizard\lizard_tails.dmi`: Lizard tails, both animated and not.
- `human\cat_features.dmi`: Felinid ears and tails.
- `monkey\monkey_tail.dmi`: The monkey tail.
- `mush_cap.dmi`: The lone mushperson cap, so easily forgotten.
Additionally, I moved `wings.dmi` from `mob\clothing` to `mob\species`.
I'm not sure what it was doing there.
`mutant_bodyparts.dmi` was something of a mess, with parts from four
different species thrown together haphazardly. It probably made sense in
earlier days when "mutant humans" were few and far between, but
splitting it up makes it more intuitive to find these sprites, and
brings it in line with other species - namely, moths. It also means that
any future sprites of these types added will not bloat an oversized file
even more.
Moving the wings file to the species folder just makes sense, because
wings are not a type of clothing.
🆑
refactor: Removed mutant_bodyparts.dmi and distributed its sprites in a
more sensible and granular manner.
/🆑
* External Organ Rework: new bodypart_overlay system (#72734)
Bodypart overlays are now drawn by the new /datum/bodypart_overlay
datum.
External organs no longer draw anything and instead add a special
/datum/bodypart_overlay/mutant to the bodypart, which draws everything
Makes it way easier to add custom overlays to limbs, since the whole
system is now modularized and external organs are just one
implementation of it
I haven't moved anything but external organs to this new system, I'll
move eyes, bodymarkings, hair, lipstick etc to this later
New pipeline is as follows:
- External organ added to limb
- External organ adds /datum/bodypart_overlay/mutant to limb to
bodypart_overlays
- Limb updates its icon, looks for all /datum/bodypart_overlay in
bodypart_overlays
- Very cool new overlay on your limb!
closes#71820🆑
refactor: External organs have been near-completely refactored.
admin: Admin-spawned external organs will load with a random icon and
color
fix: fixes angel wings not working for non-humans (it was so fucking
broken)
fix: fixes external organs being invisible if they werent initialized
with a human
/🆑
External organs are cool but are pretty limited in some ways. Making
stuff like synthetic organs is kinda fucked. I tried and it was dogshit.
Now you can just give an icon state and icon and you're good (using
/datum/bodypart_accessory/simple)
Stuff like eyes, cat ears and hair seem like good choices for extorgans,
but don't quite work for it because their icons work a lot differently.
This solves for it completely since any organ (or object or whatever)
can add it's own icon to a bodypart.
Want to add an iron plate to someones head? Go ahead. Want a heart to
stick out of someones chest? No problem.
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Makes the whole thing compile, although it most likely doesn't work
* Whoopsie daisy
* Now it's starting to work
* ok monkey
* Fixes tails some more
* Moth wings should be wings not moth wings
* Podpeople hair, yeah.
* Okay no more handle_mutant_bodyparts()
* Removed an useless variable from is_hidden()
* Fixes some more can_draw_on_bodypart (I'm gonna have to fix it upstream too)
* Removes the second useless argument of is_hidden()
* No, cat tails are no longer allowed to be snowflake
* Removes some useless variables from humans
* Whoops I forgot to commit this one
* How did I miss this one?
* Okay, yeah, tails and some other stuff show up now. Pod people hair too. Just many of them don't. Good enough for today.
* Okay so after a lot of pain and suffering, many mutant_bodyparts are now functional
* Everything works, except for ears, some of the taur layering, and moth markings (which never worked it seems)
* Alright skintones seem to work rather well now(?)
* Okay, my bad, now they do
* Moth markings can't be selected and won't be added anymore (since they're broken and integrated into the regular markings system anyway)
* Spines are no longer just matching the color of the limb they're attached to
* Moves taur organ and bodypart_overlay out of the sprite_accessory file for taurs, and fixes the taur rendering
* Linters moment
* Alright, spines are working and overlaying properly now
They just need to have a FRONT overlay for the /tg/ ones if we want them to display above the lizard tails, we already have that for vox spines thankfully.
* Disables moth_markings for good
* Fixes some rendering bugs
* Makes ears work (almost, rest of the code has MODsuit stuff in it too :( )
* Made the MODsuit overlays work :)
* Fixed horns and spines
* Fixes all of the screenshot tests
* Removes the Body Markings option from Appearances, use Augments+ instead (because that one works and is just better)
* Bye bye handle_mutant_bodyparts(), I won't miss you :)
* Forgot to take this out, whoops
* Fixes the moth antennae being unticked
* Removes some commented code in a modular file
* Fixes part of the create_and_destroy unit test
* Fixes a pretty big issue that caused some sprite_accessories to be removed from the global list because of the alter_form action (deep copies ftw)
* Fixes the runtimes related to pod_hair
* Gives the vox a better look in the prefs menu
* Fixes the appearance of functional wings
* Makes synths able to access their robotic wings
* Podpeople don't cause runtimes during CI anymore
* Fixes the random appearance of locked functional wings
* Fixed cat and lizard tails using the /tg/ sprites (we have slightly modified ones)
* Fixes the coloring on multi-colored sprites
* Fixes the code for the screenshot of the mammal screenshots and preview, so it has a tail
* Fixes the screenshot tests for a few species
* Fixes tails going invisible when wagging
* Fixes a runtime with horns
* Fixes showing/hiding mutant bodyparts not working at all
* (Hopefully) fully fixes all the issues related to extra and extra2-related icon_states.
* Fixes synth stuff and starts working on pod hair again
* I DID IT PODPEOPLE HAVE HAIR AGAIN
* Fixes the podpeople hair showing up on more than just podpeople
* Fixes the IPC screens showing up on species outside of synthetics
* Fixes a runtime in the pod_hair and the synth_screen's apply_to_human
* Updates the screenshots for podpeople and synths
* Fixes an issue with a certain type of organs
* Fixes another runtime, whoops
* Fixes the markings from /tg/'s Body Markings not being available in our markings system
* Re-adds support for taur-variants of certain mutant bodyparts
* Hopefully fixes a few more runtimes
* Adds some debug variable in the code for now, likely to be removed later if really necessary. This will make my life easier.
* Whoops, that needed to be backwards. :clown:
* Fixes the top snouts not rendering at all
* Fixes the issues where bodytypes weren't handled properly, and thus snouts were getting squished
* Fixes the weird placement of the Xeno Head Emissives in the prefs menu
* Removes a no-longer-necessary override of post_set_preference() in the limbs_and_markings middleware
* Reverts an unnecessary SKYRAT EDIT inside of commented out code
* No longer creates a new body every time we change prefs in the prefs menu, we reusing now lads
I know there's commented out code but I'm going to remove that in another commit
* Removed some more dead code.
* Fixes jellyfish ears being all white
* Fixes plasmaman limbs not displaying because I accidentally hardcoded the limb_id for all augments to "robotic"
---------
Co-authored-by: lizardqueenlexi <105025397+lizardqueenlexi@users.noreply.github.com>
Co-authored-by: Time-Green <timkoster1@hotmail.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Delete humanform.dm
* bad NANA!!!
* Update simple_animal_freeze.dm
* Update changeling.dm
* e
* wew
* Fixes the issue that caused CI to fail compilation
* Forgot to remove this one.
* wew
* fix screenshot unit test
* fixes emissive CI
* color cutoffs
* more emissive fix
* Update wardrobes.dm
* tallboy
* fix
* regen screenshots
* Update dna.dm
* screenshots
* Update dna.dm
* Fixes the lesserform unit test
* Adds our own monkey screenshots because we have monkey jumpsuits :)
---------
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* Adds a stack_trace for emissives with invalid icon_states, fixes all that appeared roundstart (#73678)
## About The Pull Request
So, this spiraled from one missing icon being fixed to an entire check
for said icons.
Several icon files no longer use error icons because its assumed that
the checks will handle any missing ones, but the checks don't apply to
emissives nor overlays at all. This led to the radsuit having an
emissive but no icon_state for it - a relic of the old radsuit. This was
only noticed because of a downstream with an error icon appearing for
it...
I was curious how many were actually having the same issue, so I made a
small little stack_trace in the mutable_appearance proc.
There were like, 2k. Lots of them were icons named, like, "transparent"
or "blank" too...
I moved that check to the emissives proc because I semi-understand that
system so could actually fix it, and it moved to around fourty
roundstart. Much more achievable.
(The error usually has more info if you click on it, including the item
that caused it. I dunno how to add that to the check itself because of
where it's located, though.)
This fixes all the ones I could find, including...
Nonexistant icons that shouldn't be adding emissives on:
- Empty Barsign
- Radsuit
- Mass Driver Controllers
- Telescreens
- Aux Base Consoles
- PanDEMIC
- Kobayashi computer (holodeck)
- Abductor camera console
- Syndie drop pod
- BSA controller
Entirely missing icons on:
- Pwr Game Vendor (this was just misnamed)
- Generic Soda Vendor
- Engivend
- Security Laptop (proud of this one.,.,)
There are no doubt more of them hidden about, but I don't really know
what I'm doing... If there's a check that'd be better than this, please
review telling me what to change <3
## Why It's Good For The Game
Fixes missing icons, fixes attempts to add icons where we don't need
them, and adds a check to help fix more of the two issues as they occur.
## Changelog
🆑
fix: fixed missing emissives on the Engivend, Pwr-Game Soda, and generic
Soda vendors. Also fixed the seclaptop having no valid screen icon!
fix: fixed a few items trying to apply emissives when they shouldn't.
code: added a stack_trace for emissives with missing icon states.
/🆑
* Adds a stack_trace for emissives with invalid icon_states, fixes all that appeared roundstart
* Update cryopod.dm
---------
Co-authored-by: OrionTheFox <76465278+OrionTheFox@users.noreply.github.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
* Brings the monkey back down (body horror edition/addition.) (#73325)
## About The Pull Request
Let me paint you a story.
A long time ago monkeys once rested their feet on the floor, this was a
time of bliss and peace. But sometime around the horrors of making
monkeys subtypes of humans did an atrocity occur.
**The monkeys were moved up.**
I thought this was bad, and alot of people on the forum tended to agree
with me
This was do to some purpose of adjusting them so it could be easier to
fit item sprites onto them instead of preforming the hours of work
refractoring to make the heights of the items dynamic and adjustable. A
simple pixel shift may have sufficed, but you see, such a change would
NEVER allow the frankensteining of monkey and human features together.
This is that refractor.
In essence, the following is now true.
A top_offset can now be generated for a human based on a varible on
their chest and legs. By default, and as is true with human legs and
chests, this variable is ZERO by default. Monkey legs and chest have
NEGATIVE values proportionate and onto how much smaller their sprite is
compared to humans. Other bodyparts, as well as any other accociated
overlays, or clothing will automatically be offset to this axis. THIS
MEANS THAT MONKEYS ARE ON THE FLOOR. But is means something else too.
Something more freakish,
**What abominable monsters**, unreachable by players as long as we can't
stitch monkeys and humans together (oh but just wait until the feature
freeze ends)
Oh but you might be thinking, if legs can make a mob go down.
can it make a mob
**go**
**up??**
**OH NO**
These lads are stepping, and have been implemented solely for proof of
concept as a way to flex the system I have created and remain
inaccessible without admin intervention.
But really, when all is said and done, all this PR does in terms of
player facing changes is move the monkey back down.
Oh and fixed monkey husked which have been broken for who knows how
long.
## Why It's Good For The Game
The monkey is restored to its original position. Tools now exist to have
legs and torsos of varying heights. Monkey Husking is fixed.
## Changelog
🆑 itseasytosee
fix: Monkeys ues the proper husk sprites.
imageadd: The monkey has been moved back down to its lower, more
submissive position.
refactor: Your bodyparts are now dynamically rendered at a height
relevant to the length of your legs and torso, what does this mean for
you? Not much to be honest, but you might see a monkey pop up a bit if
you cut its legs off.
admin: The Tallboy is here
/🆑
---------
Co-authored-by: Fikou <23585223+Fikou@ users.noreply.github.com>
Co-authored-by: san7890 <the@ san7890.com>
* Brings the monkey back down (body horror edition/addition.)
* Update species.dm
* Delete infuser_entries.dm
---------
Co-authored-by: itseasytosee <55666666+itseasytosee@users.noreply.github.com>
Co-authored-by: Fikou <23585223+Fikou@ users.noreply.github.com>
Co-authored-by: san7890 <the@ san7890.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.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>
* Updates space verification unit test to use new proc (#73322)
## About The Pull Request
At San's request, updates the space verification unit test to use the
new "are we a planetary map" proc instead of having its own
implementation of the same thing.
## Why It's Good For The Game
If it gets broken in one place it will break in all of them, most
importantly the unit test, which is what we want because that's what the
test is for.
## Changelog
Not player facing.
* Updates space verification unit test to use new proc
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
* Refactors abstract traitor objectives to be more abstract and enforces this by using unit tests. Rebalances some traitor objectives (#73777)
## About The Pull Request
In this PR, some of the traitor objectives are rebalanced to be more
consistent with scaling risk.
Abstract traitor objectives have had their telecrystal reward and
progression rewards moved to their non-abstract types and it's now
enforced that abstract objectives should not have these values set.
Additionally, it's encouraged that people don't set progression_minimum
on abstract types either, but I can see the usecase in doing so with
final objectives and assassinate objectives. This is why it's fine to
set progression_minimum on an abstract type as long as any of the
derivatives of that abstract type do not redefine the progression
minimum to avoid consistency errors when tweaking progression minimum
values. Setting the progression minimum on an abstract type means that
all derivatives of that abstract type should be unlocked at roughly the
same time.
## Why It's Good For The Game
The rebalances are so that same risk objectives of different types are
worth around the same amount. Repeatables should roughly award the same
amount of TC when it comes to comparing the risk, but the progression
rewards can vary.
The new standard enforcement on abstract traitor objectives is more so
for robustness and ease of balance, as it's easier to lose consistency
when rebalancing values between two objectives, because one of the
objectives derive their rewards from an abstract type. Generally
speaking, rewards from objectives of different risk level should not be
the same and it's easier to enforce this if developers have to
explicitly declare the rewards of the objectives they add.
This doesn't mean each objective has to declare explicitly what their
reward is. Derivatives that subtype off of non-abstract types can still
copy the rewards from their parent.
The progression minimum is fine to be set on abstract objectives as long
as derivatives don't change the progression minimum. If they do, then
it's better for consistency to declare the progression minimum on each
type rather than the abstract type so that higher-tier objectives don't
accidentally end up with a lower progression minimum when it comes to
rebalancing. Of course, this isn't a set rule on, but it's something I'm
going to try and enforce, when it makes sense, going forward, even if it
may increase the number of lines of code each traitor objective file may
have. Maintainability and robustness beat optimization.
## Changelog
🆑
code: Abstract types don't hold telecrystal rewards or progression
rewards anymore, this has been moved to the non-abstract types.
balance: Rebalances rewards from repeatable traitor objectives to be
more consistent with each other.
/🆑
---------
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* Refactors abstract traitor objectives to be more abstract and enforces this by using unit tests. Rebalances some traitor objectives
---------
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* this code is so fucking funny it makes me want to merge w/o looking
* safety component stuff
* safeties should be finished
* I loooove safety component
* I swear that's all for gun safety
* manufacturer component
* cant forget this
* this is so awful
* 1100 line long gun file
* ok it actually compiles now
* that should not be an addition of any sort
* these defines should not be used anymore
* why?? the fuck??? are there var edited fire modes on black mesa?????
* how did that even happen
* maybe ci will shut up now
* oh man so many guns are lacking autofire now
* probably fixes safety toggling
* that should reference the gun not the component
* that should probably return
* makes it replicate current behavior, defaults safeties to being ON
* and that is all i have to say about that
* its automagically
* Fixes all antag datum moodlets being removed when any single antag datum is removed (#73305)
## About The Pull Request
All antag datums operated under the `antag_moodlet` mood category, which
is clearly an issue when you can (and commonly) have multiple antag
datums of different types on your mob.
New antag datums of different type will now no longer override older
antag datum moodlets, now they will stack. This means traitor
revolutionaries are the most zealous folk on the station.
This has a few potential oversights down the line:
- Someone adds an antag datum players can have duplicates of, and also
has a moodlet associated
- Re-used moodlets in antag datums that can easily be stacked will be
noticed
- Most solo antags used `focused` right now, but none can stack outside
of admemes
But I don't think it's an issue for now.
## Why It's Good For The Game
Prevents a quick revolution from stripping you of your joy.
Fixes#67313
## Changelog
🆑 Melbert
fix: Revolutionary Heretics and Cultists Traitors no longer lose all of
their joy in life after being de-converted from their respective causes.
/🆑
* Fixes all antag datum moodlets being removed when any single antag datum is removed
* fix
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
Co-authored-by: John Doe <gamingskeleton3@gmail.com>
* Fixes an issue with nightmare revival, Unit tests some fully heal stuff (#73612)
## About The Pull Request
- Same issue as Ethereals. Owner was `null`ed because the heart was
recreated. I opted for a more permanent solution, that being introducing
a new flag to avoid recreating organs.
- Adds some unit tests for fully heal stuff to make sure it works.
## Why It's Good For The Game
More cases of revival working as expected
## Changelog
🆑 Melbert
fix: Nightmare revival acts less funky - stops it from re-creating the
Light Eater.
/🆑
---------
Co-authored-by: san7890 <the@ san7890.com>
* Fixes an issue with nightmare revival, Unit tests some fully heal stuff
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: san7890 <the@ san7890.com>
* Return to Tiny: Reworks heights to use filters, allows spacemen to have varying heights (#72344)
Re-pr of #66644 with some changes to get it working
- [x] ~~Huds get cut off~~ Resolved
- [x] ~~Very tall helmets get cut off~~ Resolved
- [x] Hair gets cut off
- [x] ~~Needs optimization before releasing to the world as a pref~~ jk
lol
Look at that fella so cute
🆑 Melbert, That REALLY Good Soda Flavor, FatFat, AndreyGusev
add: Spacemen can now have varying height. (Admin only for now)
add: Dwarfs are now slightly shorter, but look way better.
/🆑
Co-authored-by: Jack LeCroy <3073035+jacklecroy@users.noreply.github.com>
* fix conflict
* clarity
* update rouny
* update screenshots
* Revert "update screenshots"
This reverts commit a5427a5238e574869fe364568b7f043bbd287c79.
* Fixes the dwarf screenshot.
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: Jack LeCroy <3073035+jacklecroy@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
[NEW GHOST ANTAG] The Paradox Clone (#71141)
[DESIGN DOC]
https://hackmd.io/@tGKknGe5Q7qtddEspif79g/BJ3w9QLri/edit
Bluespace technology has destabilized the very fabric of reality, even
time itself!
Sometimes during a shift, it's possible for a PARADOX CLONE to spawn
somewhere on the station (usually maintenance). This paradox clone has
the exact appearance and DNA as a random crew member on the station,
wearing the same clothes they were at the start of the shift, including
their ID.
To maintain timeline coherency, the paradox clone must now hunt down and
kill the original and take their place or die trying, if the original
survives they have failed.
The only thing the paradox clone spawns with is a mechanical toolbox
that helps them from being stuck in maints if their ID doesn't have
maints access.
The inclusion of this antag encourages good crew coordination and adds a
less destructive, more personalized antag to the roster.
This antag rewards good detective work, as both the clone and the
original are identical in every way, and will therefore require a
detective to break out their detective skills to figure out who the
clone is.
Also a possible tie-in with the Chrono Legionnaires in the future.
🆑
add: Time and space has destabilized even further due to Nanotrasen
bluespace research, now, on occasion, clones from different timelines
can appear on the station and hunt you down to maintain timeline
stability! Beware the Paradox Clone!
/🆑
---------
Co-authored-by: 1bw0kopy <xz2rbf23@protonmail.com>
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
Co-authored-by: Jeremiah <42397676+jlsnow301@users.noreply.github.com>
(cherry picked from commit 214174874c)
Co-authored-by: Shadyyy66 <114319683+Shadyyy66@users.noreply.github.com>
* Optimize cardboard cutouts saving 1.5s+ on init times (#73404)
New regression in init times. Closes
https://github.com/tgstation/dev-cycles-initiative/issues/32. CC @ Fikou
- Instead of creating a human and icon for *every* cardboard cutout when
initialized, only creates the one we're actually using. When you're
about to use a crayon, creates all of them.
- Instead of using getFlatIcon, uses appearances directly.
* Optimize cardboard cutouts saving 1.5s+ on init times
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Wraps all instances of invoking Fail() into the TEST_FAIL Macro (#73407)
We shouldn't really be invoking the proc itself because then we don't
pass along the failing line/file to our consumers, let's use the macro
in all instances that really need it.
I noticed people were invoking the `Fail()` proc directly rather than
using `TEST_FAIL` instead, so they weren't getting those neat
annotations on their failing code because we never passed along the
failing line/file to actually apply those annotations. That's silly. We
don't even return on `TEST_FAIL` either, so there's no reason to not do
this (only upsides wahoo).
* Wraps all instances of invoking Fail() into the TEST_FAIL Macro
* Correct macro in opfor unit test
---------
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Tastyfish <crazychris32@gmail.com>
* Fixes changing species causing you to drop held items, Fixes loss of right arm not applying typical "lost arm" effects (#73356)
## About The Pull Request
`drop_limb(special = TRUE)` will now no longer drop held items. This can
cause issues if people are misusing `special`, but if people are not
then it's fine, as it's supposed to be replaced just after.
Also cut out some copy-pasta from arm and leg `drop_limb`. Since they're
one unified type, they no longer needed to carry across both. This fixed
another bug
Also also, I was able to move the held index check out of core bodypart
code, and down to arm level. This MAY have side effects, which I'm
observing for.
## Why It's Good For The Game
Changing species let you drop no-drop items, super lame
## Changelog
🆑 Melbert
fix: Changing species no longer drops all held items
fix: Losing your right hand not un-cuffing you or dropping your gloves
/🆑
* Fixes changing species causing you to drop held items, Fixes loss of right arm not applying typical "lost arm" effects
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Barsign UI/UX Improvements - Emissive effects, balloon alerts, and refactored code (#73106)
The barsign code is over a decade old so this is a big refactor with
some notable improvements:
- Emissive effects (neon lights now glow in the dark)
- Balloon alerts instead of `to_chat` messages
- Mapping helpers based on direction and all_access
- Barsigns are considered machinery now and use power
* Barsign UI/UX Improvements - Emissive effects, balloon alerts, and refactored code
* fixes modular maps
---------
Co-authored-by: Tim <timothymtorres@gmail.com>
Co-authored-by: Paxilmaniac <paxilmaniac@gmail.com>
* Fix underlying armor logic and fix bug with constructed ripleys having zero armor (#73319)
## About The Pull Request
See title
## Why It's Good For The Game
Messed up one of the armor procs; it changed the given values but never
carried over existing values.
So you would end up with an armor of that one specific value and nothing
else.
This wasn't actually used anywhere other than mecha, lava burning, and
sentient viruses, so the issue isn't that bad.
It's still an issue however.
## Changelog
🆑
fix: Mechs no longer have zero armor when built.
/🆑
* Fix underlying armor logic and fix bug with constructed ripleys having zero armor
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
* Remove NTNet from doors (saves 0.2s of init) -- Fixes windoors not working with remotes, and balloons them (#71735)
## About The Pull Request
Removes NTNet from doors. NTNet as a whole is getting excised, but this
was an enormous cost to initialize. Was only used for door remotes, so
just changes them to act on the door directly.
Windoors were supposed to be controllable, but were broken at some point
to always display an error message in chat.
Closes https://github.com/tgstation/dev-cycles-initiative/issues/3
## Changelog
🆑
fix: Door remotes now open windoors again.
qol: Door remotes now use balloon alerts for failures.
/🆑
(cherry picked from commit db2566f44d)
# Conflicts:
# code/game/machinery/doors/airlock.dm
* Update airlock.dm
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
* Fixes new regal rat sprite & removes duplicate file (#73306)
Removes a duplicate file which was preventing the new regal rat sprite from being used.
* Fixes new regal rat sprite & removes duplicate file
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
* this is gonna look so cool
* oops
* ok that didnt quite work
* maybe we can keep the disk in the preview
* oh right dont give the previews ids
* yeah it really hates belt modsuits doesnt it
* updates the screenshot test
* 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>
[NO GBP] Lazy Template Cordoning | Double Runtime Fix (#72709)
## About The Pull Request
Adds automatic cordoning to block reservations.
Also fixes an issue where ChangeTurf would cause SSicon_smoothing to
throw runtimes by calling QUEUE_SMOOTH regardless of initialization
completion
## Why It's Good For The Game
## Changelog
---------
Signed-off-by: GitHub <noreply@github.com>
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Stack traces when a cliented or ckeyed mob is Destroy()ed. (#72797)
## About The Pull Request
One thing that repeatedly pops up in admin channels is investigating
causes of death when a player just vanishes from the game. These are
almost universally qdeletion issues.
9 years ago `/mob/Destroy()` was commented with:
`//This makes sure that mobs with clients/keys are not just deleted from
the game.`
Whatever code may have existed back then has long since been replaced.
**I consider that Destroy()ing a cliented or ckeyed mob is a runtime
error case.**
Code which may result in deleting a mob should handle removing and/or
reassigning any client or ckey - or call generic procs that do so -
prior to destruction. This should ideally result in a clear log trail
that allows admins to see what happened. Where this isn't the case, a
stack trace will now be available to help narrow down the cause of
qdeletion so an issue report can be made, and so admins have SOME info
to investigate on.
An example of where this would help catch bugs is #72782 - It was
clearly unintended behaviour to qdel the mob in the first place and this
stack trace would have immediately highlighted exactly where the death
came from.
```
[2023-01-18 12:44:40.415] runtime error: Mob with client has been deleted. (code/modules/mob/mob.dm:29)
- proc name: stack trace (/proc/_stack_trace)
- source file: stack_trace.dm,4
- usr: Julia Watson (/mob/living/carbon/human)
- src: null
- usr.loc: the floor (111,143,2) (/turf/open/floor/iron)
- call stack:
- stack trace("Mob with client has been delet...", "code/modules/mob/mob.dm", 29)
- Julia Watson (/mob/living/carbon/human): Destroy(0)
- Julia Watson (/mob/living/carbon/human): Destroy(0)
- Julia Watson (/mob/living/carbon/human): Destroy(0)
- Julia Watson (/mob/living/carbon/human): Destroy(0)
- qdel(Julia Watson (/mob/living/carbon/human), 0)
- the mouse (/mob/living/basic/mouse): try consume cheese(Julia Watson (/mob/living/carbon/human))
- the mouse (/mob/living/basic/mouse): tamed(the mouse (/mob/living/basic/mouse), Julia Watson (/mob/living/carbon/human))
- /datum/callback (/datum/callback): Invoke(the mouse (/mob/living/basic/mouse), Julia Watson (/mob/living/carbon/human))
- /datum/component/tameable (/datum/component/tameable): on tame(the mouse (/mob/living/basic/mouse), Julia Watson (/mob/living/carbon/human))
- the mouse (/mob/living/basic/mouse): SendSignal("simplemob_sentiencepotion", /list (/list))
- the intelligence potion (/obj/item/slimepotion/slime/sentience): attack(the mouse (/mob/living/basic/mouse), Julia Watson (/mob/living/carbon/human), "icon-x=16;icon-y=7;left=1;butt...")
- the mouse (/mob/living/basic/mouse): attackby(the intelligence potion (/obj/item/slimepotion/slime/sentience), Julia Watson (/mob/living/carbon/human), "icon-x=16;icon-y=7;left=1;butt...")
- the intelligence potion (/obj/item/slimepotion/slime/sentience): melee attack chain(Julia Watson (/mob/living/carbon/human), the mouse (/mob/living/basic/mouse), "icon-x=16;icon-y=7;left=1;butt...")
- Julia Watson (/mob/living/carbon/human): ClickOn(the mouse (/mob/living/basic/mouse), "icon-x=16;icon-y=7;left=1;butt...")
- the mouse (/mob/living/basic/mouse): Click(the floor (112,143,2) (/turf/open/floor/iron), "mapwindow.map", "icon-x=16;icon-y=7;left=1;butt...")
-
```
See also #67300.
An example of where this would help identify causes of death where
previously there were none - Scenarios that were fixed by #62949 and
#66104 caused administrative headaches figuring out causes of death when
players in exploding crates just got literally fucking qdeleted. Which
was pretty trivial for players to do to other players.
Issue reports can be made and bugs can be fixed as we go along.
There are examples of quote "false positives" unquote.
Right click -> Delete, which can be used on any atom.
```
[2023-01-18 11:40:54.597] runtime error: Mob without client but with associated ckey has been deleted. (code/modules/mob/mob.dm:32)
- proc name: stack trace (/proc/_stack_trace)
- source file: stack_trace.dm,4
- usr: Norah Rader (/mob/dead/observer)
- src: null
- usr.loc: the floor (109,143,2) (/turf/open/floor/iron)
- call stack:
- stack trace("Mob without client but with as...", "code/modules/mob/mob.dm", 32)
- Fulton Enderly (/mob/dead/observer): Destroy(0)
- Fulton Enderly (/mob/dead/observer): Destroy(0)
- qdel(Fulton Enderly (/mob/dead/observer), 0)
- Timberpoes (/client): admin delete(Fulton Enderly (/mob/dead/observer))
- Timberpoes (/client): Delete(Fulton Enderly (/mob/dead/observer))
```
Admin gibself
```
[2023-01-18 11:41:17.635] runtime error: Mob with client has been deleted. (code/modules/mob/mob.dm:29)
- proc name: stack trace (/proc/_stack_trace)
- source file: stack_trace.dm,4
- usr: Norah Rader (/mob/living/carbon/human)
- src: null
- usr.loc: the floor (109,145,2) (/turf/open/floor/iron)
- call stack:
- stack trace("Mob with client has been delet...", "code/modules/mob/mob.dm", 29)
- Norah Rader (/mob/living/carbon/human): Destroy(0)
- Norah Rader (/mob/living/carbon/human): Destroy(0)
- Norah Rader (/mob/living/carbon/human): Destroy(0)
- Norah Rader (/mob/living/carbon/human): Destroy(0)
- qdel(Norah Rader (/mob/living/carbon/human), 0)
- Norah Rader (/mob/living/carbon/human): gib(1, 1, 1, 0)
- Norah Rader (/mob/living/carbon/human): gib(1, 1, 1, 0)
- Timberpoes (/client): Gibself()
```
Over time these stack traces can be checked for how well the true cause
of death is logged, and whether there is a better procedure for deleting
cliented/ckeyed mobs than just qdel(target).
## Why It's Good For The Game
qdeletion of cliented or ckeyed mobs is death and often lacks any
specific logging.
This obfuscates bugs and hinders admin investigation.
stack_tracing highlights where this happens, revealing the previously
obfuscated bugs more clearly. It also provides relevant information on a
cause of death that can allow admin investigation to take place despite
the absence of logging.
## Changelog
🆑
admin: When a player-owned mob is deleted from the game world, a stack
trace is now dropped in the runtime logs. This allows admins and coders
to investigate these issues easier.
/🆑
Co-authored-by: Timberpoes <silent_insomnia_pp@hotmail.co.uk>
Updates Mob_Spawn Unit Test To Use NAMEOF (#73035)
## About The Pull Request
One of the key functions of this test is to iterate vars to see if it is
null or not, and then error if something is defined where it should not
be. Just to futureproof this test in case someone changes the name of a
variable on the mob spawner (e.g. haircolor to hair_color), we still
want this unit test to work!
So, let's switch it all over to NAMEOF to ensure that all of our stuff
still works the way we want it: safe-guarded against trivial changes
(it'll throw a compile error if one of these vars are changed, which is
good because it compels the coder to fix it).
I also re-arranged the unit test since we didn't need to have those
bulky lists in the middle of the actual checking code, and it should
work a-okay.
## Why It's Good For The Game
Someone in the future will sob a few tears if this unit test breaks and
remains broken throwing runtimes and bricking tgui or whatever because
it's very easy to just have this unit test not be useful in a very
"simple code improvement"
## Changelog
Nothing that concerns players.
Co-authored-by: san7890 <the@san7890.com>
* Update alt_job_titles.dm
* Create cargo_technician.dm
* Create quartermaster.dm
* Update tgstation.dme
* Update wardrobes.dm
* Update loadout_datum_heads.dm
* Create clothing_overrides
* Update tgstation.dme
* despite claims to the contrary, I did not forget to put a .dm when transplanting this from where it was before
* so be it
* does the entire list like that
* why didn't this fail on local
* Update alt_job_titles.dm
* Delete screenshot_antag_icons_bloodbrother.png
* Add files via upload
* Update modular_skyrat/modules/alternative_job_titles/code/alt_job_titles.dm
Co-authored-by: Dragonfruits <51841793+Spc-Dragonfruits@users.noreply.github.com>
* pressed tab 68x, also, removes or edits two redundant comments
* Update cargo_technician.dm
* Update quartermaster.dm
* Update alt_job_titles.dm
* oop
* vile wretched ghoul released a plague upon this wo
rld and then the evil when the when he
Co-authored-by: Dragonfruits <51841793+Spc-Dragonfruits@users.noreply.github.com>
Co-authored-by: Zonespace <41448081+Zonespace27@users.noreply.github.com>
Water will now make you wet (#72844)
Water, when exposed to a mob either via `TOUCH` or `VAPOR` application,
will now apply wet stacks to said mob according to the amount of water
used. For touch application, the ratio is 0.5 wet stack per unit of
water, whereas for vapor application (so for foam and sprays), that
ratio is lowered to 0.1 wet stack per unit of water. Yes, that would
mean that you could now put someone out by spraying enough water at them
with a spray bottle (usually around 50-150u), and I think that is quite
simply hilarious.
I also updated the unit test of water's `expose_mob()` proc, to check
that wet stacks were being applied properly, hopefully making sure that
there's no regression on that part in the future.
* Fixes and buffs Metal Hydrogen golems (#72482)
## About The Pull Request
Metal Hydrogen golems as of now are quite literally not even immune to
_space_ and _the cold_, despite their description insinuating the exact
opposite and their manner of creation being more time-intensive than any
other golem. This PR fixes that, putting them on-par with all other
golems in regards to temperature and space immunity, whilst also
_hugely_ buffing them so they're not simply an antimagic version of
adamantine golems - instead, they're now most metal golems rolled into
one power-wise, with the armor of diamond golems as is befitting.
Also, I fixed their colors and wording (metal hydrogen isn't a
_mineral_, it doesn't naturally occur)
## Why It's Good For The Game
Creating metal hydrogen golems is not wholly difficult if you understand
atmospherics and practice safety in doing so, but compared to all other
golems they are _woefully_ underpowered and nigh-useless in most
practical applications. Adamantine golems are better in effectively
every way, and they're the standard for easily-created golems. Properly
fixing them and buffing them to ensure they're worth making is an
effective way to make metal hydrogen a more worthy endeavor for
atmospherics, and also metal hydrogen is simply cool.
## Changelog
🆑
fix: metal hydrogen golems no longer die to low pressures and cold
temperatures
fix: metal hydrogen golems are no longer solid white, and are now the
actual color of metal hydrogen
balance: metal hydrogen golems are also now immune to most environmental
threats, and get more armor
/🆑
Co-authored-by: ATH1909 <42606352+ATH1909@ users.noreply.github.com>
* Fixes and buffs Metal Hydrogen golems
Co-authored-by: dawsonkeyes <76002401+dawsonkeyes@users.noreply.github.com>
Co-authored-by: ATH1909 <42606352+ATH1909@ users.noreply.github.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
Fixes strange geyser and geyser regen (#72221)
Called the random reagent code after it was initialized
Registered the reagent del/remove signal on the geyser, not the reagent
datum of the geyser
Closes#72037🆑
fix: Strange geysers have random reagents again
fix: Geysers regen reagents again
/🆑
Co-authored-by: Time-Green <timkoster1@hotmail.com>
* Cutting the Burdened Cheese Part 1: Removes free burden points from removing unnecessary or cosmetic organs. (#71938)
Burdened organs now only count for the main organs only. Cyberimplants
don't count, alien organs don't count, etc. This is because someone
could get a bunch of extra organs, and then take the burdened sect and
remove them for free burden points.
Useless organs for species also do not count (stomachs given to species
that do not hunger, for instance)
Removes the error on burden points clamping on negative values. This can
happen when someone previously disabled takes burden sect.
Cheese is being used to bypass the unique gameplay goals burdened sect
provides. Will throw another pr when fikou finishes bat mutants ;)
🆑
fix: Removed some cheese strategies from burdened sect.
/🆑
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
* Modular!
* Aaaaaa
Co-authored-by: tralezab <40974010+tralezab@users.noreply.github.com>
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
Co-authored-by: Funce <funce.973@gmail.com>
* Removes cargo culting from human mob icon update
* Fixes dem conflicts yo
* Updates the screenshots
Co-authored-by: Kyle Spier-Swenson <kyleshome@gmail.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* Biogen shows default reagent container icons instead of beakers (#72247)
## About The Pull Request
With the new crafting menu some reagents now have default container
assigned.
I applied these to visualize reagents in biogen UI too.
<img alt="060ybChTkI"
src="https://user-images.githubusercontent.com/3625094/209483256-e4159a05-46ae-47b8-bc42-9d003cf6c303.png">
## Why It's Good For The Game
Better representation of a reagent.
## Changelog
🆑
qol: Biogenerator shows default reagent containers instead of beakers
/🆑
* Biogen shows default reagent container icons instead of beakers
Co-authored-by: Andrew <mt.forspam@gmail.com>
Co-authored-by: Zonespace <41448081+Zonespace27@users.noreply.github.com>
Abstract away stuff that acts on baseturfs directly into their own procs, and kills some dead code related to baseturfs + tests (#72117)
Adds some new procs relating to baseturfs that replaces some code that
reads and sets them directly. Moves them to their own file. **To
reviewers: Any proc in baseturfs.dm that is snake_case is mine, anything
else is just moved**.
Adds tests for the existing procs of baseturfs.
I'm going to be doing some optimizations to baseturfs that change the
actual representation of baseturfs, and so I'm prepping these to be
implementation agnostic.
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
