## About The Pull Request
What it says on the tin-- with having a nice abstract types system now,
we can utilize that in create_and_destroy.
## Why It's Good For The Game
Removes a lot of the need for snowflake item exclusions, and makes this
test likely a lot more stable (and a little faster even).
## Changelog
Not player-facing
## About The Pull Request
- Removed global list `fake_reagent_blacklist` in favour of
`abstract_type`. Saved memory
- Removed proc `get_chemical_reaction()` in favor of
`GLOB.chemical_reaction_list`. No proc overhead and faster access
- Remove unused proc `remove_chemical_reaction()`
- Removed proc `find_reagent()` in favour of
`GLOB.chemical_reagents_list`. No proc overhead and faster access
- Directly access name of reagents via `::` operator from typepaths
instead of looking up the datum in global chemical reagents list for
some operations. Faster variable access
- Removed unit test `reagent_id_typos`. The typepaths will error at
compile time because they aren't strings so there's no need for this
test
## Changelog
🆑
code: cleaned up code pertaining to reagent & reaction lookup
/🆑
## About The Pull Request
Converts species and antagonist icon generation to the batched
spritesheet system using IconForge, thanks to the new
`get_flat_uni_icon` implementation. Unfortunately the cost of *building*
the sprite is still expensive (GFI is always expensive, even a fancy
list-based one), but the generation is SIGNIFICANTLY faster. We will see
evidence of parity in the screenshot tests. but here:
<img width="892" height="634" alt="image"
src="https://github.com/user-attachments/assets/2a17f2e3-c024-41f6-9d1e-c2cb70642a81"
/>
The main advantage is that species and antag icons can now take
advantage of the development-time smart cache which invalidates
automatically. On the server this PR does very little except make antag
icon generation a little bit more likely to find and announce errors
(BYOND has a habit of silently eating weird icon proc calls).
Also optimizes the greyscale preview generator from #90940 (~2x speedup)
using `rustg_iconforge_generate_headless` instead of `Insert()` to build
the resulting sheets. This can be further optimized in the future by
implementing a smart cache, like batched spritesheets, and storing it in
the repo, but for now it's not important/slow enough to be worth the
effort. Also fixes a silent compilation error that would always happen
outside unit tests, but for some reason doesn't appear on local? Notice
how `map_icon_key` is not a defined variable anywhere. That's because
`USE_RUSTG_ICONFORGE_GAGS` is *never* defined at this point, so it was
always using the 'slow' generation.
I also took the liberty of cleaning up the cultist and heretic icon
generation randomly initializing a blade object when it could just use a
static access.
## Why It's Good For The Game
The subsystem timing may not be much faster, but the interactivity
benefits during spritesheet realization are undeniable. Opening the
preferences menu during init on local is orders of magnitude faster.
**Old**
Early Assets: 5.02 seconds
Greyscale Previews: 1.38 seconds
**Fresh (No Cache)**
Early Assets: 4.21 seconds
Greyscale Previews: 0.5 seconds
**Cache Invalidated**
Early Assets: 4.27 seconds
**Cache Hit**
Early Assets: 4.05~4.2 seconds
**Preferences lag:**
~6 sec to open to ~2 sec to open due to caching in dev
## Changelog
🆑
code: Optimized species and antagonist icon loading in the preferences
menu on local, speeding up time to open in development.
fix: GAGS map preview generation no longer silently errors outside of
unit tests due to a compilation error.
/🆑
## About The Pull Request
Fixes#95203
Changling "decoy brain" status was a behavior attached to the brain.
However it never re-applied the "decoy brain" status at any point. Even
if your brain changed.
This was fine for the most part because all of our roundstart species
used the same base brain type.
Which meant your brain didn't change and there was no reason to re-apply
the behavior.
But now Felinids (*and Lizardpeople*) have a different brain typepath.
Changing into these species would give you an entirely new brain and
wipe the "decoy brain" mechanic entirely without re-applying it.
This PR fixes the issue by re-applying "decoy brain" status the ling has
a new brain added.
## Changelog
🆑 Melbert
fix: Fixes Changlings transformed into a Felinid losing decap immunity
thanks to their newly shrunken brain
/🆑
---------
Co-authored-by: Jordan Dominion <jordanhcbrown+github@gmail.com>
Co-authored-by: Arturlang <24881678+Arturlang@users.noreply.github.com>
## About The Pull Request
- You can now add effects when multiple reagents are metabolized per
tick by creating a new subtype of
`/datum/stacked_metabolization_effect`. So lets say you have 3 reagents
A & B & C and you want to implement some unique effect when all 3
reagents are present at the same time. Instead of implementing those
effect inside each of those reagents like such
```dm
/datum/reagentA/on_mob_life()
if(holder.hasReagent(/datum/reagentB) && holder.hasReagent(/datum/reagentC))
//do stuff
/datum/reagentB/on_mob_life()
if(holder.hasReagent(/datum/reagentC) && holder.hasReagent(/datum/reagentA))
//do stuff
/datum/reagentC/on_mob_life()
if(holder.hasReagent(/datum/reagentA) && holder.hasReagent(/datum/reagentB))
//do stuff
```
You can now implement that effect by creating a subtype of stack reagent
effect as such
```dm
/datum/stacked_metabolization_effect/unique_effect
requirements = list(/datum/reagent/A = 1, /datum/reagent/B = 1, /datum/reagent/C = 1)
/datum/stacked_metabolization_effect/unique_effect/apply(list/reagents_metabolized, mob/living/carbon/owner, seconds_per_tick)
var/metabolization_ratio = average(reagents_metabolized)
//do stuff with the ratio
```
The effect is applied per tick and you can check for subtypes as well
like such
```dm
/datum/stacked_metabolization_effect/unique_effect
requirements = list(/datum/reagent/A = 3)
```
## Why it's good for the game
The framework of stacked reagent effects allows contributors to
implement unique effects for metabolizing multiple reagents at once. The
benefits are obvious.
Right now it's a framework that is unused but should hopefully see some
use in the future
## Changelog
🆑
code: adds a framework for implementing effects when multiple reagents
are metabolized per tick
/🆑
---------
Co-authored-by: Jordan Dominion <jordanhcbrown+github@gmail.com>
## About The Pull Request
Gives the 3 main missing icon tests a shared parent for behavior. Made
the list of icon states not static because of this but that shouldn't
really matter.
Additional icon locations is made a list for evil down streams that are
grandchildren of TG rather then just children, or repos with multiple
spots for icons, `modular_downstream/master_files/icons` and
`modular_downstream/modules` can both have icons in alot of them
Was considering also making them filter out abstract_types but maybe
should be a diff pr.
## Why It's Good For The Game
All 3 present unit tests copy paste ALOT of their behavior, but very low
hanging fruit is the compiling of folders, which while claiming have
modularity support its a bit silly to require 3 separate additions just
to make sure all tests are properly working.
## Changelog
N/A
---------
Co-authored-by: Jordan Dominion <dominion@tgstation13.org>
## About The Pull Request
Makes lizard husks swampy green and ethereal husks bright neon green
<img width="187" height="99" alt="image"
src="https://github.com/user-attachments/assets/a9182969-8dc7-4fb5-a55b-8bf30acac730"
/>
Also futureproofed the blood-colored limb overlay element that skeleton
limbs use to work fine if the limb didn't get assigned blood dna (while
its still attached to the owner without being added by butchering)
## Why It's Good For The Game
Preserves visual consistency
## Changelog
🆑
image: Husk visuals now inherit their mob's blood color
/🆑
## 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
This is the most efficent way of doing it (I think), typeid checking is
actually worse (it's 55 btw). I've also added alists to all the find
reference unit tests.
This is a good step in making these things actually work in our
codebase. The next thing to look into will be VV (or SDQL though I
suspect that's just a matter of being able to use a stable version)
which is gonna require playing around with IS_NORMAL_LIST's uses a good
bit
## About The Pull Request
Exactly what the title says. Nightmare/shadowlings and nightmare organs
have new sprites
<img width="412" height="408" alt="image"
src="https://github.com/user-attachments/assets/ea5cdeea-157e-4e2a-943d-61bca08ce7cd"
/>
## Why It's Good For The Game
Shadow people sprite is ancient and not really that good. Now they
actually look scary. Light Eater just using same sprite as changeling's
armblade was kinda boring, same goes for heart of darkness just being
black demon heart
## Changelog
🆑 ERRORNAME
image: Shadow people and Nightmare resprite
image: Unique sprites for light eater and heart of darkness
/🆑
## About The Pull Request
Desensitized is no longer binary yes/no, now scales from 0.1x to 1x (or
beyond, I guess)
Desensitized jobs start as 0.5x desensitized (which is the threshold for
being considered "truly desensitized")
Some antags are now 0.1x to 0.25x desensitized
Witnessing death of a fellow human gives you slight desensitization
(currently -0.025x).
A normal crewmember, after witnessing 20 deaths, is on par with a
roundstart desensitized crewmember.
Likewise a desensitized crewmember has almost no reaction to death after
witnessing 20 deaths.
Your own deaths count towards this value.
There's an achievement for managing to go from 1x to 0.1x across the
course of an entire round.
## Why It's Good For The Game
This is intended to contribute to the "story" people face across the
length of a round.
Rounds with few overall deaths results in crewmembers regularly getting
shocked, but bloodbaths results in crewmembers "dehumanizing and facing
the bloodshed".
## Changelog
🆑 Melbert
add: Desensitization to death is no longer binary - some antagonists are
now more used to it than others.
add: Witnessing the death of a fellow humanoid (or dying yourself) will
slightly desensitize you to future deaths.
add: Adds an achievement for managing to max out desensitization across
a round.
add: Desensitized crewmembers care less when splattered with blood.
add: Holodeck mobs have a reduced death mood impact.
/🆑
## About The Pull Request
`Moved` -> registers id card in wallet -> `dropped` -> unregisters id
card
Fixes it by registering in dropped. This does mean we register,
unregister, and register again, which is less than ideal - but I'm not
sure how else to tackle this cleanly...
## Changelog
🆑 Melbert
fix: Fix wallet (again)
/🆑
## About The Pull Request
Makes a unit test that checks the engineering borg's RCD & RTD to make
sure they're working.
## Why It's Good For The Game
After the issue that happened a little bit ago where these stopped
working, a unit test was suggested. This test would have prevented that
issue, and also serves as a general rcd and rtd test to some extent.
## About The Pull Request
I'm making the ordeal of finding a maint disk (or buying blackmarket
bootleg disk) with a theme in it a slightly more rewarding experience,
while sticking to the concept that it's something you've to find, unlike
default PDA themes.
This PR also proves to be an opportunity to put the progress tab that I
coded a year ago for the 'Fishdex' to good use.
TODO:
~~Refactor preferences to allow specific choices to be shown/hidden
depending on whether the player meets a defined criteria, otherwise
you'll have to do it manually every round, which is lame~~
- [x] Make some simple ui icons associated with each unlockable theme to
be shown in the cheevo progress tab
- [x] Code to validate deserialized DB values, in the remote case that
any theme is removed in the future, as well as unit test code for any
non-abstract theme without ID
- [x] Add sound cue and chat feedback when unlocking a theme (or when
fishing a new kind of fish for the first time, like, the code's similar)
- [x] Test all of this
## Why It's Good For The Game
These themes are basically an end in itself, and I understand the reason
behind their existence is to make for some cute, little maint loot, but
relegating it to chance of finding a disk somewhere in maintenance,
**every single round** really rots whatever little substance this purely
cosmetic feature already has.
## Changelog
🆑
add: Once installed, special PDA themes from maintenance disks will be
present on your roundstart PDA on future rounds (Sadly I couldn't figure
out a way to add those to the preferences UI yet). You can check which
PDA themes you've unlocked in the Progress tab of the achievements UI.
/🆑
## About The Pull Request
Adds emergency access and red alert access as tests in the door access
unit test.
## Why It's Good For The Game
Only two things are infinite, the universe and human stupidity, and I'm
not sure about the former.
## Changelog
🆑 LT3
code: Code unit testing now checks emergency access and red alert access
/🆑
## LTS Document
Check this document before making any significant future changes to
blood worms, please.
https://hackmd.io/@RikuTheKiller/H1AHQSKNZx
## About The Pull Request
THIS PR SHOULD ABSOLUTELY BE TM'D FIRST
Blood worms are a new progression antag. When the event runs, 2
candidates are picked from ghosts and spawned in as blood worm
hatchlings, which then have to grow up, do a couple objectives and take
over the station.
Hatchlings are weak outside of a host, while juveniles can stand their
own reasonably well. Adults have high offensive power and can only be
dealt with using the right gear or a lot of luck and robustness. They're
meant to be a moment of glory for achieving maximum progression and they
can bootstrap the next hatchlings by gathering corpses before cocooning.
Each growth stage requires 30 seconds in a cocoon, which can only be
created after consuming a lot of blood. There's a falloff curve on a
per-blood-type basis, meaning you can't drain the same person over and
over again to reach adulthood. The medbay freezer is a priority target
for the blood worms and can get one of them to the juvenile stage if
fully ransacked.
It takes 500 blood to mature from hatchling to juvenile, and 1500 blood
to mature from juvenile to adult. You can only get up to 1000 blood from
synthetic sources like monkeys, and consuming synthetic blood is 30%
less efficient. Blood worms can also examine living targets to see how
much blood a target has, and how much growth the blood worm would gain
for consuming that blood.
Blood worms spawn in vents and have night vision for maneuvering in
maintenance. Hatchlings can ventcrawl, while juveniles can move around
by breaking things. Optionally, you can take over a host with a lot of
access like the Captain to go basically anywhere, especially if nobody
knows you killed the captain.
Behind the scenes, host-taking kicks the host's original mind to a
backseat mob. This needs the most testing in practice, but it's
confirmed that it returns the host's mind back to their body, at least
in testing.
All mob, ability and action sprites are made by INFRARED_BARON. Legal
rights were transferred to me after I paid for the commission.
Note, I've been working on this massive PR for quite a while, so
documenting every small change is really hard! Apologies for anything
I've missed. There's a lot.
Final note, admins can spawn these by either:
A. Trigger the midround event via the dynamic-panel verb, under the
Rulesets tab.
B. Giving someone the Blood Worm antag datum via the Traitor Panel in
the Player Panel for the target player. This will transform their mob
into a valid Blood Worm, with all of the associated objectives and such.
### Active Abilities
1. Leech Blood (No Host) - Lets the blood worm drain blood from living
targets and reagent containers. Uses an aggressive grab to restrain
living targets until leeching is over, which takes around a second to
initiate. Causes oxyloss during the leeching. NPC monkeys can't escape
from this and it floors targets as well.
2. Spit Blood (Both) - Multi-function ability, lets the blood worm fire
ranged corrosive blood spit at targets, melt restraints on their hosts
by right-clicking, and as an adult, shoot a burst of blood spit at a
target by right-clicking. Note of the right-click abilities, shooting
bursts can't be done while in a host. (to avoid unfair stealth kills)
Shooting a burst has a much longer cooldown than shooting normally. All
spit types cost blood to use.
3. Invade Corpse (No Host) - Lets the blood worm take a host for
themselves, consuming all of the host's blood and in essence, "becoming"
the host. Any bloodloss inflicted on the host is taken as damage to the
blood worm, and the blood worm retains its weakness to fire even in this
state. Burn damage itself no longer has any extra damage, though.
4. Leave Host (Host) - Title, literally just leaves the host after a
delay. Notably works even while the host is moving, dead, incapacitated
or otherwise fucked up in any way, shape or form.
5. Inject Blood (Host) - Lets the blood worm heal its host. The potency
of this increases as the worm grows up, but so does the cooldown and
blood consumption. This works on organ damage, injuries, etc.
6. Mature (No Host) - Makes the blood worm enter a cocoon for 30
seconds, emerging as the next growth stage. Requires an increasing
amount of consumed blood / growth as the blood worm uses it.
7. Reproduce (No Host, Adult Only) - Makes the blood worm enter a cocoon
for 30 seconds, with 4 hatchlings emerging out of it, including the
original blood worm, now reverted back into a hatchling as well.
8. Revive Host (Host) - If the host is in a viable state to be revived,
revives them after an animation sequence plays out.
### Passive Abilities
1. Space Immunity - Blood worms are immune to the cold, low pressures
and a lack of oxygen. Only the immunity to a lack of oxygen carries on
to hosts from this.
2. Organ Insertion - Blood worms can insert organs into their hosts by
right-clicking on them with the organ in-hand. This mainly exists to
deal with hosts that lack organs, and avoids the gotcha where an adult
blood worm ends up gutting their host by hitting them too hard, as they
can simply fix it on the spot.
3. Life Support - Blood worm hosts don't need a heart, lungs or a liver
to survive. Lungs are useful for speaking, and a liver is necessary to
process reagents.
4. Regeneration - Blood worms slowly heal over time. This is nowhere
near enough to overcome bleeding or heat damage, since it's 0.3 hp/s for
a hatchling, 0.4 hp/s for a juvenile and 0.5 hp/s for an adult.
5. Night Vision - Blood worms can see in the dark. This doesn't extend
to hosts.
6. Ventcrawling - Hatchling blood worms can ventcrawl.
7. Doorcrawling - Hatchling and juvenile blood worms can slide under
doors. Doing so takes 3 seconds for a hatchling and 5 seconds for a
juvenile.
8. HUD - Blood worms can tell how much blood targets have at a glance,
via a blood HUD bar exclusive to them. They can also tell apart other
blood worm hosts from normal people via an antag HUD. There's also an
examine message they can use on living targets for even more info.
### Weaknesses
1. Heat and Fire - Blood worms quickly die to heat, their bodies are
flammable and their blood will burn up if their host's core temperature
is too high. The main counter to this is getting a host with
flame-resistant gear.
2. Bleeding - While in a host, bleeding wounds will directly damage the
blood worm itself. How much a host needs to bleed before the worm dies
depends on their growth stage. Blood worm hosts keep bleeding even while
dead, so just keep hitting them and they'll die. Blood worms
automatically leave their hosts when they hit 10% health or lower, and
their hosts bleed 50% faster than normal people.
3. Stuns - Blood worms have no way of dealing with a stunned host other
than getting out. They can deal with any restraints by melting them,
though.
4. Testing - Security can order a blood worm testing crate from cargo,
either for a 20 minute cooldown via the security cargo interface
console, or for 10000 credits via the supply console. It contains 4
single-use testers that hurt a bit when applied, but are instant to use
and 100% accurate. The stopgap is that they're really fucking expensive
and only work once per item.
### Screenshot
<img width="280" height="132" alt="image"
src="https://github.com/user-attachments/assets/00d22361-997e-4347-a0bf-aa240de40727"
/>
## Why It's Good For The Game
Antagonist variety, mainly. This is basically Cortical Borers 2:
Electric Boogaloo.
Currently, we lack any antagonists with mind control abilities. That
really sucks!
I've also gotten a lot of positive feedback about the antagonist while
working on it.
This antagonist also has great potential for roleplay, as they can take
over hosts, surprise attack people by getting out of a dead corpse, talk
to each other using Wormspeak, etc.
I think we're also itching for variety on "pest" antagonists. Right now
we just have spiders and xenos. Everybody knows these two, so why not
mix it up a bit?
And as for balance? Blood worms are relatively easy to dispatch when you
know their weaknesses, which are extremely clear. Bleeding for hosts,
fire for either one, lasers for the worms themselves. As long as you get
the host in crit and keep hitting, you've pretty much won, and they
can't keep spamming Inject Blood forever since they'll quickly run out
of blood to use.
## Changelog
🆑
add: Added a new heavy roundstart/midround antagonist, the Blood Worm.
Credit to INFRARED_BARON for the sprites!
fix: Removing traits based on a source no longer causes issues with
trait signals.
fix: High-priority effects no longer double-trigger due to subsystem
issues.
fix: Weighted averaging in reagent merging code has been band-aid fixed.
It's not the best, but it works.
/🆑
## About The Pull Request
If a crate fails to generate, fail but actually give you the type path
so you can fix it
## Why It's Good For The Game
Ran up with an issue trying to debug the return of generate being null
while having no clue what type path it was. Prevents that headache in
future
## Changelog
N/A
## About The Pull Request
Fixes#94855
Three things
1. We filter incompatible surgical states when removing the wound. I'm
not sure if this contributed to the problem, but it seemed wrong
regardless - At that point we don't really care about incompatible
states since we're removing everything regardless
2. `COMSIG_BODYPART_UPDATING_SURGERY_STATE` was registered before adding
the states, which would cause the act of adding the states to clear the
variable.
3. The signal handler was missing the source arg, so it was removing the
wrong values.
## Changelog
🆑 Melbert
fix: Surgical state applied by wounds no longer persist after fix
/🆑
## About The Pull Request
I thought megafauna were hard to refactor into simple mobs, and they
kinda are, but also enough work has been done on them through various
refactors (e.g. mob abilities) that it's not _too_ bad, but I didn't
really relish working on it.
Regardless, it's refactored! A few more of the ol' simple mobs flushed
down the toilet, with a bunch more features to make porting over more
`megafauna` to the basic mob's `boss` framework even simpler. There's
some weird patterns that are introduced in here to better fit the old
system's parity, but I don't really mind having done that since it's
more important to get stuff out of the simple mob framework and into
something a bit easier to work with and extend.
Here are all of the changes I can recall having made:
* A lot of the documentation regarding the blood drunk miner did not
actually meet reality. The current refactor reflects what the code was
actually doing, not what was documented.
* The code regarding using the saw's `melee attack chain` stuff wasn't
changed. Sorry but I can't even start to unravel that, I just overrode
the whole attack thing because it's not really incorporable from what I
was finding.
* Basic mobs operate differently than simple mobs, thus this mob will be
"harder" for a shorter amount of time as people are not used to the
current timings/pathfinding behavior/cooldowns/etc. of the modern blood
drunk miner. The overall difficulty didn't feel too different to me in
my playtesting, but changes can certainly be made if someone can tell me
which variable to fix.
* Basic Bosses now appear in the orbit menu as mob POIs, parity with
megafauna
* Basic Bosses can now use the boss music component.
## Why It's Good For The Game
Cleans up the code by incorporating it into a modern framework that
already accounts for a lot of the stuff that was taken for granted 8-9
years ago when this was first implemented, and tries to keep any
possible number the same in doing so. Should be much easier to add new
graphics or overhaul the boss's AI to transform it into something even
more interesting should someone choose to do so.
Let me know if I fucked up with signals/ai behavior patterns/etc.
somewhere as it's been a while since I touched this stuff and I had to
clean out a lot of cobwebs in my brain to get to this implementation.
## Changelog
🆑
balance: Miners Beware: Blood Drunk Miners have been refactored into
basic mobs. This means their timings and such may be a bit more
unpredictable than what you're used to. The difficulty should be about
the same, but do approach with caution lest you get devoured...
/🆑
Hopefully more people can pitch in with refactoring megafauna now... not
too bad anymore after I fixed some of the jank...
## About The Pull Request
As title says, skin butchered from humans (currently only applies to
lizardskin) now inherits their owner's skin color, and so do items
(lizardskin boots and hats) made from it.
Also this PR gagsifies lizardskin hats and boots for this very reason.
## Why It's Good For The Game
Consistency, when you butcher a purple lizard you should get purple
lizard boots.
## Changelog
🆑
add: Made lizard skin and lizardskin items inherit their "donor's" skin
color
/🆑
## About The Pull Request
Closes#94794
Both of these unit tests were using the outdated way of changing the gas
mix on a turf, probably because they were more than a few years old
apiece. The modern way is using the `/datum/gas_mixture` and
`parse_gas_string()` to either retrieve the gas mix from cache or
generate it on-demand. Neither of these tests were doing that, and they
worked well enough until they got mutated in #94771
(01c7ef7de1).
I am uncertain of the specifics that are behind either one
spontaneously/always failing but I do know that they weren't doing it
the "right way". I suspect the flakiness in the Breath Ashwalker Sanity
(that loads a full ashwalker carbon instead of just the lungs) is
because it was initiating a gas mix with no volume within it, and that
volume would get filled up as the other turfs in the loc would update it
somewhere in the atmos chain? We only checked for the "low oxygen"
status effect on the mob and that could easily have been filled up to
normal depending on how much happened. Regardless the best way to fix
this is to just have all the turfs in the unit test room get changed to
prevent any schenanigans with that.
Another explanation for the flakiness is that the ashwalker lungs
themselves use the same "old" way of getting the gas mix instead of the
modern way (such that the lung breath values can adapt to changes)... I
think...
## Why It's Good For The Game
Less developer frustration at spontaneously failing unit tests through
no fault of their own.
## Changelog
Irrelevant
## About The Pull Request
Lightens up the Gateway CI, as it's a very memory-intensive test that
creeps ever closer to the 4gb limit.
## Why It's Good For The Game
Functional and consistent CI is good
## Changelog
N/A
## About The Pull Request
To understand the PR we should first define what is micro dosing &
volumetric dosing
- **Micro dosing:** The reagent effects are **independent** of the
volume of reagent metabolized and are constant every tick, so the effect
you get from metabolizing 0.01u of a reagent is the same as metabolizing
1u of a reagent
- **Volumetric dosing:** The reagent effects are **dependent** on the
volume of reagent metabolized per tick, so the effect you get from
metabolizing 0.01u is much lower compared to metabolizing 1u of a
reagent which is much higher
This PR replaces **micro dosing** with **volumetric dosing** so if you
increase metabolization rates and absorb more reagents you get higher
effects from that reagent & vice versa for lower metabolization rates.
With that lets ask the core questions
**How does this affect present reagent values?**
_This PR scales all reagent effects such that even if it has a lower
metabolization rate the value is the same as before but will still scale
with reagent volumes & mob metabolization levels_
Under normal circumstances most reagents metabolize at 0.4u of reagent
per tick so as long as this value isn't changed by cybernetic body parts
or other reagents you will get the same values as before and won't
notice anything different in normal gameplay.
However, if you do get enhanced body parts like a cybernetic
liver/stomach or use reagents with metabolization rates different from
0.4u you will now get more/less affects depending on how much reagent is
consumed. Here is an example
Consider Syriniver this is how the formulae look like.
```dm
adjust_tox_loss(-1 * metabolization_ratio * seconds_per_tick, updating_health = FALSE, required_biotype = affected_biotype)
```
as long as 0.4u of it is metabolized every tick you get 2 tox loss
healing which is the same as before. However, this time if you
metabolize 0.01u of the reagent you get only 0.1 tox loss healing. If
you metabolize 1u reagent per tick, then you get 5 tox loss healing
**What about cigarettes?**
Unaffected. The amount of reagents injected into a mob per tick **does
not** affect the rate at which it is metabolized. Even if you have like
10u of cigarette reagents within you, if you are metabolizing just 0.4u
of it every tick then nothing changes
## Why It's Good For The Game
- Volumetric dosing is realistic. If you metabolize more reagent you
should be getting more benefits and lesser volumes should yield lesser
affects
- Microdosing is an exploit that should have been patched a long of time
ago because it encourages people to put in minimal effort to produce
just 0.01u of reagent to get maximum affects. This coupled with slower
metabolization rates leads to unbalanced higher reagent effects for
longer periods of time.
- This PR address the core issue in #93991 which is heal all patches.
Plumbing was gutted in an unnatural way by making the plumbing iv
drip/output gate/pill press behave essentially as mini reaction chambers
by filtering just 5 reagents. With this heal all patches are nerfed
based on the number & now volume of reagents you can put in a patch, so
its concern is addressed. If this does get merged, we can hopefully
revert it and make plumbing great and behave like large factories again
<img width="914" height="230" alt="Screenshot (532)"
src="https://github.com/user-attachments/assets/96467fad-b32f-409a-a1e8-2a92b8ff6565"
/>
## Changelog
🆑
fix: probability reagent affects scale correctly
balance: reagent affects now scale with the volume of reagent
metabolized meaning lower metabolization rates (from like cybernetic
organs) yield lower effects & higher rates yield higher effects
/🆑
## About The Pull Request
Inspired by #94233. `grind_results`(list) & `juice_typepath`(typepath)
are only used when grinding & juicing after which the atom is deleted.
This means if that object is not processed these vars occupy memory &
don't do anything.
Now these values are only generated on demand by calling their
respective procs. Considering how these vars are on the obj level the
memory savings are quite significant
## Changelog
🆑
refactor: grinding & juicing have been refactored to occupy low memory.
Report bugs on github
code: improved grinding & juicing code
/🆑
## About The Pull Request
Alt to #94423 , see it for more information
Currently, the `can_baton` checks disallow harmbatonning. This is an
error.
However, untangling this code wasn't super trivial thanks to the way the
chain was split across a few procs.
This PR puts all the relevant code in `pre_attack`, so we can easily see
what contexts allows a stun, a harmbaton, both, and neither.
## Changelog
🆑 Melbert
fix: You can harm people with batons that are otherwise inoperable, like
an Abductor's baton.
refactor: Batonning was refactored ever so slightly. Report any
oddities, particularly involving harmbatonning.
/🆑
## About The Pull Request
The death moodlet was becoming a monster, and I knew it would happen but
I was too lazy to implement something proper for it, until now
`/datum/mood_event/conditional` now exists:
When this moodlet is added, it iterates over all subtypes of the moodlet
and checks to see if the subtypes fulfill some condition
Each subtype has a priority set, the highest priority condition is what
is ultimately added
This makes it significantly easier and cleaner to add new conditions to
more complex moodlets, which should make new personality dev a piece of
cake
## Changelog
🆑 Melbert
refactor: Refactored death moodlet, report any oddities
/🆑
## About The Pull Request
As the title says, this excludes Kilo & Pubby from failing CI due to the
design being added while the tech node isn't, now it's only ran if the
map has it. This was an oversight of my original PR
https://github.com/tgstation/tgstation/pull/94160
## Changelog
Nothing player-facing.
## About The Pull Request
So something i missed from when i played Goonstation a long while ago
was my blind characters, i tried recreating them in TGCode but found
that the blind quirk here is far more harsh to play visually. So i got
some help from Melbert and got a plan goin and here's the results.
Players can see colors! But muted, this change is strictly for visual
enjoyment as the constant monochrome is just - i cant really describe
how much i hate seeing it for more than 15 minutes.
Secondly the flicker is gone from the quirk but remains for all the
temporary blindness, this is 100% Melberts code as they're a helluva lot
smarter than I am and I just nod and smile before pasting it. This did
entail creating a new fulscreen in the dmi, but i just copy/pasted the
existing one and took out the animated frames and named it as 'static'
so it wouldnt interfere with anything else using it.
## Why It's Good For The Game
Playing a blind character is great, however it causes some serious
eyestrain after prolonged playstyle
## Changelog
🆑 MrMelbert, Zergspower
qol: The world is now heavily desaturated while blind, rather than pure
monochrome, to give players some visual stimulus
qol: When blind, the brief flicker of the entire screen now only appears
for mobs temporarily blinded - ie, mobs blinded from quirk / trauma /
genetic mutation no longer experience it
/🆑
## About The Pull Request
Just improves the new material unit test, making it more copy-paste
friendly when dealing with large amounts of things to change.
It now also calculates the appropriate sheet material value for you too
so you quite literally just have to copy paste the line and you're done,
no more having to do math yourself.
<img width="2104" height="155" alt="image"
src="https://github.com/user-attachments/assets/b605e423-0418-46b7-b40c-c65fac920af9"
/>
## Why It's Good For The Game
Developer qol.
## Changelog
Nothing player-facing
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
Reused the old pre-rework heretic robe and blade assets as a new set of
chaplain gear and null rod option.
Replaced the last few existing uses of the now spriteless generic robe:
- Deathmatch, changed heretic warrior to use blade robes
- Deathmatch, changed ripper to use the new chaplain armour
- Tribal mothman legion corpse, changed to use new chaplain armour
- Heretic preview and hallucination, changed to use rust robes
- Heretic virtual domain, changed to use rust robes
<img width="127" height="131" alt="image"
src="https://github.com/user-attachments/assets/690e848e-5191-44d4-bd58-5e338fa2aa4e"
/>
## Why It's Good For The Game
Chaplains are the playground of old magic content assets, where they
find a second life as cosplay outfits. Chaplains can already cosplay
cultists, it's only fair that they can pretend to be a heretic as well.
## Changelog
🆑
add: Added a new set of chaplain armour based on the generic heretic
robes unavailable since the path rework.
/🆑
## About The Pull Request
After I merged #94200 I realized it blocked all attack hand interactions
on decal which means flypeople would break
Fixes that, adds some unit tests
## Changelog
🆑 Melbert
fix: Fix Flypeople's vomit interaction before anyone realizes it's
broken but me
/🆑
## About The Pull Request
Currently mech construction icons correspond 1:1 with construction step
<img width="1357" height="349" alt="image"
src="https://github.com/user-attachments/assets/65763f51-776c-44a7-bc9e-b710db9342a1"
/>
This means if you want to add a new step in the middle of an existing
construction chain you are SOL and have to update everything manually
This suuuucks, and you will notice in the picture above that many states
*are identical*
So I have lightly refactored it:
- When steps are instantiated, it will automatically attempt to fill in
`icon_state`s according to the index in the list, as it does currently
- If the step specifies its own icon state, nothing happens, but index
goes up
- If the step specifies `skip_state`, it will neither set an icon state
nor increment the index
This means you can insert a step in the middle of an existing chain with
`skip_state = TRUE` if your state has no icon associated, OR you can
insert a step with `icon_state = "new_state", skip_state = TRUE` to add
your icon without needing to edit every existing icon
Now in an ideal world we get rid of this auto-setting system wholesale
and set bespoke icon states (`mecha_wires`, `mecha_internal_armor`,
etc). We would just define a step's `state = "wired"`, `state =
"armored"`, and so on. However, I feel like having the option of using
"default states" makes it easier during development.
Also I *could* go through and remove all the duplicate states and
replace them with `skip_state` instructions but I'm lazy. (Maybe I'll do
it anyways though)
Other changes
- Completing a construction step sends you a chat message about the next
step, so you don't have to examine the chassis to find out
- Changed around how the Phazon accepts its anomaly core
## Changelog
🆑 Melbert
refactor: Refactored how mech icons update mid-construction, report any
disappearing mechs please
fix: One of the Phazon's mid construction icons was not visible in the
past, now it is again. Yippee.
/🆑
## About The Pull Request
Extends the part of the crafting unit test that ensures consistency
between the total mats of the components of a recipe (or rather, the
result of said recipe) and a generic instance of the same type as its
result, previously only implemented on food recipes.
## Why It's Good For The Game
This ensures a degree of consistency with the material composition of
various objects in the game. I couldn't do it in the original PR as that
one was too big already and it took months to get it merged, and have
the relative bugs fixed.
Currently a WIP as I slowly deal with the unit test reports.
## Changelog
🆑
refactor: Follow-up to the crafting/material refactor from months ago.
All objects crafted with stacks now inherit their mat composition (not
necessarily the effects and color) by default, while previously only a
few things like chair, sinks and toilets did. Report any object looking
or behaving weirdly as a result.
fix: The material composition of ammo boxes is no longer a 1/10 of what
it's supposed to be. It was a shitty hack to make it harder to recycle
empty ammo boxes. Instead, they lose materials as they're emptied now.
/🆑
## About The Pull Request
Logs the coordinates of the turf causing the test failure
## Why It's Good For The Game
Knowing where the turf is can be a clue to the root cause of the failure
## Changelog
N/A
## About The Pull Request
Closes#93635
`unique_reskin` is no longer a list on `/item`, now `/datum/atom_skin`
The actual reskinning behavior has been moved out to
`/datum/component/reskinable_item`
PKC reskinning is now handled via alt-click reskin, rather than via the
retooling kit. The retooling kit has been removed.
There's no limit on how many times you can reskin your PKC (though
perhaps we limit it to one reskin and keep the retooling kit as a way to
allow a miner to reskin it a second time?)
The Ashen Skull unique reskin is still a trophy, and instead unlocks its
unique reskin option in the alt-click radial.
## Why It's Good For The Game
I'm unsure why the retooling kit exists on its own, when it's relatively
cheap and just performs the behavior of alt-click reskinning.
So to keep it consistent with all other forms of reskinning I've just
made it baseline. To accomplish that I refactored reskinning.
The new form of reskinning allows for greater potential in adding
reskins, allowing far more than just an icon state change. Also we can
put it on turfs and mobs and structures now which is cool I guess
There's also the added benefit of being able to see an item's reskins
without needing to instantiate it, which the loadout menu uses to great
effect.
## Changelog
🆑 Melbert
refactor: Refactored item reskinning (the alt-click way), report any
oddities with that
del: Deleted the crusher retool kit, now you can just reskin your
crusher with alt-click. The Skull skin is still locked behind having the
Ashen Skull trophy applied.
fix: Stunswords no longer have an incorrect lore blurb
fix: Fixed loadout item reskinning's UI
/🆑
## About The Pull Request
Depends on #94064 for the unit test but offers a better method for
finding an atom to mount on
- Finding a mount now takes into consideration the objects pixel x & y
offsets meaning diagonal mounting is now supported. Gives great
flexibility for mappers
- If you don't want to use pixel offsets but default back to using the
objects direction that behaviour is still preserved. Useful if your
object uses directional icon states(lights & cameras for now) AND don't
use offsets
- If no direction could be specified then as the last resort it defaults
back to the objects local turf for mounting
## Changelog
🆑
fix: all mounted objects on tables, fences, windows & walls should fall
of correctly when the atom it is placed on is destroyed
fix: security telescreen now falls off when their mounted wall is
destroyed
fix: defib wall mount falls off when their mounted wall is destroyed
fix: floor lights are mounted to the ground/catwalk/tram floor they are
sitting on meaning destroying it will destroy the light
fix: wall mounted plaques now fall off when their mounted wall is
destroyed
/🆑
