* Admins can now customize the wisdom cow event. (#74045)
## About The Pull Request
Gives admins the ability to customize the spawn location of the cow and
the wisdom that it grants.
## Why It's Good For The Game
Wisdom cows lack any sort of customization at present, this allows
admins to set what type of wisdom which is granted which may be thematic
for events and adding positional spawn support for them is a pretty easy
addition.
## Changelog
🆑
admin: Admins can now customize the wisdom cow event.
/🆑
* Admins can now customize the wisdom cow event.
---------
Co-authored-by: NamelessFairy <40036527+NamelessFairy@users.noreply.github.com>
* Station Trait: Spider Infestation (#73893)
## About The Pull Request
Hate having your cables eaten by mice? Nanotrasen have heard your
complaints and settled on a natural, _organic_, and eco-friendly
solution.
When this station trait is active, roundstart and event mouse spawns
have a chance to instead be replaced with duct spiders (both will exist,
it doesn't remove mice).
Duct spiders are largely harmless to humans, actively hunt other
maintenance creatures (such as mice), and have only one _tiny_ downside.
These mobs can also sometimes be spawned by a minor scrubber clog event.
As a side note, all spider basic mobs with AI (except Araneus) will now
try to automatically fill a small area around them with webs.
Also I made it so that mobs will ignore their random_walking behaviour
if they're engaged in a `do_after`, just in case.
## Why It's Good For The Game
Adds a little bit of variety to things which can slightly annoy you in
maintenance.
Spiders will automatically make places they live in look like spiders
live there.
## Changelog
🆑
add: A station trait which sometimes populates maintenance with small
spiders. You can wear them as a hat if you wanted to have a spider on
your head for some reason.
add: Spider mobs will automatically start webbing up their environment.
/🆑
* Station Trait: Spider Infestation
---------
Co-authored-by: Jacquerel <hnevard@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>
* Fixes dog fashion items not clearing up when removed from the dog & fixes armor vest dog fashion (#73743)
## About The Pull Request
Restores a `cut_overlays()` to dog's `regenerate_icons()` that was lost
back in #70799.
Also makes an armorvest back fashion for armor vests. When a dog fashion
datum doesn't have `obj_icon_state` declared, it defaults to the
assigned item's icon. Dog fashion's sprite sheet has the armor vest
sprite saved as _armor_. And the only vest that would actually show on a
dog would be an _alt_ armor vest. Apparently, the standard-issue armor
vest uses _armoralt_ icons. Go figure.
However, there are quite a few armor vest subtypes that don't look
anything like the base vest; this needs addressing by either banning
such vests from being used as dog fashion items, or making separate
sprites for them (to be fair, the current dog fashion armor vest needs
an update as well, it's quite old and doesn't correspond to the current
armor vest).
- [x] go around and remove dog fashion from armor vests that don't look
like the base vest
## Why It's Good For The Game
Closes#59224 (hats as items were not stuck, but their sprites were);
dog's sprites will correctly update upon placing/removing a fashion item
Most armor vests placed on a dog will actually show on the sprite
## Changelog
🆑
fix: undressing a hat/back item from a dog will correctly remove the
item's overlay
fix: most armor vests will actually show on a dog when placed on its
back
/🆑
* Fixes dog fashion items not clearing up when removed from the dog & fixes armor vest dog fashion
---------
Co-authored-by: Sealed101 <75863639+Sealed101@users.noreply.github.com>
* Corgis now show their ID on examine (#73662)
## About The Pull Request
Lost feature when they were moved to basic mob
## Why It's Good For The Game
The intended feature is now back again !
## Changelog
🆑
fix: Corgis show their ID on examine.
/🆑
* Corgis now show their ID on examine
---------
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
* Fixes bread dog butchering producing error bread and adds some warnings to bread that shouldn't appear in-game. (#73783)
## About The Pull Request
Fixes https://github.com/tgstation/tgstation/issues/73765
Also adds some warnings and description to bread/breadslice so you can
more easily notice that something is wrong.
Not much to discuss i think.
## Why It's Good For The Game
You can get normal bread from butchering bread dog. And potentially less
issues with bread in future.
## Changelog
🆑
fix: fixed butchering bread dog spawning error bread.
/🆑
---------
Co-authored-by: Jacquerel <hnevard@ gmail.com>
* Fixes bread dog butchering producing error bread and adds some warnings to bread that shouldn't appear in-game.
---------
Co-authored-by: Helg2 <93882977+Helg2@users.noreply.github.com>
Co-authored-by: Jacquerel <hnevard@ gmail.com>
* Adds checkgrep for improper or missing atom Initialize args (`mapload`) (#72846)
## About The Pull Request
Adds a grep for atom initialize overrides which does not include mapload
Regex used
`^/(obj|mob|turf|area|atom)/.+/Initialize\((?!mapload).*\)`
Also replaced some space indentation with some tab indentation in some
other greps
## Why It's Good For The Game
See #69107, #61759, #61623
## Changelog
No player facing changes
* Missed by #8374
* Add (mapload) to a //Skyrat Edit so that it passes
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Mice retain their colors when they die. (#73508)
## About The Pull Request
When mice die the corpse they leave behind was always grey, they now
drop correctly colored corpses.
## Why It's Good For The Game
Bug fix.
## Changelog
🆑
fix: Mice will now retain their color when they die.
/🆑
* Mice retain their colors when they die.
---------
Co-authored-by: NamelessFairy <40036527+NamelessFairy@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>
* Makes Shake() proc work (#73480)
## About The Pull Request
Fixes#72321Fixes#70388
The shake proc didn't work and hasn't for ages.
I remember it having worked at some point, but it was quite a long time
ago.
I cannot guarantee that the end result here is the same as it was, the
reason here being that I have no idea how this proc ever worked in the
first place. My limited understanding of the `animate` proc implies that
the previous implementation as written would never have acted as you
would expect it to, but clearly at some time in the past it did work. A
mystery.
As a result of the previous, possibly because the proc never _did_ work
as expected and just did something which looked vaguely correct most of
the time, both the default values and the values people were passing
into this proc were completely ridiculous.
Why would anyone ever want to pixel shift an object with a range of _15_
pixels in all directions? That's half a full tile! And why would you
want it to do this for 25 seconds?
So I also changed the values being passed in, because you really want
pretty small numbers passed into here most of the time.
Here's a video of everything that vibrates:
https://www.youtube.com/watch?v=Q0hoqmaXkKA
The exception is the v8 engine. I left this alone because it seems to
try and start shaking while in your hands, which doesn't work, and I
don't know how to fix that. This has potentially _also_ never worked.
## Why It's Good For The Game
Now you can see intended visual indicators for:
- Lobstrosities charging.
- Beepsky being EMPed.
- The Savannah Ivanov preparing to jump.
- The DNA infuser putting someone through the spin cycle.
- The mystery box admin item I had no previous idea even existed (fun
animations on this one).
- Anything else which wants to use this proc to create vibrating objects
in the future.
## Changelog
🆑
fix: Lobstrosities and Tarantulas will once more vibrate to let you know
they're about to charge at you.
fix: The Savannah Ivanov will once more vibrate to let you know it's
about to jump into the air.
fix: The DNA infuser will now vibrate to let people know that it's busy
blending someone with a dead animal.
/🆑
* Makes Shake() proc work
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
* Adds the Ectoplasmic Outburst, a rare ghost-centric anomaly event (#73024)
## About The Pull Request
This PR description might be a bit rushed because I accidentally
submitted the PR and want to bang out a quick explanation of what this
is before people start asking questions.
Adds a new, rare, ghost-themed anomaly event -- The Ectoplasmic
Outburst.
This event increases in power as more ghosts orbit it, with three
important thresholds to meet.
If 10% or more of all active observers are orbiting the anomaly, an
effect will occur in the nearby area akin to the revenant's defile
spell, damaging flooring, windows, and making a mess.
If 35% or more are orbiting the anomaly, nearby objects in the effect
radius have a chance to become haunted, and will fling themselves at
anyone nearby for a bit. Spooky!
Now, at 50% or more participation, things get serious. Ghosts orbiting
the anomaly will be polled to be brought back into the world for a brief
period as a vengeful spirit, anchored to a SUPER spooky ghost portal.
The portal closes after two minutes (alternatively, smash it with a
toolbox) and deletes all of the ghosts it spawned. Vengeful spirits are
mostly just meant to smash stuff and be a nuisance while they can. It's
a wonderful opportunity to let deadchat desalinate a little.
Oh, also, the anomaly is deadchat controlled. With enough ghosts, you
could theoretically outrun anyone trying to neutralize it!
The associated reactive armor has an effect similar to the anomaly,
haunting nearby objects for a time when the wearer is struck. Not
particularly outstanding, but it can introduce an element of chaos into
a fight that your opponent might not expect.
## Why It's Good For The Game
Anomaly events are great for ghosts. Why not make one tailored just for
them!
Gives admins something to spawn when a wizard has killed half of the
crew but it's not quiiiite time for an ERT.
It's a bit of a silly event with a novelty reward, but I think it's rare
enough not to be a huge issue.
## Changelog
🆑 Rhials
add: Ectoplasmic Outburst anomaly event
add: Reactive Ectoplasm Armor
/🆑
* Adds the Ectoplasmic Outburst, a rare ghost-centric anomaly event
---------
Co-authored-by: Rhials <Datguy33456@gmail.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
* Dominate & Lazarus Inject basic mobs. Lazarus Injected mobs don't fight each other. (#72440)
Fixes#72404
The Lazarus Injector doesn't currently work on basic mobs, but should.
Problem:
The EMPed state of the Lazarus Injector is intended to make a revived
mob hostile to everyone except you, including other mobs you have
revived wtih an EMPed Lazarus Injector.
This is trivial to achieve for Simple Mobs which essentially all share
the same AI, but I could not think of a single workable solution for
Basic Mobs which don't, or at least any which didn't come with a tedious
requirement to closely consider this niche item when programming any
additional AI.
Solution:
Change the default behaviour of the Lazarus Injector so this is not a
problem.
If all it does it make the mob loyal to you _and_ friendly to other mobs
which are loyal to you, then it's pretty easy because we can just use
the existing faction flags.
This is unambiguously a buff to using the item for nefarious purposes as
now if you revive four ice drakes and fulton them onto the station they
won't kill each other until only one is left, but is the only workable
solution I could really think of.
A lot of the very dangerous mining fauna can't be dragged so
transporting your army to the station still poses a question.
The alternate solution was just to replace the AI controller of any
emp-revived basic mob with a "zombie" AI controller, but this has the
problem that
A- It would now make things like cows and dogs into hostile creatures
when they previously weren't.
B- It loses any interesting behaviour the mob previously had and for
cases like Bileworms doesn't even make any sense (they'd try to walk and
just get stuck in place).
This ultimately leads to needing to make bespoke versions for various
mobs, which doesn't seem desirable from a maintainability standpoint.
As a side note it's still not a great idea to revive Bileworms _anyway_
as, their ability to move is tied to their ability to attack so once
they don't have a target they will just kind of sit there and if they
_do_ get a target their attempts to help you fight are difficult to
distinguish from attempts to kill you... but at least being able to
revive them makes it easier to make one sapient if you really want to
trap a player's mind inside a body which is incapable of leaving
lavaland.
Additional edit:
At Fikou's suggestion I've also added a sentience comparison proc to
`mob/living` and removed some code duplication which dealt with this
problem in the sentience/mind transfer potions, as well as added it to
the Dominate spell.
This device is meant to revive mobs and it shouldn't be required for
players to memorise an arbitrary list of which mobs it does and doesn't
work on.
Especially as the goal is eventually that all simple mobs should be
basic mobs.
This way of working is more intuitive, even if it is also stronger. I
was surprised when I used EMPed injectors and my "new minions" just
killed each other.
🆑
fix: You can now revive 'basic mobs' with a Lazarus Injector, such as
dogs, cows, axolotls, or carp.
fix: The same category of mobs can also now be effected by the Runic
Golem Dominate spell.
fix: Basic Mobs will switch target if they can no longer attack their
current target; meaning that if you become a Bileworm's friend it will
stop attacking you.
balance: Mobs injected with the Lazarus Injector while it is EMPed will
no longer attack other mobs revived by EMPed Lazarus Injectors.
/🆑
* Update code/modules/research/xenobiology/xenobiology.dm
* Update code/modules/research/xenobiology/xenobiology.dm
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
Add investigate_deaths (#71112)
## About The Pull Request
Adds INVESTIGATE_DEATHS, an investigate category intended to better show
causes of death.
Also makes suicide_act take a `mob/living` as an argument instead of a
`mob`, and some minor style improvements since apparently I hate
atomicity.
## Why It's Good For The Game
Inspired by a mysterious death and dusting. More logging and leads for
admins investigating deaths.
Also fixes#59028
## Changelog
🆑 Tattle
admin: added investigate deaths to shed some more light on unusual
demises, dustings, and gibbings
/🆑
Co-authored-by: tattle <article.disaster@gmail.com>
(cherry picked from commit ad5debaaa1)
# Conflicts:
# code/datums/dna.dm
# code/game/machinery/washing_machine.dm
# code/game/objects/items/clown_items.dm
# code/game/objects/items/food/misc.dm
# code/game/objects/items/food/monkeycube.dm
# code/game/objects/items/stacks/sheets/glass.dm
# code/game/objects/items/storage/toolbox.dm
# code/game/objects/items/tools/crowbar.dm
# code/game/objects/items/tools/screwdriver.dm
# code/game/objects/items/tools/wrench.dm
# code/game/objects/items/weaponry.dm
# code/game/objects/structures/petrified_statue.dm
# code/modules/antagonists/heretic/magic/nightwatcher_rebirth.dm
# code/modules/mob/living/carbon/human/death.dm
# code/modules/mob/living/living_defense.dm
# code/modules/mob/living/simple_animal/guardian/guardian.dm
# code/modules/mob/living/simple_animal/hostile/headcrab.dm
# code/modules/paperwork/stamps.dm
# code/modules/reagents/chemistry/reagents/cat2_medicine_reagents.dm
# code/modules/reagents/chemistry/reagents/toxin_reagents.dm
# code/modules/shuttle/on_move.dm
# code/modules/spells/spell_types/touch/smite.dm
# code/modules/vehicles/mecha/equipment/tools/mining_tools.dm
Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com>
* Adds nutriment factor to liquid gibs. (#73033)
## About The Pull Request
Over the years I've heard quite a few lizard players scratch their heads
in confusion due to the lack of gibs filling you up. I gave it a fairly
low value of 2 so people don't end up trying to power game it.
## Why It's Good For The Game
Adding an alternative use to gibs is always nice, at the moment it's
mostly just used for soap and cytology (Which barely anyone does.)
## Changelog
🆑
balance: Gibs now provide a small amount of nutriment.
/🆑
* Fixes the modular uses of liquid gibs
* Fixes an error that somehow slipped through.
---------
Co-authored-by: carshalash <carshalash@gmail.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* [no gbp] Dehydrated Carp will follow orders correctly (#73079)
## About The Pull Request
Fixes#72914
The order of operations here were wrong, such that it was calling a proc
which sent signals to inform a component about a new "master" before
actually adding the component.
I switched the proc calls around so that now it adds the component
before telling the component that there is someone to listen to.
## Why It's Good For The Game
Item you spent a valuable single telecrystal on did not work as
advertised, now does.
## Changelog
🆑
fix: Rehydrated Carp should now properly recognise who is the boss and
follow their instructions.
/🆑
* [no gbp] Dehydrated Carp will follow orders correctly
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
Adds Axolotls to List of Cytology Creatures (#72924)
## About The Pull Request
Adds axolotls to list of cytology creatures. Edits the name of the cells
for frogs by changing to "anura amphibian cells" and for axolotls,
"caudata amphibian cells." These mean both "frog" and "salamander"
amphibian cells respectively. Also makes axolotls swabbable, adds their
cell lines to fern's list, and they are now distinguishable from the
frog's reagent lists.
## Why It's Good For The Game
Adding more thing to cytology is always good. Frogs could be grown but
not axolotls despite them coming from the same place and are amphibians.
Adds more ways to get axolotls and another reason why you should do
cytology.
Reinforces the PR
([https://github.com/tgstation/tgstation/pull/72922](url)) I added for
amphibian cytology.
## Changelog
🆑
add: Axolotl lovers rejoice! I added axolotls to cytology and as such
are now swabbable.
add: Frog cells are now named "anura amphibian cells." This literally
means "frog amphibian cells."
add: Axolotl are "caudata amphibian cells." This literally means
"salamander amphibian cells."
/🆑
---------
Co-authored-by: ophaq <44999764+ophaq@users.noreply.github.com>
Co-authored-by: kawoppi <94711066+kawoppi@users.noreply.github.com>
* Basic mobs don't become dense upon death (#72554)
## About The Pull Request
In #72260 what was previously a var became a flag, which was a sensible
change, however this inverted the default behaviour.
In virtually all cases we want dead mobs to _stop_ being dense, this
added a requirement for the flag to be present for that to happen and
then didn't add the flag to any mobs.
Rather than add this to every mob I inverted the function of the flag.
My reasoning here is that _simple_ mobs seemingly never required this
behaviour, basic mobs are probably going to need it rarely if ever, and
including it in `basic_mob_flags` by default seems messy and easy to
leave off when setting other flags (plus #72524 implies to me we want to
avoid adding more default values).
Setting this manually on each mob seems kind of silly as a requirement
going forward and I can't think of a way we'd unit test for people
forgetting.
For the same reason I did the same thing with the
`STOP_ACTING_WHILE_DEAD` flag I added to the AI controller in a recent
PR, the flag should denote unusual behaviour not the default.
## Why It's Good For The Game
It looks really odd when you're constantly shuffling places with dead
mobs, they're not supposed to do that.
It's tedious to add `STOP_ACTING_WHILE_DEAD` to every AI controller when
that should be an obvious default assumption.
## Changelog
🆑
fix: Dead basic mobs are no longer "dense" objects and can be stepped
on.
/🆑
* Basic mobs don't become dense upon death
* Removes a flag we didn't need anymore.
* Forgot to remove this one
Co-authored-by: Jacquerel <hnevard@gmail.com>
Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* New Mob [Garden Gnomes] (#72672)
## About The Pull Request
Garden gnomes can go into the ground when they stand still for a while.
If they are damaged and underground they will heal. If they are
underground they will also gain damage resistance. They can make people
trip when underground and deal some damage. They are available through
golden slime cores or you can collect them from cargo with an emag. If
one of them gets damaged they will all retaliate against the attacker.
They have a very realistic colour pallet based on online gathered data.
Depending on their colour pallets some of them have a very low chance of
spawning.
## Why It's Good For The Game
These new garden gnomes come with expanding the world building of space
station 13. These gnomes will add more variety to the game play and use
an interesting AI and behavior that interacts with the player.
## Changelog
🆑
add: Adds garden gnomes.
imageadd: Adds garden gnome sprites.
/🆑
* New Mob [Garden Gnomes]
Co-authored-by: Comxy <tijntensen@gmail.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>
[READY] DRAMATIC SHUTTLES!! You can now fly around the shuttle (#71906)
You can move around shuttles during transport now! Instead of them
teleporting you instantly into deepspace, you can move around somewhat
depending on your space-mobility and grip-strength.
**Please watch the demonstration aswell, it should answer most
questions:**
https://www.youtube.com/watch?v=Os77qDOVSXE
Interactions:
- Being within armsreach of a wall or solid object means you 'cling',
where the shuttle pull is very weak and you can basically run around the
shutt;e (but dont fuck up or you're gone)
- Being in range of nothing gives you a very heavy pull, you can barely
resist if you have a decent jetpack
- Objects are instantly power-yeeted
- Being pulled or riding something excempts you from hyperspace pull
- Touching a space tile while being on hyperspace dumps you in
deepspace, you either go back to the shuttle or enjoy deepspace
- On shuttle hyperspace tiles are a lot less dangerous, and will instead
launch and freeze you instead of teleporting you into deepspace
- In-case it wasn't obvious, you can rest outside the shuttle as long as
something is blocking your path. I think it's funny but I might nerf it
🆑
add: You can now fly around the shuttle during transit! Woohoo! You can
either cling to the side or grab a jetpack and try and keep up with the
shuttle! Carps can move around freely in hyperspace
qol: Increased shuttle hyperspace size from 8 tiles to 16
/🆑
- [x] Find a way to detect when a shuttle arrives and do something with
the shit left in hyperspace
Things I will do in another PR:
- Engines spit fire and hurt (almost finished but I want to keep this
small)
- Random shuttle events. You might run into dust meteors or migrating
carps OR A CHANGELING INFILTRATOR
- Hyperspace turfs on the shuttle pull you under the shuttle
It's so much more immersive than being instantly teleported into
deepspace. It gives you a chance to recover if you get spaced or for
daredevils to look cool
It's also just very cool idk
Co-authored-by: Time-Green <timkoster1@hotmail.com>
* [NO GBP] Fixes a runtime caused by basic ghost mobs (#72622)
## About The Pull Request
Fixes a runtime that was causing the CI to fail. The Bald hairstyle and
Shaved facial hairstyle had no associated sprites in the hairstyle
global lists. This would cause a runtime when trying to generate the
hair/beard sprite.
Bonus behind-the-scenes picture of the debug process:
## Why It's Good For The Game
I get scared every time Fikou pings me and this will make him stop.
## Changelog
🆑
fix: Bald/Shaved ghosts will no longer cause a runtime and spawn without
a name.
/🆑
* [NO GBP] Fixes a runtime caused by basic ghost mobs
Co-authored-by: Rhials <Datguy33456@gmail.com>
* Basic Faithless Mob (#72479)
## About The Pull Request
Turns the faithless mob into a basic mob with unique behaviors, it will
now break lights and drag around victims bodies. Can also punch open
airlocks if they can be opened.
## Why It's Good For The Game
Now the faithless mob has its own unique behavior and it is cool to see
more AI variety.
## Changelog
🆑
add: Faithless will now also break lights and drag victims around
refactor: Faithless into basic mob
/🆑
* Basic Faithless Mob
* SR
Co-authored-by: Comxy <tijntensen@gmail.com>
Co-authored-by: John Doe <gamingskeleton3@gmail.com>
* Converts ghosts mobs to a basic mob, slightly changes how ghosts are given their identities (#72196)
## About The Pull Request
Performs a very simple conversion of ghosts to basic mobs. They're
relatively lacking in unique behavior in their current state, but they
didn't really have any when they were simple animals either. They
retaliate, they float, they do everything they did before, but now as a
basic mob.
Kilostation and Derelict Station 6 have had their mapped-in ghosts
converted to the new type as well. I'm unsure if there are any other
mapped instances of ghosts that will need changing, but please let me
know if there are.
Also in this PR is a slight rework of how ghost's get their hair/name.
As an ADDED BONUS, ghosts now get random hair to gow ith their randomly
generated names, rather than hair only being only possible through
varediting. (Thank you tattle for helping me figure this out).
## Why It's Good For The Game
Strikes another simple_animal from existence. Gives ghost mobs a bit
more _visual flair_.
## Changelog
🆑
code: Ghosts are now basic mobs! You might not notice any difference,
but...
code: Ghost mobs now spawn with hair and sometimes facial hair.
/🆑
Co-authored-by: Jeremiah <42397676+jlsnow301@ users.noreply.github.com>
* Converts ghosts mobs to a basic mob, slightly changes how ghosts are given their identities
Co-authored-by: Rhials <Datguy33456@gmail.com>
Co-authored-by: Jeremiah <42397676+jlsnow301@ users.noreply.github.com>
Co-authored-by: tastyfish <crazychris32@gmail.com>
* Dogs use the Pet Command system
* modular pets
* modular dogs
* oops
* NO
Co-authored-by: Jacquerel <hnevard@gmail.com>
Co-authored-by: tastyfish <crazychris32@gmail.com>
* Crafting/Cooking menu update
* Yeeted away all of the merge conflicts, time to fix the code
* Okay, now it compiles, and after testing, it seems to work just fine
* Actually, early addition of an upstream fix, so those that don't have hunger can still open the cooking menu
* Fixes the units tests by removing the extra comma in the Stuffed Muli Pod recipe
Co-authored-by: Andrew <mt.forspam@gmail.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com>
AI actions won't unassign each other's movement targets & Mice stop being scared of people if fed cheese (#72130)
## About The Pull Request
Fixes#72116
I've had a persistent issue with basic mob actions reporting this error
and think I finally cracked it
When replanning with `AI_BEHAVIOR_CAN_PLAN_DURING_EXECUTION` it can run
`Setup` on one action leading to the plan changing, meaning that it runs
`finishCommand` to cancel all other existing commands
If you triggered a replan by setting up a movement action in the middle
of another movement action, cancelling the existing action would remove
the target already set by the current one.
We want actions to be able to remove _their own_ movement target but not
if it has been changed by something else in the intervening time.
I fixed this by passing a source every time you set a movement target
and adding a proc which only clears it if you are the source... but this
feels kind of ugly. I couldn't think of anything but if you have a
better idea let me know.
Also while I was doing this I turned it into a feature because I'm
crazy.
If you feed a mouse cheese by hand it will stop being scared of humans
and so will any other mice it attracts from eating more cheese. This is
mostly because I think industrial mouse farming to pass cargo bounties
is funny.
Mice controlled by a Regal Rat lose this behaviour and forget any past
loyalties they may have had.
https://user-images.githubusercontent.com/7483112/208779368-3bd1da0f-4191-4405-86e5-b55a58c2cd00.mp4
Oh also I removed a block about cancelling if you have another target
from the "hunt" behaviour, everywhere using this already achieves that
simply by ordering the actions in expected priority order and it was
messing with how I expected mice to work.
Now if they happen to stop by some cheese they will correctly stop
fleeing in order to eat it before continuing to run away.
## Why It's Good For The Game
Fixes a bug I kept running into.
Makes it possible to set up a mouse farm without them screaming
constantly.
Lets people more easily domesticate mice to support Ratatouille
gameplay.
## Changelog
🆑
add: Mice who are fed cheese by hand will accept humans as friends, at
least until reminded otherwise by their rightful lord.
fix: Fixed a runtime preventing mice from acting correctly when trying
to flee and also eat cheese at the same time.
/🆑
Co-authored-by: Jacquerel <hnevard@gmail.com>
* Adds mobroach to the game. Stronger glockroach (#72426)
Adds a stronger glockroach, with a lil hat and a tommygun. This roach
has a 4 shot burst on a 2 second cooldown.
Co-authored-by: tattle <66640614+dragomagol@ users.noreply.github.com>
* Adds mobroach to the game. Stronger glockroach
Co-authored-by: khevy <64374321+khevy@users.noreply.github.com>
Co-authored-by: tattle <66640614+dragomagol@ users.noreply.github.com>
* Basic Mobs can run away (#71963)
## About The Pull Request
That's right I'm still atomising #71421, some day I might even post
something related to carp.
This PR adds various behaviours to basic mobs allowing them to run away,
in a couple of variations.
Mice will flee from anyone who doesn't share their factions, at all
times (so they will scatter from most humans, but not regal rats).
Rabbits and Sheep will flee from anyone who has attacked them.
Pigs will run away from people who have attacked them, but only if
they're below half health.
https://user-images.githubusercontent.com/7483112/207127135-d1737f91-d3f7-468a-ac60-7c7ae5d6623d.mp4
Mice are still plenty catchable because they don't run _very far_ (or
very fast) but I think the chase will be good enrichment.
To achieve this I had to change the signal COMSIG_CARBON_HEALTH_UPDATE
into COMSIG_LIVING_HEALTH_UPDATE but frankly the latter seems more
sensible anyway.
## Why It's Good For The Game
More behaviours to use later when designing mobs, gradually gives mobs
more things to do rather than just sort of moving aimlessly around the
area you left them in.
It'll give people hunting rats in maintenance some exercise.
## Changelog
🆑
add: Mice will now run away from you, you have to catch them if you want
to eat them. Use those traps!
add: Rabbits, Sheep, and Pigs likewise won't just sit there and let you
pulverise them if they can see an escape route.
/🆑
* Basic Mobs can run away
* Modular!
Co-authored-by: Jacquerel <hnevard@gmail.com>
Co-authored-by: Funce <funce.973@gmail.com>
SkyratBot
