* Basic mobs drop their butcher results when gibbed (#78091)
## About The Pull Request
Title.
## Why It's Good For The Game
Fixes#78089
Simple mobs drop their meats when gibbed but basic mobs don't which is
weird and inconsistent.
## Changelog
🆑
fix: fixed basic mobs not dropping their butcher results when gibbed
/🆑
* Basic mobs drop their butcher results when gibbed
---------
Co-authored-by: Sealed101 <cool.bullseye@yandex.ru>
* Basic Watchers & Basilisks (#77630)
## About The Pull Request
This one is a double feature because Watchers and Basilisks share the
same typepath. You might see a couple more of those.
As is tradition I decided to fuck with them rather than just port them.
Here's what's up.
**Basilisks**
- Have a new soulless sprite which looks less like a living blue hedge.
- Walk at you and shoot you while you are not in range (just like
before).
- Become supercharged if they become "heated" by lava, lasers, or
temperature weapons. This was a feature they also previously had but
they would never encounter lava, so now it also works if you use the
wrong gun on them.
- Lose their supercharge if you cool them down.
- Otherwise pretty normal mobs.
**Watchers**
https://www.youtube.com/watch?v=kOq_Bf78k5A
Here's a traditional video of me intentionally getting hit by mechanics
(trust me its definitely on purpose)
- They glow emmissively a little bit so you can see them from further
away.
- Their eyes light up about 0.5 seconds before they are able to shoot at
you.
- No longer melee attack, instead try to stay out of melee.
- Will occasionally put you into "Overwatch", meaning they will shoot
you rapidly if you move or act while they're staring at you for a brief
time period (after which you become immune for 12 seconds, and during
which other watchers will play fair and stop shooting at you).
- If they start taking damage they will also start using their "Gaze"
attack, look away or suffer some kind of negative effect!
- - Normal watcher gaze flashes and confuses you.
- - Magmawing watcher gaze obviously burns (and briefly stuns) you.
- - Icewing watcher gaze freezes you and throws you backwards.
- Magnetically attract and eat diamonds. They also used to do this, but
just if they happened to coincidentally walk past some.
**Other accompanying changes**
All basic mobs will now adopt the "stop gliding" trait if they get
slowed down too much.
I moved behaviour for "fire a projectile from this atom" into a helper
proc because I was using it in three places and I will probably use it
in more places. There are probably other places in the existing code
which could be using this.
I think I made the basic mob melee attack forecast default a little more
forgiving, they were fucking me up too much and I am the playtester.
## Why It's Good For The Game
Another one off the list.
New tricks for old dogs.
Framework for making mobs with ranged attacks "fairer" (you can see when
they are ready to shoot you).
More (hopefully) versatile AI behaviours which we will reuse later (I
hope I'm not duplicating one someone already made).
If our players "enjoy" them enough we can give more mobs "don't look at
me" mechanics.
Removes some soul sprites.
## Changelog
🆑
refactor: Basilisks and Watchers now use the basic mob framework. Please
bug report any unusual behaviour.
sprite: Basilisks have new sprites.
add: Basilisks will go into a frenzy if heated by energy weapons or
temperature beams as well as by lava.
add: Watcher eyes will be illuminated briefly when they are ready to
fire at you.
add: Watchers can now briefly put you into "Overwatch" and penalise you
for moving while they can see you.
add: Wounded watchers will occasionally punish players who look at them.
balance: Unusual watcher variants are more likely to appear.
/🆑
* Basic Watchers & Basilisks
* Modular paths
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com>
* Kills `seconds_per_tick` from status effect `tick`, replaces it with `seconds_between_ticks` to clarify some things (#77219)
## About The Pull Request
https://github.com/tgstation/tgstation/pull/66573#discussion_r861157216
`status_effect/proc/tick(seconds_per_tick)` is wildly misleading and I
feel like I should address it
For a majority of status effects, they process on fast processing but do
not tick every fastprocessing tick
This means that using `seconds_per_tick` here is not giving you the
seconds between status effect ticks, it's giving you seconds between
processing ticks (`0.2`)
This is how it's misleading - If you have a tick interval of `1
SECONDS`, you'd think `seconds_per_tick` is, well, one. But it's
actually one-fifth. So all of your effects are now 80% weaker.
I have replaced the use of `seconds_per_tick` in tick with
`seconds_between_ticks`.
This number is, quite simply, the initial tick interval of the status
effect divided by ten.
An effect with the tick interval of `1 SECONDS` has a
`seconds_between_ticks` of 1.
As a consequence, some things which were inadvertently made weaker, such
as fire and some heretic things (at a glance), are now a little
stronger.
## Why It's Good For The Game
See above. Makes it more clear what you're doing when working with
effects.
## Changelog
🆑 Melbert
code: Updated some status effect tick code to be more clear of how long
is elapsing between ticks. Some effects that were inadvertently weakened
are now stronger as a result (fire and some heretic effects).
/🆑
* Kills `seconds_per_tick` from status effect `tick`, replaces it with `seconds_between_ticks` to clarify some things
* Modular updates
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com>
Mobs can die loudly again (#76580)
## About The Pull Request
Mobs would never emote or make sounds upon death because they set
themselves to "dead" before trying to run the emote and the emote can't
run while you are dead.
Also basic mobs didn't have the "it's dead" examine text, and should.
## Why It's Good For The Game
It's good for mobs to tell you when they have died.
Multiple basic mobs were implemented with this feature and apparently
never tested? Maybe we just broke it recently.
## Changelog
🆑
fix: Mobs can once again emote (with sound) when they die.
fix: Basic mobs will tell you whether they are alive if you examine
them.
/🆑
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>
* 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>
* 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>
* 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>
* makes status tab use signals, thirds the delay between updates (#72002)
## About The Pull Request
status panel for carbons and humans instead of hardcoding stuff, uses
signals (borg material storage too)
removes combat mode indicator in status tab from xenomorphs which have a
button for it, but adds it to simplemobs, since they dont have a visual
indicator
adds status tab stuff to basic mobs, i think they were missing
everything by accident
offsets unique status tab stuff for all mobs by a single line
the delay between updates is a third of what it was before, mainly to
make shuttle timers more accurate (approved by kyler)
## Why It's Good For The Game
much cleaner code, makes future implementations easy
## Changelog
🆑
qol: you can see your combat mode status as a simple or basic mob, and
you can see your health as a basic mob
qol: status panel updates three times as fast
/🆑
* makes status tab use signals, thirds the delay between updates
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
* Basic Mob Carp Part IV: Revived Basic Mobs Look Alive (#71482)
## About The Pull Request
Fourth atomisation of #71421
Pretty basic fix, if you revived basic mobs they'd retain their dead
appearance forever (as well as losing density if they had it).
Now they don't do that.
There's still some work to do to get the Lazarus Injector to work with
Basic Mobs because of how it changes behaviour, and we don't really have
support for that yet. Probably important once it covers more pets
because once Basic Mob Dogs is merged Ian will be temporarily impossible
to revive with the injector (although strange reagent, wands, etc will
still work fine).
I'll get to that eventually.
## Why It's Good For The Game
If something is alive it should look alive.
## Changelog
🆑
fix: A revived basic mob will stand up again rather than inching around
as a living corpse.
/🆑
* Basic Mob Carp Part IV: Revived Basic Mobs Look Alive
Co-authored-by: Jacquerel <hnevard@gmail.com>
Co-authored-by: Zonespace <41448081+Zonespace27@users.noreply.github.com>
* Fixes the riding component not working with basic mobs (#63884)
basic mobs were missing behavior on relaying movement
* Fixes the riding component not working with basic mobs
Co-authored-by: Seth Scherer <supernovaa41@gmx.com>
SkyratBot
