## About The Pull Request
Deletes `can_hear`, replaces it with trait-checking deafness.
The only two non-trait sources of deafness (hardcrit and lacking ears)
were refactored into using the trait.
## Why It's Good For The Game
Many places inconsistently check for the deaf trait rather than use
can_hear which meant behavior was not consistent.
Some code would treat "do we lack ears?" as being deaf, some would not.
This unifies all the behavior so being deaf means you're deaf
everywhere.
It also means we can now easily react to gaining and losing deafness via
signal, where before we could not react to it without hooking the trait,
organ remove, AND stat change. Which no one did, of course, because who
would ever think to do that?
## Changelog
🆑 Melbert
refactor: Refactored how deafness is tracked. Please report any weird
interactions with sounds, like messages or sfx being missing.
fix: Lacking ears and being in hard crit now consistently treats you as
"being deaf". This affects a few minor interactions like empath, the
jukebox, and sleeping.
/🆑
## About The Pull Request
So this nice way of explicitly override an emote type exists, but for
some reason it is not properly used and mostly nonfunctional.
Custom emotes, a perfect use case for these, was just... mutating the
singleton and then resetting it back, instead of actually making use of
args.
Sinful. Just sinful.
<details><summary> It does work, note the type override from the prompt
making its way where needed. </summary>
<img width="209" height="206" alt="dreamseeker_DRS9nFqoQP"
src="https://github.com/user-attachments/assets/35cbac9b-600f-4060-938e-519e110f330d"
/>
<img width="308" height="493" alt="Code_ZQfaj3GGSu"
src="https://github.com/user-attachments/assets/6847e070-d11f-4a32-90fa-edbb5e869e13"
/>
</details>
## Why It's Good For The Game
Fixes a likely oversight/coding skill issue. Improves code modularity.
## Changelog
Nothing anyone would notice, if this is working correctly.
## About The Pull Request
Add a new volume pref in game options that controls how loud emotes that
have sound effects are.
Note: This PR was made to fulfill a bounty by @NanoCats
## Why It's Good For The Game
Quality of life improvement, we have many emotes that play sounds here
and not everyone wants to hear them. Also there's that one scream that's
insanely fucking loud
## Proof Of Testing
<details>
<summary>Screenshots/Videos</summary>
Note: the emote cooldown was disabled in this video for demonstration
purposes
https://github.com/user-attachments/assets/1e465ad1-6be9-4113-a564-72ace0c78118
</details>
## Changelog
🆑
qol: added a volume slider for emote sounds to game options
/🆑
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
So I was running into the bit where custom emotes actually don't get the
`+|_` emphasis formatting applied to them, _except_ for the runechat
portion which *does*.
This felt annoying, especially given I've seen a lot of people try it
and have it not work.
Add to that that your own emotes would keep getting highlighted,
blotting out other people mentioning your highlighted messages, and
here's this pr.
In this pr we add a few flags to audible/visible messages,
`WITH_EMPHASIS_MESSAGE` and `BLOCK_SELF_HIGHLIGHT_MESSAGE`, which
respectively apply emphasis formatting and block highlighting the
message to oneself.
We're doing this with flags because I felt always applying this would be
unnecessary. Most audible/visible messages won't need to check for
formatting, and quite a lot we *do* want to be highlighted.
As such, we apply these flags as need be.
For emotes we do this by having `get_message_flags(intentional)`, which
applies `BLOCK_SELF_HIGHLIGHT_MESSAGE` based on whether the message is
intentional, and on the custom emote subtype applies
`WITH_EMPHASIS_MESSAGE`.
Because it's not just for _say_ anymore, and already was also used for
emote runechats, we rename `say_emphasis(input)` into
`apply_message_emphasis(input)`. We additionally move it down to `/atom`
from `/atom/movable`, such that visible/audible messages can in fact
call it.
That resolves our issues.
We also apply `BLOCK_SELF_HIGHLIGHT_MESSAGE` to sign language tone
messages, as they're essentially a part of speech.
<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->
Being able to do `+|_` emphasis formatting on your emotes is nice, I've
seen a lot of people try it and have it not work.
Especially weird given it DOES apply to the runechat message, just not
the text chat message.
It's annoying when your own emotes trip your own highlights! Like if you
have a name highlight, your own emotes getting constantly highlighted
would blot out other people talking to you.
So having your own emotes not trip it just like your own talking makes
that less of a pain.
But sometimes emotes are forced, and in that case I think it's better to
keep the highlight because it's just like other people's messages
information the player might want to be notified of.
Generally, I think if it's the player's input it probably shouldn't be
highlighted, while if it isn't the player's input it probably should.
There's no need for us to ever highlight our own sign language tone
messages, because they're essentially a part of our talking.
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
<!-- 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 its 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: When performing a custom emote, `+|_` emphasis formatting applies
to the text chat message instead of just the runechat message.
qol: Intentional emotes don't trip your own highlights.
qol: Sign language tone messages don't trip your own highlights.
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
So I was running into the bit where custom emotes actually don't get the
`+|_` emphasis formatting applied to them, _except_ for the runechat
portion which *does*.
This felt annoying, especially given I've seen a lot of people try it
and have it not work.
Add to that that your own emotes would keep getting highlighted,
blotting out other people mentioning your highlighted messages, and
here's this pr.
In this pr we add a few flags to audible/visible messages,
`WITH_EMPHASIS_MESSAGE` and `BLOCK_SELF_HIGHLIGHT_MESSAGE`, which
respectively apply emphasis formatting and block highlighting the
message to oneself.
We're doing this with flags because I felt always applying this would be
unnecessary. Most audible/visible messages won't need to check for
formatting, and quite a lot we *do* want to be highlighted.
As such, we apply these flags as need be.
For emotes we do this by having `get_message_flags(intentional)`, which
applies `BLOCK_SELF_HIGHLIGHT_MESSAGE` based on whether the message is
intentional, and on the custom emote subtype applies
`WITH_EMPHASIS_MESSAGE`.
Because it's not just for _say_ anymore, and already was also used for
emote runechats, we rename `say_emphasis(input)` into
`apply_message_emphasis(input)`. We additionally move it down to `/atom`
from `/atom/movable`, such that visible/audible messages can in fact
call it.
That resolves our issues.
We also apply `BLOCK_SELF_HIGHLIGHT_MESSAGE` to sign language tone
messages, as they're essentially a part of speech.
<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->
Being able to do `+|_` emphasis formatting on your emotes is nice, I've
seen a lot of people try it and have it not work.
Especially weird given it DOES apply to the runechat message, just not
the text chat message.
It's annoying when your own emotes trip your own highlights! Like if you
have a name highlight, your own emotes getting constantly highlighted
would blot out other people talking to you.
So having your own emotes not trip it just like your own talking makes
that less of a pain.
But sometimes emotes are forced, and in that case I think it's better to
keep the highlight because it's just like other people's messages
information the player might want to be notified of.
Generally, I think if it's the player's input it probably shouldn't be
highlighted, while if it isn't the player's input it probably should.
There's no need for us to ever highlight our own sign language tone
messages, because they're essentially a part of our talking.
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
<!-- 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 its 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: When performing a custom emote, `+|_` emphasis formatting applies
to the text chat message instead of just the runechat message.
qol: Intentional emotes don't trip your own highlights.
qol: Sign language tone messages don't trip your own highlights.
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
## About The Pull Request
So I was running into the bit where custom emotes actually don't get the
`+|_` emphasis formatting applied to them, _except_ for the runechat
portion which *does*.
This felt annoying, especially given I've seen a lot of people try it
and have it not work.
Add to that that your own emotes would keep getting highlighted,
blotting out other people mentioning your highlighted messages, and
here's this pr.
In this pr we add a few flags to audible/visible messages,
`WITH_EMPHASIS_MESSAGE` and `BLOCK_SELF_HIGHLIGHT_MESSAGE`, which
respectively apply emphasis formatting and block highlighting the
message to oneself.
We're doing this with flags because I felt always applying this would be
unnecessary. Most audible/visible messages won't need to check for
formatting, and quite a lot we *do* want to be highlighted.
As such, we apply these flags as need be.
For emotes we do this by having `get_message_flags(intentional)`, which
applies `BLOCK_SELF_HIGHLIGHT_MESSAGE` based on whether the message is
intentional, and on the custom emote subtype applies
`WITH_EMPHASIS_MESSAGE`.
Because it's not just for _say_ anymore, and already was also used for
emote runechats, we rename `say_emphasis(input)` into
`apply_message_emphasis(input)`. We additionally move it down to `/atom`
from `/atom/movable`, such that visible/audible messages can in fact
call it.
That resolves our issues.
We also apply `BLOCK_SELF_HIGHLIGHT_MESSAGE` to sign language tone
messages, as they're essentially a part of speech.
<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->
## Why It's Good For The Game
Being able to do `+|_` emphasis formatting on your emotes is nice, I've
seen a lot of people try it and have it not work.
Especially weird given it DOES apply to the runechat message, just not
the text chat message.
It's annoying when your own emotes trip your own highlights! Like if you
have a name highlight, your own emotes getting constantly highlighted
would blot out other people talking to you.
So having your own emotes not trip it just like your own talking makes
that less of a pain.
But sometimes emotes are forced, and in that case I think it's better to
keep the highlight because it's just like other people's messages
information the player might want to be notified of.
Generally, I think if it's the player's input it probably shouldn't be
highlighted, while if it isn't the player's input it probably should.
There's no need for us to ever highlight our own sign language tone
messages, because they're essentially a part of our talking.
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
## Changelog
<!-- 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 its 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: When performing a custom emote, `+|_` emphasis formatting applies
to the text chat message instead of just the runechat message.
qol: Intentional emotes don't trip your own highlights.
qol: Sign language tone messages don't trip your own highlights.
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
## About The Pull Request
defaults:
```php
/// How long is the shared emote cooldown triggered by this emote?
var/general_emote_audio_cooldown = 2 SECONDS
/// How long is the specific emote cooldown triggered by this emote?
var/specific_emote_audio_cooldown = 5 SECONDS
```
specific cooldown only checks for the emote, while the general is a
shared cooldown, gave laugh and scream longer specific cooldowns.
## Why It's Good For The Game
The general emote cooldown fixed the problem of multiple emotes getting
used at once, now we have a problem with people using the same emote too
many times, I want to give the players ability to use sounds in their
emotes, but spamming the same emote over and over again makes me regret
it and hesitant about it, this way we can have the best of both worlds.
## Changelog
🆑 grungussuss
sound: along with the shared emote cooldown, specific emote audio
cooldown has returned.
/🆑
# Conflicts:
# code/datums/emotes.dm
## About The Pull Request
Removes all remnants of the broken SR emote cooldown, reverting back to
standard TG.
## Why It's Good For The Game
Cooldown on emotes work properly, people can flip again (without
beyblading.)
## Proof Of Testing
<details>
<summary>Screenshots/Videos</summary>
https://github.com/user-attachments/assets/8cbda9aa-ba78-4082-a620-d4ac93f8df65
</details>
## Changelog
🆑 LT3
fix: Emote cooldowns work properly
del: Removed Freerunning restriction on the flip emote
/🆑
## About The Pull Request
Added the FOSBURY skillchip, found in hacked toy vendors.
This skillchip allows you to bypass the emote cooldown when flipping or
spinning. However, if used too often, it will lower the chip's
integrity. At first, this is harmless, emitting sparks only, but at a
certain point, your head starts smoking, your brain begins
short-circuiting, and once the chip has lost all integrity your head
will explode in a shower of gore, giving you a cranial fissure!
Added the Chipped quirk. It allows you to spawn with one skillchip. Of
note here is that the only chips you can spawn with are the 'default'
skillchips found in the toy vendor, you can NOT spawn in with the
fosbury chip or with the musical one.
Added the Chip Connector quirk. It contains a new implant, the chip
connector, which allows you to install and take out skillchips at any
time. Being EMPed will cause it to drop one random skillchip, and if you
try using it while it's malfunctioning you'll take out a bit of your
brain instead. It can also be made at the exosuit fabricator after basic
research.
Renamed the organ slots for brain implants and made the connector
implant take the CNS slot.
## Why It's Good For The Game
> Added the FOSBURY skillchip, found in hacked toy vendors.
This skillchip allows you to bypass the emote cooldown when flipping or
spinning. However, if used too often, it will lower the chip's
integrity. At first, this is harmless, emitting sparks only, but at a
certain point, your head starts smoking, your brain begins
short-circuiting, and once the chip has lost all integrity your head
will explode in a shower of gore, giving you a cranial fissure!
During the time flipping was bugged to have no cooldown or delay, it was
really funny seeing people flip at increasingly higher speeds. Many
people miss it, and to be honest, so do I. But everything needs limits
or it stops being funny and ends up being overdone. To this end this
skillchip lets people relive those days of glory, until they go out in a
beautiful explosion. The chip will last a very long while if well taken
care of, and there are plenty of warning signs before it gets too risky
to use, but we know what players are actually gonna do, and I am looking
forward to it.
> Added the Chipped quirk. It allows you to spawn with one skillchip. Of
note here is that the only chips you can spawn with are the 'default'
skillchips found in the toy vendor, you can NOT spawn in with the
fosbury chip or with the musical one.
Chips can be kind of neat sometimes, and I think always having one as
part of your character can make for some fun things as the consistency
of it makes it more likely to stick in your mind to do stuff with.
> 'but can't you just go to the vendor at the start of every shift?'
Sure. But we have loadouts. We have tagger, musician, and many other
things that are 'roundstart bloat', and while that by itself is not an
excuse, it's part of the design of character setup: Minimizing the time
spent running around the station for things your character is supposed
to have for their personality/roleplay/gimmick. They're paying the cost
of quirk points for it, anyways.
> Added the Chip Connector quirk. It contains a new implant, the chip
connector, which allows you to install and take out skillchips at any
time. Being EMPed will cause it to drop one random skillchip, and if you
try using it while it's malfunctioning you'll take out a bit of your
brain instead. It can also be made at the exosuit fabricator after basic
research.
I like the idea of having a gross usb drive on the back of your brain
that you shove chips into and out of, especially if it drops pieces of
your brain when malfunctioning. It also adds a little bit of extra
relevance to skillchips now that you don't need to spend 15 (!!!)
seconds inside a skillstation to add one. The cost is, as stated, quite
literally losing your brain on EMP's and the moderately expensive sum of
4 points.
> Renamed the organ slots for brain implants and made the connector
implant take the CNS slot.
It annoys me that there were organ slots for 'anti drop implant'. Now
they're just slots for anything meant to connect to the
cerebellum/central nervous system, making it less brute forcey and also
adding the start of some fun exclusivity between brain implants.
## Changelog
🆑
add: Added the FOSBURY skillchip, found in hacked toy vendors. This
skillchip allows you to bypass the emote cooldown when flipping or
spinning. However, if used too often, it will lower the chip's integrity
and cause malfunctions.
add: Added the Chipped quirk. It allows you to spawn with one base
skillchip. (not the one above)
add: Added the Chip Connector quirk. It contains a new implant, the chip
connector, which allows you to install and take out skillchips at any
time.
code: Renamed the organ slots for brain implants and made the connector
implant take the CNS slot.
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
# Conflicts:
# code/datums/emotes.dm
## About The Pull Request
closes https://github.com/tgstation/tgstation/issues/87274
## Why It's Good For The Game
vocal chords work differently to instruments and other sfx, a lower
range of pitch variance is more natural.
## Changelog
🆑 grungussuss
sound: emote pitch shifting has been fixed
/🆑
## About The Pull Request
Closes#87274
If TTS is enabled and supports vocal pitch, certain emotes will have a
far smaller frequency range but will become affected by your chosen TTS
pitch. Frequency equation is non-linear as pitch scales from -12 to 12
## Why It's Good For The Game
Makes vocal emotes a bit more immersive as now they'll fit your
character's tone.
## Changelog
🆑
add: TTS pitch now affects emote sounds
/🆑
3591 individual conflicts
Update build.js
Update install_node.sh
Update byond.js
oh my fucking god
hat
slow
huh
holy shit
we all fall down
2 more I missed
2900 individual conflicts
2700 Individual conflicts
replaces yarn file with tg version, bumping us down to 2200-ish
Down to 2000 individual conflicts
140 down
mmm
aaaaaaaaaaaaaaaaaaa
not yt
575
soon
900 individual conflicts
600 individual conflicts, 121 file conflicts
im not okay
160 across 19 files
29 in 4 files
0 conflicts, compiletime fix time
some minor incap stuff
missed ticks
weird dupe definition stuff
missed ticks 2
incap fixes
undefs and pie fix
Radio update and some extra minor stuff
returns a single override
no more dupe definitions, 175 compiletime errors
Unticked file fix
sound and emote stuff
honk and more radio stuff
## About The Pull Request
defaults:
```php
/// How long is the shared emote cooldown triggered by this emote?
var/general_emote_audio_cooldown = 2 SECONDS
/// How long is the specific emote cooldown triggered by this emote?
var/specific_emote_audio_cooldown = 5 SECONDS
```
specific cooldown only checks for the emote, while the general is a
shared cooldown, gave laugh and scream longer specific cooldowns.
## Why It's Good For The Game
The general emote cooldown fixed the problem of multiple emotes getting
used at once, now we have a problem with people using the same emote too
many times, I want to give the players ability to use sounds in their
emotes, but spamming the same emote over and over again makes me regret
it and hesitant about it, this way we can have the best of both worlds.
## Changelog
🆑 grungussuss
sound: along with the shared emote cooldown, specific emote audio
cooldown has returned.
/🆑
## About The Pull Request
Added the FOSBURY skillchip, found in hacked toy vendors.
This skillchip allows you to bypass the emote cooldown when flipping or
spinning. However, if used too often, it will lower the chip's
integrity. At first, this is harmless, emitting sparks only, but at a
certain point, your head starts smoking, your brain begins
short-circuiting, and once the chip has lost all integrity your head
will explode in a shower of gore, giving you a cranial fissure!
Added the Chipped quirk. It allows you to spawn with one skillchip. Of
note here is that the only chips you can spawn with are the 'default'
skillchips found in the toy vendor, you can NOT spawn in with the
fosbury chip or with the musical one.
Added the Chip Connector quirk. It contains a new implant, the chip
connector, which allows you to install and take out skillchips at any
time. Being EMPed will cause it to drop one random skillchip, and if you
try using it while it's malfunctioning you'll take out a bit of your
brain instead. It can also be made at the exosuit fabricator after basic
research.
Renamed the organ slots for brain implants and made the connector
implant take the CNS slot.
## Why It's Good For The Game
> Added the FOSBURY skillchip, found in hacked toy vendors.
This skillchip allows you to bypass the emote cooldown when flipping or
spinning. However, if used too often, it will lower the chip's
integrity. At first, this is harmless, emitting sparks only, but at a
certain point, your head starts smoking, your brain begins
short-circuiting, and once the chip has lost all integrity your head
will explode in a shower of gore, giving you a cranial fissure!
During the time flipping was bugged to have no cooldown or delay, it was
really funny seeing people flip at increasingly higher speeds. Many
people miss it, and to be honest, so do I. But everything needs limits
or it stops being funny and ends up being overdone. To this end this
skillchip lets people relive those days of glory, until they go out in a
beautiful explosion. The chip will last a very long while if well taken
care of, and there are plenty of warning signs before it gets too risky
to use, but we know what players are actually gonna do, and I am looking
forward to it.
> Added the Chipped quirk. It allows you to spawn with one skillchip. Of
note here is that the only chips you can spawn with are the 'default'
skillchips found in the toy vendor, you can NOT spawn in with the
fosbury chip or with the musical one.
Chips can be kind of neat sometimes, and I think always having one as
part of your character can make for some fun things as the consistency
of it makes it more likely to stick in your mind to do stuff with.
> 'but can't you just go to the vendor at the start of every shift?'
Sure. But we have loadouts. We have tagger, musician, and many other
things that are 'roundstart bloat', and while that by itself is not an
excuse, it's part of the design of character setup: Minimizing the time
spent running around the station for things your character is supposed
to have for their personality/roleplay/gimmick. They're paying the cost
of quirk points for it, anyways.
> Added the Chip Connector quirk. It contains a new implant, the chip
connector, which allows you to install and take out skillchips at any
time. Being EMPed will cause it to drop one random skillchip, and if you
try using it while it's malfunctioning you'll take out a bit of your
brain instead. It can also be made at the exosuit fabricator after basic
research.
I like the idea of having a gross usb drive on the back of your brain
that you shove chips into and out of, especially if it drops pieces of
your brain when malfunctioning. It also adds a little bit of extra
relevance to skillchips now that you don't need to spend 15 (!!!)
seconds inside a skillstation to add one. The cost is, as stated, quite
literally losing your brain on EMP's and the moderately expensive sum of
4 points.
> Renamed the organ slots for brain implants and made the connector
implant take the CNS slot.
It annoys me that there were organ slots for 'anti drop implant'. Now
they're just slots for anything meant to connect to the
cerebellum/central nervous system, making it less brute forcey and also
adding the start of some fun exclusivity between brain implants.
## Changelog
🆑
add: Added the FOSBURY skillchip, found in hacked toy vendors. This
skillchip allows you to bypass the emote cooldown when flipping or
spinning. However, if used too often, it will lower the chip's integrity
and cause malfunctions.
add: Added the Chipped quirk. It allows you to spawn with one base
skillchip. (not the one above)
add: Added the Chip Connector quirk. It contains a new implant, the chip
connector, which allows you to install and take out skillchips at any
time.
code: Renamed the organ slots for brain implants and made the connector
implant take the CNS slot.
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
123 changed files and multiple crashes after writing broken regex, I
replaced most remains of direct spans with macros. This cleans up the
code and makes it easier to work with in general, see justification for
the original PR. I also fixed a bunch of broken and/or unclosed spans
here too.
I intentionally avoided replacing spans with multiple classes (in most
cases) and spans in the middle of strings as it would impact readability
(in my opinion at least) and could be done later if required.
## Why It's Good For The Game
Cleaner code, actually using our macros, fixes borked HTML in some
places. See original PR.
## Changelog
Nothing player-facing
## About The Pull Request
all audible emotes share a cooldown now, that means, for example:
emoting `*scream` will play a sound, then emoting `*cry`, if the
cooldown for `*scream` hasn't passed, will not play a sound for the
`*cry`, but will still play the emote. Note - all audible emotes have a
default audible cooldown of 2 seconds, unless overriden on some emotes.
## Why It's Good For The Game
- prevents people from spamming multiple audio emotes in quick
succession.
- allows us to add more emote sounds without fear of players abusing
them for spam.
- less audio from emotes makes the audible emotes more special and less
ear-fatigue-ing
- forces players to be more considerate with what audible emote they
use, increasing quality of their usage for roleplay.
## About The Pull Request
Added a var to emotes for ignoring walls when playing their sound, now
only the scream emote can ignore walls.
## Why It's Good For The Game
It's really annoying and stupid that you can hear people crying through
walls and doesn't make sense at all.
## Changelog
🆑 grungussuss
sound: only the scream emote can be heard through walls
/🆑
## About The Pull Request
Currently, each time someone flip, the cooldown is halved. Whoops.
Also, COMSIG_MOB_PRE_EMOTED doesn't prevent the emote from running,
because it isn't allowed to return FALSE inside the `run_emote` proc, so
we moved the checks up to the comsig behind the `run_emote` call.
## Why It's Good For The Game
Fixing stuff.
## Changelog
🆑
fix: Fixed beyblade *flipping.
/🆑
## About The Pull Request
### EDITED, see spoiler for previous about section.
This pr adds the `TRAIT_SILICON_EMOTES_ALLOWED`, which is now used to
determine what can perform silicons emotes instead of typechecks.
We do this by adding a `trait_required` var to emotes, which if set is
checked for in `can_run_emote(...)` and means the mob must have that
trait to use the emote.
We then adds this trait to all of the mobs previously capable of using
silicon emotes and the beep emote, being:
All silicons, basic bots, simple bots, orbies, and brain mobs.
In addition, we add the trait to robotic voicebox users.
Finally, it makes beeping a silicon emote.
What this changes is that robotic voicebox users can beep and use other
silicon emotes, basic and simple bots can actually beep, sentient orbies
could use other silicon emotes, and brains can beep and use silicon
emotes.
Previously brains where on the allowed types list for beeping, but
living emotes also blocked brains generally, so they couldn't _actually_
beep.
<details>
<summary>Previous About Section</summary>
All this really does is add a new trait, `TRAIT_SILICON_EMOTES_ALLOWED`,
which when given to a human allows them to use silicon emotes.
It does this by adding the `/mob/living/carbon/human` type to the
allowed types for these emotes, but then adding an additional check to
`can_run_emote(...)` for these emotes to block it for humans if they
don't have the trait.
We add it to the typecache because the base checks for
`can_run_emote(...)` would block if not for that, but we _do_ want the
other checks it runs.
</details>
## Why It's Good For The Game
I just think it'd be fun, really. Like, _I'd_ want to beep at people
when I'm going out of my way to augment the shit out of my character.
It's an item primarily accessible by roboticists and transhumanists,
both of which are encouraged/required to interact with silicons, so I
think this'd lead to fun interactions for those that do commit to
getting the silicon-speech tongue replacement.
Finally, I mean, it's a funky synthesizer that makes you sound like a
silicon. Why shouldn't it let you synthesize these sounds too? Hell,
even its attack verbs are beeping and booping already.
### EDITED, additional justification:
It's weird for basic/simple bots to be able to use all other silicon
emotes except beeping.
MMI'd brains/posibrains being able to beep looked intentional, just
broken. This fixes that.
I feel we might as well just allow them to use other silicon emotes
while we're at it.
## About The Pull Request
Facehuggers dont make people fall asleep, instead making them unable if
on (already was in), and muffling speech
Xenomorphs still have decent tools to stun people in melee thats stuff
for another pr
muzzle is now an element and also just makes you talk like
word word word -> mmmmf mmmf mf
COMPLETELY evaporates BLOCKS_SPEECH flag
## Why It's Good For The Game
Being instantly sent to sleep by a facehugger thrown the hunter that
materialized from a vent then getting dragged to their goon cave where
you spend 2 minutes to get gibbed so someone else but you can play antag
is just extremely unfun
This should allow you to survive if youre quick enough after getting
hugged instead of being forced to get gibbed, allowing cooler xenomorph
combat (you could try fistfighting the dude or something idk)
- Fixes all emotes being considered audible
- We have a check here: `if(emote_type & (EMOTE_AUDIBLE |
EMOTE_VISIBLE)) //emote is audible and visible` ...Which doesn't work
the way it think it's working.
- The correct way to have done this is `emote_type & (EMOTE_AUDIBLE |
EMOTE_VISIBLE) == (EMOTE_AUDIBLE | EMOTE_VISIBLE)`
- Adds support for runechat only emotes
- Starts by adding this flag to *cough, making coughing only display to
runechat.
- If a player has runechat emotes disabled, these will print to chat
like normal.
- Adds `EMOTE_VISIBLE` to *snap
We have a few emotes that get spammed a metric ton in some events, such
as coughing for smokers who have viruses in smoke clouds. Having "X
coughs!" 100 times in your chat is simply un-necessary, and leaving it
to be more ephemeral (a-la balloon alerts) makes it a bit easier to
parse chat.
🆑 Melbert
qol: Coughing will now no longer print to chat, IE, it is runechat only.
If you have runechat emotes disabled, however, it will still print to
chat.
qol: Snapping now has a visual component.
fix: All emotes are no longer considered audible, meaning blind people
go back to not being able to see people do flips and jumps
fix: However, blind people are now told when they do a visible emote
like flipping (because they can, obviously, feel themselves flipping).
Likewise, deaf people are told when they do some audible emotes, like
coughing or screaming.
/🆑
## About The Pull Request
- Fixes all emotes being considered audible
- We have a check here: `if(emote_type & (EMOTE_AUDIBLE |
EMOTE_VISIBLE)) //emote is audible and visible` ...Which doesn't work
the way it think it's working.
- The correct way to have done this is `emote_type & (EMOTE_AUDIBLE |
EMOTE_VISIBLE) == (EMOTE_AUDIBLE | EMOTE_VISIBLE)`
- Adds support for runechat only emotes
- Starts by adding this flag to *cough, making coughing only display to
runechat.
- If a player has runechat emotes disabled, these will print to chat
like normal.
- Adds `EMOTE_VISIBLE` to *snap
## Why It's Good For The Game
We have a few emotes that get spammed a metric ton in some events, such
as coughing for smokers who have viruses in smoke clouds. Having "X
coughs!" 100 times in your chat is simply un-necessary, and leaving it
to be more ephemeral (a-la balloon alerts) makes it a bit easier to
parse chat.
## Changelog
🆑 Melbert
qol: Coughing will now no longer print to chat, IE, it is runechat only.
If you have runechat emotes disabled, however, it will still print to
chat.
qol: Snapping now has a visual component.
fix: All emotes are no longer considered audible, meaning blind people
go back to not being able to see people do flips and jumps
fix: However, blind people are now told when they do a visible emote
like flipping (because they can, obviously, feel themselves flipping).
Likewise, deaf people are told when they do some audible emotes, like
coughing or screaming.
/🆑
* fixes signal circuit not working | refactors name of timer cooldown macros to be inherent, also docs them (#79367)
## About The Pull Request
Title
## Why It's Good For The Game
Less headache in the future for a macro thats not really obvious in what
it does
## Changelog
🆑
fix: signals in circuits now actually function
/🆑
* fixes signal circuit not working | refactors name of timer cooldown macros to be inherent, also docs them
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
## About The Pull Request
Title
## Why It's Good For The Game
Less headache in the future for a macro thats not really obvious in what
it does
## Changelog
🆑
fix: signals in circuits now actually function
/🆑
* Canonizes Robot Yawns (#78175)
## About The Pull Request
Closes#77592
I agree that it's silly that robots shouldn't be able to yawn, but I
think that instead of removing the potential for this interaction to
occur outright (which can be done with moving around a check), it should
be embraced instead.
## Why It's Good For The Game
Robots fake-yawning to make them feel more realistic to the workers of
the station (and if they aren't station based, their once-creators
(which is fine because we removed swarmers)) and not being exempt from a
really cutesy niche interaction greatly appeals to me.
## Changelog
🆑
add: Ever see a robot yawn? Don't worry, it makes sense now.
/🆑
* Canonizes Robot Yawns
---------
Co-authored-by: san7890 <the@san7890.com>
Alexis