## About The Pull Request
This provides a work around for issue: #92706
Which prevents user from using uplink.
YES -> A new verb called "Reset UI Positions". It puts them all to the
0,0 location which is top left of screen.
YES, too! -> Holding ALT and clicking the background of the window will
allow you to move it.
## Why It's Good For The Game
This provides ADMINs two ways to help antags that get their uplink page
stuck.
## About The Pull Request
@Metekillot
Continues https://github.com/tgstation/tgstation/pull/92053https://github.com/tgstation/tgstation/pull/92442https://github.com/tgstation/tgstation/pull/92911
Biodegrade destroys all restraints instead of one single restraint.
Biodegrade will now dissolve all* restraints (fixes niche use-cases such
as strait jackets, cuffed prisoner shoes, etc).
Biodegrade includes grabs (unless it's another ling): The manhandler
gets splashed acid, dealing some damage (this damage is not that bad);
the damage dealt depends on BIO protection (for reference - the default
security uniform halves the damage). They will also be stunned briefly
to give the ling a short chance to leg it.
## Why It's Good For The Game
Same reasons as Metek's
This change is meant to bring changelings in line with their categorized
"uncontainable" valid salad demarcation.
Biodegrade kinda sucks, and this makes it not-suck.
Makes biodegrade a more attractive ability for changeling by
significantly increasing its use as a method to escape confinement of
any sort. Hopefully it has the gumption to close up cheesy edge cases as
well.
## Changelog
🆑 ArchBTW, Bisar
balance: Changeling's Biodegrade works against grabs.
balance: Changeling's Biodegrade destroys all restraints instead of one
single restraint.
fix: Changeling's Biodegrade shows the effect when used inside lockers.
fix: Changeling's Biodegrade properly covers restraint types (cuffed
prisoner shoes, strait jackets, etc).
/🆑
---------
Co-authored-by: tgstation-ci[bot] <179393467+tgstation-ci[bot]@users.noreply.github.com>
Co-authored-by: ArchBTW <230859540+glue0000@users.noreply.github.com>
Co-authored-by: Aki Ito <11748095+ExcessiveUseOfCobblestone@users.noreply.github.com>
## About The Pull Request
Another one of those things that I've noticed when playing around with
fish tanks; The slowdown lingered even when the fish tank (which depends
on the total weight of fish inside it) was no longer held and was only
updated another item is equipped or held.
This is because `attempt_insert` doesn't end up calling `DoUnEquip`,
which along with `equip_to_slot`, is one of the cornerstones of the
whole inventory system that we have had for over a decade. Luckily, this
doesn't break things entirely because `item/doMove` seems to have a
fallback, but it only covers held items and only does half of what
`DoUnEquip` does, because it's its own copypaste code, disconnected from
the standard unequip call stack.
I've done some changes to make sure `DoUnEquip` is always called on
`doMove` if we find that the item still has the IN_INVENTORY flag. I've
also updated the code comment for it as well, to emphasize that the
measure is a fallback and not an excuse to call forceMove or Move if we
know that the object is held or equipped on a mob.
If something doesn't work, it'll be likely caught by the CI (it's a core
feature of the game after all) or stack traces.
Also, despite equipment slowdown supporting all mob types, when
equipping/unequipping items it's only applied to carbon mobs. This is
not _strictly_ a contributing factor to the titled issue but it still
limits a balance feature that ought to affect all mobs with hands and/or
equipment slots.
## Why It's Good For The Game
Fixing issues with inventory and storages. Hopefully improving and
modernizing years old code a little.
## About The Pull Request
<img width="573" height="77" alt="HAuAh8ioY0"
src="https://github.com/user-attachments/assets/33eb5b66-330b-42c1-b395-841561ef2bb0"
/>
Because run_examinify can get queued to run async we need to consider
the possibility that the item does not exist when the callback is
finally invoked.
## Why It's Good For The Game
Less runtime spam
## Changelog
Not player-facing
## About The Pull Request
Fixes up some of the blaring problems with the woefully unloved
dullahans, making them at least playable in time for halloween. List of
individual fixes in the changelog, but notable code changes include that
visible/audible messages can (currently exists for dullahan heads and
holopad projections) now be proxied, so that detached cameras can
optionally relay TTS, emotes, and other messages to the proper client.
## Why It's Good For The Game
Its spooky month!
## Changelog
🆑
fix: Dullahans spawn with their intended organs
fix: Dullahans can hear/see emotes
fix: Dullahan heads properly have preferences applied to them
fix: Dullahan heads no longer appear eyeless
fix: Dullahans can hear things from their head regardless of if their
body is nearby
fix: Dullahans can hear TTS messages
fix: Dullahans have a TTS voice
qol: Dullahans have a head in the character preview, for the sake of
easier customization
/🆑
## About The Pull Request
Moves a lot of the unique renaming implementations described in #82664
to the functions given by the `obj_flag` `UNIQUE_RENAME`.
`UNIQUE_RENAME` has been given new properties to account for
non-standard renaming, these being the `RENAME_NO_DESC` flag that
prevents changing the description, the `nameformat()` and `descformat()`
procs that, when modified, allow for applying naming formats(i.e. "Body
Bag - [input]"), as well as other post-renaming handling such as
changing the name of the output plant of a renamed seed, the
`rename_checks()` proc that allows for unique naming prevention(such as
a locked personal closet), and the `rename_reset()` proc to clean up
other possible renamed variables potentially changed in `nameformat()`
and `descformat()`.
This also adds `/datum/element/tool_renaming` to crayons, which will let
them rename anything that has `UNIQUE_RENAME`. I looked through
everything with that flag, and I didn't see anything that I don't think
should be renameable by a crayon(except things that shouldn't be
renamable with pens), so it shouldn't fuck anything up.
## Why It's Good For The Game
moves all of the non-honorable mentions in #82664 to the same renaming
system, and also moves all of the honorable mentions save for:
- plaques, as they only get renamed once and wouldn't benefit from
`UNIQUE_RENAME` imo
- books, because they're far more than just renaming, and are persistent
- paintings, because they're persistent
- photos, because they're not normal renaming and they're persistent
- endoskeletons, because they're done with a multitool in UI
- cardboard IDs, because they're far more than just renaming
Additionally, this fixes:
- Implanter renaming didn't work because a ! was missing
- Clown borg picket sign renaming didn't work because they didn't use
the correct arguments
This'll make it easier to make renameable objects in the future, as
well.
## Changelog
🆑
fix: fixes implanter renaming not working
fix: fixes clownborg picket sign renaming not working
code: brought most unique renaming implementations under UNIQUE_RENAME
/🆑
## About The Pull Request
Fixes#85028
Obscured flags and covered flags are tracked on carbons, updated as
items are equipped and unequipped. It's that shrimple.
Closes#92760
Just removes the species exception checks for not making sense
Also refactors handcuffs / legcuffs removal. In all of these situations
they were hardcoded when they could easily just use an inventory proc to
work.
## Why It's Good For The Game
Stops a million excessive calls to `check_obscured_slots`
Makes obscured behavior more consistent
Makes obscured behavior easier to use
Cleans up human rendering (There was some cursed stuff before with
render item -> updated obscured -> update body -> cause side effects)
## Changelog
🆑 Melbert
del: Golems which somehow manage to grow wings and somehow manage to
equip something that covers their jumpsuit can no longer fly.
(Seriously, this will not affect anyone)
refactor: Refactored clothing obscurity entirely. Items should be a
loooot more consistent and what covers what, and should update a lot
snappier. As always, report any oddities, like mysteriously disappearing
articles of clothing, hair, or species parts
refactored: Refactored handcuffs and legcuffs a bit, report any odd
situations with cuffs like getting stuck restrained
/🆑
## About The Pull Request
Changes human name to update whenever anything that could result in
their visible name changing occurs, such as changing IDs, equipping
gasmasks, picking potted plants, etc. Currently name updates occur every
``Life()`` tick and in a few "special" cases, which causes a lot of name
changes from sources such as equipment to not apply until the mob ticks,
and makes us waste a tiiiny bit of CPU time on name updates.
I've also slighly cleaned up human /Life() and made species'
``spec_life()`` not run when the mob is dead, as it was causing certain
unintended interactions, such as slimepeople regenerating blood while
dead.
## Why It's Good For The Game
Microoptimization, ensures that correct names are always used (in case
something could update their name but the mob hasn't ticked yet), plus
its just a cleaner implementation
(cherry picked from commit 87e1ef6f64)
# Conflicts:
# code/game/data_huds.dm
## About The Pull Request
Changes human name to update whenever anything that could result in
their visible name changing occurs, such as changing IDs, equipping
gasmasks, picking potted plants, etc. Currently name updates occur every
``Life()`` tick and in a few "special" cases, which causes a lot of name
changes from sources such as equipment to not apply until the mob ticks,
and makes us waste a tiiiny bit of CPU time on name updates.
I've also slighly cleaned up human /Life() and made species'
``spec_life()`` not run when the mob is dead, as it was causing certain
unintended interactions, such as slimepeople regenerating blood while
dead.
## Why It's Good For The Game
Microoptimization, ensures that correct names are always used (in case
something could update their name but the mob hasn't ticked yet), plus
its just a cleaner implementation
## About The Pull Request
By request from the original requester of Vulpkanin traits; Vulpkanin
hunger drain has been reduced from 2x -> 1.5x. (i.e. those with the
``TRAIT_FAST_METABOLISM`` trait suffer less)
## Why It's Good For The Game
2x metabolism was deemed too fast by the community, this lowers the
hunger drain for Vulps to a reasonable 1.5x so the chef still has food
on the table for other crew.
## Proof Of Testing
it compiles
## Changelog
🆑
balance: Vulpkanin hunger drain reduced from 2x -> 1.5x
/🆑
This PR aims to clean or bring up to date portions of code about dna,
the dna console and mutations. This includes taking care of or removing
some of the awful choices like the pratically useless
`datum/mutation/human` pathing, or the class variable, in favor of using
sources to avoid potential issues with extraneous sources of a mutation.
The files changed are over a hundred just because I removed the
`datum/mutation/human` path, but the actual bulk of the code is mainly
shared between the datum/dna.dm, _mutations.dm and dna_console.dm.
Mutation shitcode is hurting my future plans for infusions a little.
Also it's a much needed refactor. Drafted 'till I'm sure it works
without issues.
🆑
refactor: Refactored mutation code backend. Report any issue.
/🆑
## About The Pull Request
This PR aims to clean or bring up to date portions of code about dna,
the dna console and mutations. This includes taking care of or removing
some of the awful choices like the pratically useless
`datum/mutation/human` pathing, or the class variable, in favor of using
sources to avoid potential issues with extraneous sources of a mutation.
The files changed are over a hundred just because I removed the
`datum/mutation/human` path, but the actual bulk of the code is mainly
shared between the datum/dna.dm, _mutations.dm and dna_console.dm.
## Why It's Good For The Game
Mutation shitcode is hurting my future plans for infusions a little.
Also it's a much needed refactor. Drafted 'till I'm sure it works
without issues.
## Changelog
🆑
refactor: Refactored mutation code backend. Report any issue.
/🆑
Refactors most of blood handling code untouched by #90593 and completely
rewrites all blood decals, components and reagents.
- Blood types now have behavioral flags which allow them to control
where they leave decals/DNA/viruses. Oil no longer transfers DNA and
viruses with it, while podpeople water-blood doesn't leave visible
decals on turfs and items, but still can be picked up by DNA scanners.
- Multiple blood types have received unique handling - liquid
electricity blood now glows in the dark, oil trails are flammable and
lube ones are slippery. Oil blood can be restored with fuel, lube with
silicon and slime with stable plasma (as normal plasma already passively
regenerates their blood), instead of everything using iron. Saline
solution only supplements on iron-based blood and won't do anything to
help with bloodloss for species who rely on different blood types.
(Roundstart this applies only to Ethereals)
- All blood logic has been moved away from the blood reagent itself into
a blood element that is assigned to the blood reagent by default, and to
any reagent that's drawn from a mob as their "blood" (in
``transfer_blood_to``). This means that blood you draw from lizards will
be green and have lizard's blood description instead of mentioning red
blood cells, Ethereal "blood" will actually contain their DNA and genes,
etc.
- Refactored all blood decals. Blood states are no more, everything is
now handled via blood DNA. Credits to MrMelbert and Maplestation, as a
significant amount of code has been taken from
https://github.com/MrMelbert/MapleStationCode/pull/436 and many of his
followup PRs. Oil and xenomorph splatters are now subtypes of blood,
blood drying is now animated, blood trails now curve and can be
diagonal.
- Rewrote bloodysoles and bloody_spreader components, credits to Melbert
again for the former, while latter now makes more sense with its
interactions. Bloody soles no longer share blood DNA with your hands.
- Ported Melbert's bloody footprint sprites and bot-blood-spreading
functionality.
- Removed all species-side reagent interactions, instead they're handled
by said species' livers. (This previously included exotic blood
handling, thus the removal)
- Slightly optimized human rendering by removing inbetween overlay
holders for clothing when they're not needed.
- Blood-transmitted diseases will now get added to many more decals than
before.
- Cleaned up and partially refactored replica pods, fixed an issue where
monkeys/manipulators were unable to harvest mindless pods.
- Exotic bloodtype on species now automatically assigns their blood
reagent, without the need to assign them separately.
- Clown mobs now bleed (with colorful reagent instead of blood during
april fools), and so do vatbeasts (lizard blood)
- Implemented generic procs for handling bleeding checks, all sorts of
scanners now also correctly call your blood for what it is.
- Podpeople's guts are now lime-green like their organs, instead of
being weirdly greyish like their water-blood. (Their bleeding overlays
are still grey, as they're bleeding water)
- Slimepeople now can bleed. Their jelly is pale purple in color, but
their wound overlays copy their body color.
- Injecting/spraying/splashing/etc mob with a reagent preserves its
data, so you could theoretically recycle fine wines from someone's
bloodstream
- Fixed burdened chaplain's sect never actually giving a blessing when
applying effects, and giving a blessing when nothing can be healed.
Inverted check strikes again.
- Closes#91039
A lot of blood here has dried, visually the blood colors are almost
exactly the same as before either of the blood refactors.
## About The Pull Request
Refactors most of blood handling code untouched by #90593 and completely
rewrites all blood decals, components and reagents.
- Blood types now have behavioral flags which allow them to control
where they leave decals/DNA/viruses. Oil no longer transfers DNA and
viruses with it, while podpeople water-blood doesn't leave visible
decals on turfs and items, but still can be picked up by DNA scanners.
- Multiple blood types have received unique handling - liquid
electricity blood now glows in the dark, oil trails are flammable and
lube ones are slippery. Oil blood can be restored with fuel, lube with
silicon and slime with stable plasma (as normal plasma already passively
regenerates their blood), instead of everything using iron. Saline
solution only supplements on iron-based blood and won't do anything to
help with bloodloss for species who rely on different blood types.
(Roundstart this applies only to Ethereals)
- All blood logic has been moved away from the blood reagent itself into
a blood element that is assigned to the blood reagent by default, and to
any reagent that's drawn from a mob as their "blood" (in
``transfer_blood_to``). This means that blood you draw from lizards will
be green and have lizard's blood description instead of mentioning red
blood cells, Ethereal "blood" will actually contain their DNA and genes,
etc.
- Refactored all blood decals. Blood states are no more, everything is
now handled via blood DNA. Credits to MrMelbert and Maplestation, as a
significant amount of code has been taken from
https://github.com/MrMelbert/MapleStationCode/pull/436 and many of his
followup PRs. Oil and xenomorph splatters are now subtypes of blood,
blood drying is now animated, blood trails now curve and can be
diagonal.
- Rewrote bloodysoles and bloody_spreader components, credits to Melbert
again for the former, while latter now makes more sense with its
interactions. Bloody soles no longer share blood DNA with your hands.
- Ported Melbert's bloody footprint sprites and bot-blood-spreading
functionality.
- Removed all species-side reagent interactions, instead they're handled
by said species' livers. (This previously included exotic blood
handling, thus the removal)
- Slightly optimized human rendering by removing inbetween overlay
holders for clothing when they're not needed.
- Blood-transmitted diseases will now get added to many more decals than
before.
- Cleaned up and partially refactored replica pods, fixed an issue where
monkeys/manipulators were unable to harvest mindless pods.
- Exotic bloodtype on species now automatically assigns their blood
reagent, without the need to assign them separately.
- Clown mobs now bleed (with colorful reagent instead of blood during
april fools), and so do vatbeasts (lizard blood)
- Implemented generic procs for handling bleeding checks, all sorts of
scanners now also correctly call your blood for what it is.
- Podpeople's guts are now lime-green like their organs, instead of
being weirdly greyish like their water-blood. (Their bleeding overlays
are still grey, as they're bleeding water)
- Slimepeople now can bleed. Their jelly is pale purple in color, but
their wound overlays copy their body color.
- Injecting/spraying/splashing/etc mob with a reagent preserves its
data, so you could theoretically recycle fine wines from someone's
bloodstream
- Fixed burdened chaplain's sect never actually giving a blessing when
applying effects, and giving a blessing when nothing can be healed.
Inverted check strikes again.
- Closes#91039
#### Examples
A lot of blood here has dried, visually the blood colors are almost
exactly the same as before either of the blood refactors.
## About The Pull Request
Adds a new HUD element that only shows up when you're resting that
flicks when you click it once, and puts you to sleep for 40 seconds if
you double click it (so you don't accidentally sleep yourself for 40
seconds), which is meant to replace the verb in the stat panel.
Doesn't show up if you're sleep immune.
I also fixed alien huds a bit, putting rest on the right side where it
is for every other mob, and brought the floor change buttons down to
compensate.
New Larva HUD (other xenos have Throw between rest and sleep)
Demonstration
https://github.com/user-attachments/assets/11f7574d-dd6d-4da5-ab39-6fcf6d6694b9
Rest can be seen in IDB
### New accessibility setting
As a compromise to putting a tgui confirmation menu in your face or
requiring a double click, I added a new setting in accessibility tab
that allows you to disable "double click" features. So far all it does
is give a tgui menu instead of require double click for sleeping, and
allow you to further examine things with a linked button in base
examine.
## Why It's Good For The Game
Sleep is currently only a verb available in the stat panel, this
provides an alternative so it doesn't become a chatbar-only verb when
the stat panel is removed. It's also just good feedback to the player
that this action exists.
## About The Pull Request
Adds a new HUD element that only shows up when you're resting that
flicks when you click it once, and puts you to sleep for 40 seconds if
you double click it (so you don't accidentally sleep yourself for 40
seconds), which is meant to replace the verb in the stat panel.
Doesn't show up if you're sleep immune.
I also fixed alien huds a bit, putting rest on the right side where it
is for every other mob, and brought the floor change buttons down to
compensate.
New Larva HUD (other xenos have Throw between rest and sleep)
Demonstration
https://github.com/user-attachments/assets/11f7574d-dd6d-4da5-ab39-6fcf6d6694b9
Rest can be seen in IDB
### New accessibility setting
As a compromise to putting a tgui confirmation menu in your face or
requiring a double click, I added a new setting in accessibility tab
that allows you to disable "double click" features. So far all it does
is give a tgui menu instead of require double click for sleeping, and
allow you to further examine things with a linked button in base
examine.
## Why It's Good For The Game
Sleep is currently only a verb available in the stat panel, this
provides an alternative so it doesn't become a chatbar-only verb when
the stat panel is removed. It's also just good feedback to the player
that this action exists.
<!-- 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. -->
This PR started with the idea of adding support for map feedback
threads, which I added to the roundend report, escape menu, and stat
panel. To do this though I had to make pretty annoying changes to the
stat panel and had to touch every single time something to the stat
panel was added, so since we now have a way to have links in the stat
panel I thought of taking full advantage of it and add some QOL.
AIs can now track their borgs by clicking their status on the stat panel
https://github.com/user-attachments/assets/1789dc46-5d12-48e9-bb8d-d3278aa19639
With Melbert's comment, I added another stat panel entry that directs
you to the Webmap page, which currently seems to be a little messed up
(https://github.com/AffectedArc07/SS13WebMap/issues/41 &
https://github.com/AffectedArc07/SS13WebMap/issues/42) but if they get
fixed this would be a swag asf feature
Feedback threads was a suggestion from a player and is fully in control
of admins as an optional thing, and while we still have stat panel I
think it's nice to be able to take advantage of its features.
🆑
admin: Admins can now link a URL for maps, used to give feedback on said
maps. Accessible through the roundend report, escape menu, and stat
panel.
qol: AIs can track their borgs by clicking on them in the stat panel.
qol: You can now directly go to the webmap of maps from the stat panel
(assuming it's set in config).
/🆑
## About The Pull Request
Hunger bar is now dynamic rather than 4 static sprites
Hunger bar now accounts for food you have yet to metabolize, meaning it
updates as you eat
https://github.com/user-attachments/assets/06269da7-f07d-4738-98b2-ca6bde8ba0fe
Other changes:
- Adds a hunger tier between hungry and starving
## Why It's Good For The Game
Overeating happens so often simply because this bar is trash, so let's
give it some love
## Changelog
🆑 Melbert
fix: All humans no longer have a baseline "75" ghost nutrition (which
means you can eat more)
qol: Hunger bar update! It's now dynamic and updates as you eat.
qol: Adds a hunger tier between hungry and starving (for mood)
/🆑
## About The Pull Request
This PR started with the idea of adding support for map feedback
threads, which I added to the roundend report, escape menu, and stat
panel. To do this though I had to make pretty annoying changes to the
stat panel and had to touch every single time something to the stat
panel was added, so since we now have a way to have links in the stat
panel I thought of taking full advantage of it and add some QOL.
AIs can now track their borgs by clicking their status on the stat panel
https://github.com/user-attachments/assets/1789dc46-5d12-48e9-bb8d-d3278aa19639
With Melbert's comment, I added another stat panel entry that directs
you to the Webmap page, which currently seems to be a little messed up
(https://github.com/AffectedArc07/SS13WebMap/issues/41 &
https://github.com/AffectedArc07/SS13WebMap/issues/42) but if they get
fixed this would be a swag asf feature
##### Code bounty for Ezel/Improvedname
## Why It's Good For The Game
Feedback threads was a suggestion from a player and is fully in control
of admins as an optional thing, and while we still have stat panel I
think it's nice to be able to take advantage of its features.
## Changelog
🆑
admin: Admins can now link a URL for maps, used to give feedback on said
maps. Accessible through the roundend report, escape menu, and stat
panel.
qol: AIs can track their borgs by clicking on them in the stat panel.
qol: You can now directly go to the webmap of maps from the stat panel
(assuming it's set in config).
/🆑
## About The Pull Request
from when the server starts to 30 minutes after, respawning is free of
charge
## Why It's Good For The Game
item #1 on the list
## Proof Of Testing
it works dude trust me
<details>
<summary>Screenshots/Videos</summary>
</details>
## Changelog
🆑
code: respawn enabled until 30 min (world time)
/🆑
## About The Pull Request
Hunger bar is now dynamic rather than 4 static sprites
Hunger bar now accounts for food you have yet to metabolize, meaning it
updates as you eat
https://github.com/user-attachments/assets/06269da7-f07d-4738-98b2-ca6bde8ba0fe
Other changes:
- Adds a hunger tier between hungry and starving
## Why It's Good For The Game
Overeating happens so often simply because this bar is trash, so let's
give it some love
## Changelog
🆑 Melbert
fix: All humans no longer have a baseline "75" ghost nutrition (which
means you can eat more)
qol: Hunger bar update! It's now dynamic and updates as you eat.
qol: Adds a hunger tier between hungry and starving (for mood)
/🆑
Converts `/datum/player_details` into `/datum/persistent_client`.
Persistent Clients persist across connections. The only time a mob's
persistent client will change is if the ckey it's bound to logs into a
different mob, or the mob is deleted (duh).
Also adds PossessByPlayer() so that transfering mob control is cleaner
and makes more immediate sense if you don't know byond-fu.
Clients are an abstract representation of a connection that can be
dropped at almost any moment so putting things that should be stable to
access at any time onto an undying object is ideal. This allows for
future expansions like abstracting away client.screen and managing
everything cleanly.
## About The Pull Request
Separate verb and PR from #89375 because this is something you'd apply
on top of a mob with existing behaviour, or one you've used the other
verb on.
This will probably conflict with my other PR but that's my problem.
This adds a shortcut for making mobs say/emote stuff randomly on a timer
from a list of things you have specified.
Doing this via VV is possible but sufficiently complicated that I don't
think anyone would ever bother.
As with the other PR you can optionally do this to mobs who already have
a client if you want them to randomly burp every so often or something.
I briefly flirted with the idea of replacing all
`/datum/ai_planning_subtree/random_speech` subtypes with blackboard ones
but... I think probably actually we save some memory _and_ sanity by not
doing that.
A bunch of mobs on totally different typepaths use the `/insect` subtype
for instance, and I don't think it would be an improvement to paste the
same four vars into all of their blackboards.
## Why It's Good For The Game
This one is frankly more niche than the other PR probably but it is
plausibly useful if you are setting up some kind of VV creature.
Fixes#85980
- Pixel adjustments are now sourced
When tweaking a mob's pixel w, x, y, z, is is now done via `add_offsets`
and must have a source string associated
- Refactors riding
Refactors how riding component selects the offsets to use. It's now all
done via the getter rather than a weird mix of a var, a cache, and a
getter.
- Moves a bunch of animations to use `pixel_w` / `pixel_z`
Largely to prevent conflicts with adjustments to a mob's pixel position,
but also as many animations are not actual movements, but visual
movements. Floating is one such example.
It just works
🆑 Melbert
fix: Fixed grab offsets not showing for anything but passive grab
fix: Fix jank with mob offsets when riding things
refactor: Refactored riding component, particularly how it selects layer
and offsets. Report any oddities
refactor: Refactored pixel offsets of mobs. Report any oddities
/🆑
## About The Pull Request
Melbert asked me to make this and I thought it'd be relatively easy and
plausibly useful so I did.
This PR adds a feature to the VV menu for mobs which allows you to apply
and configure an AI controller from a list of templates.
It's not as versatile as coding one would be, but it should be able to
accomodate a lot of generic scenarios.
Some examples of basic stuff you can set it up to do:
- Give Ian a machine gun he will fire at nearby people while staying
within a specified min/max range.
- Have Poly fire brimstone beams on cooldown at whoever is nearby
(although she won't bother trying to line up cardinally).
- Assign a gorilla to be someone's personal bodyguard which will follow
them around and attack anyone who hurts them.
I have also made an executive decision to remove the restriction that
basic ai controllers can only be placed on basic mobs.
We've removed _most_ non-basic simple mobs from the game, and also have
more recently updated most AI behaviours to work agnostically of whether
they are assigned to a basic mob or not... which means that they'll
largely work on carbons.
Coincidentally, this feature makes sure to ask if you want an AI
controller to remain active on a mob which already has a client.
Assigning an active AI controller to a live player which forces their
character to automatically attempt to run away from whoever the last
person to attack them was is ~~not recommended behaviour because it's
largely untested~~ highly recommended behaviour because I think it's
very funny (makes it very hard to play though).
I'm gonna do another PR some time which cleans up `random_speech` so
it's configurable and then let you slap that on whoever as well.
## Why It's Good For The Game
Enables a greater level of admin abuse.
## Changelog
🆑
admin: Added easier tooling for admins to add or change the AI
controllers on mobs
/🆑
## About The Pull Request
Converts `/datum/player_details` into `/datum/persistent_client`.
Persistent Clients persist across connections. The only time a mob's
persistent client will change is if the ckey it's bound to logs into a
different mob, or the mob is deleted (duh).
Also adds PossessByPlayer() so that transfering mob control is cleaner
and makes more immediate sense if you don't know byond-fu.
## Why It's Good For The Game
Clients are an abstract representation of a connection that can be
dropped at almost any moment so putting things that should be stable to
access at any time onto an undying object is ideal. This allows for
future expansions like abstracting away client.screen and managing
everything cleanly.
## About The Pull Request
Separate verb and PR from #89375 because this is something you'd apply
on top of a mob with existing behaviour, or one you've used the other
verb on.
This will probably conflict with my other PR but that's my problem.
This adds a shortcut for making mobs say/emote stuff randomly on a timer
from a list of things you have specified.
Doing this via VV is possible but sufficiently complicated that I don't
think anyone would ever bother.
As with the other PR you can optionally do this to mobs who already have
a client if you want them to randomly burp every so often or something.
I briefly flirted with the idea of replacing all
`/datum/ai_planning_subtree/random_speech` subtypes with blackboard ones
but... I think probably actually we save some memory _and_ sanity by not
doing that.
A bunch of mobs on totally different typepaths use the `/insect` subtype
for instance, and I don't think it would be an improvement to paste the
same four vars into all of their blackboards.
## Why It's Good For The Game
This one is frankly more niche than the other PR probably but it is
plausibly useful if you are setting up some kind of VV creature.
## About The Pull Request
Fixes#85980
- Pixel adjustments are now sourced
When tweaking a mob's pixel w, x, y, z, is is now done via `add_offsets`
and must have a source string associated
- Refactors riding
Refactors how riding component selects the offsets to use. It's now all
done via the getter rather than a weird mix of a var, a cache, and a
getter.
- Moves a bunch of animations to use `pixel_w` / `pixel_z`
Largely to prevent conflicts with adjustments to a mob's pixel position,
but also as many animations are not actual movements, but visual
movements. Floating is one such example.
## Why It's Good For The Game
It just works
## Changelog
🆑 Melbert
fix: Fixed grab offsets not showing for anything but passive grab
fix: Fix jank with mob offsets when riding things
refactor: Refactored riding component, particularly how it selects layer
and offsets. Report any oddities
refactor: Refactored pixel offsets of mobs. Report any oddities
/🆑
## About The Pull Request
Melbert asked me to make this and I thought it'd be relatively easy and
plausibly useful so I did.
This PR adds a feature to the VV menu for mobs which allows you to apply
and configure an AI controller from a list of templates.
It's not as versatile as coding one would be, but it should be able to
accomodate a lot of generic scenarios.
Some examples of basic stuff you can set it up to do:
- Give Ian a machine gun he will fire at nearby people while staying
within a specified min/max range.
- Have Poly fire brimstone beams on cooldown at whoever is nearby
(although she won't bother trying to line up cardinally).
- Assign a gorilla to be someone's personal bodyguard which will follow
them around and attack anyone who hurts them.
I have also made an executive decision to remove the restriction that
basic ai controllers can only be placed on basic mobs.
We've removed _most_ non-basic simple mobs from the game, and also have
more recently updated most AI behaviours to work agnostically of whether
they are assigned to a basic mob or not... which means that they'll
largely work on carbons.
Coincidentally, this feature makes sure to ask if you want an AI
controller to remain active on a mob which already has a client.
Assigning an active AI controller to a live player which forces their
character to automatically attempt to run away from whoever the last
person to attack them was is ~~not recommended behaviour because it's
largely untested~~ highly recommended behaviour because I think it's
very funny (makes it very hard to play though).
I'm gonna do another PR some time which cleans up `random_speech` so
it's configurable and then let you slap that on whoever as well.
## Why It's Good For The Game
Enables a greater level of admin abuse.
## Changelog
🆑
admin: Added easier tooling for admins to add or change the AI
controllers on mobs
/🆑
## About The Pull Request
- Fixes#76977
pAIs were able to interact with machinery via ctrl_click/alt_click
behavior. Notably this applied to atmos pumps and thermomachines which
allowed a pAI to do harmful actions like overload the SM or flood the
station with gas.
I added a `ALLOW_PAI` flag so that if someone wants to in the future
they can enable certain actions as a whitelist... but right now there
isn't anything that would make sense to let them interact with.
## Why It's Good For The Game
Holograms should not be able to directly interact with stuff.
## About The Pull Request
Partially a port of
https://github.com/DaedalusDock/daedalusdock/pull/1163 which is a port
of my own code from bitbus
Closes#88579
Instead of manually setting hud images and positioning we now can use
set_hud_image_state which also updates their position to ensure that
they scale with the owner atom. HUDs had RESET_COLOR and RESET_TRANSFORM
but no KEEP_APART, so they were stuck with mobs all this time. I
replaced RESET_TRANSFORM with PIXEL_SCALE (shouldn't be reserved to mob
huds only to be honest) and added KEEP_APART, so that HUDs still
scale/rotate with their owner but don't inherit their color. Also fixed
the dragon issue, that's where this PR actually started.
Closes https://github.com/tgstation/tgstation/issues/45411
## Why It's Good For The Game
I don't want my HUDs to be pretty pink when I make a barbie Clarke.
## Changelog
🆑
refactor: Rewrote some of HUD code so they're no longer colored in their
owner's color
fix: Space dragons no longer turn invisible when toggling seethrough
mode
/🆑
nevimer