## About The Pull Request
Adds HIDEFRILLS flag for clothing if you need to only hide frills
without hiding ears and lets you hide them through
Show/Hide-Mutant-Parts verb
## Why It's Good For The Game
You couldn't hide them before with that verb and now you can. Not sure
if HIDEFRILLS will be used if HIDEEARS also hides frills but now that's
an option if you need to only hide frills without ears
## Proof Of Testing
<details>
<summary>Screenshots/Videos</summary>
<img width="276" height="116" alt="1"
src="https://github.com/user-attachments/assets/484474c1-2f8b-409d-b3d4-2713822fd612"
/>
(i varedited gas mask to have HIDEFRILLS flag, this doesn't actually
apply the flag to it in the code)
<img width="364" height="201" alt="2"
src="https://github.com/user-attachments/assets/264c0881-653c-4f0b-9497-f0f7880c46d5"
/>
</details>
## Changelog
🆑
add: Show/Hide-Mutant-Parts verb now can hide lizard frills
add: HIDEFRILLS clothing flag if you need to hide specifically just
frills
/🆑
## 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
`create_from_ghost` can be called from stuff like... dynamic executing a
ruleset, so putting a sleep/user input within it causes problems
So I refactored ghost spawns a fair bit, creating a clear delineation
between where you can and can't put user input
## Changelog
🆑 Melbert
fix: Pirates will no longer randomly spawn as human
fix: Servant Golems have numbered names again
refactor: Refactored ghost spawns (like spider eggs or pirate spawners),
report any oddities
/🆑
## About The Pull Request
Fixes https://github.com/tgstation/tgstation/issues/90641
Fixes https://github.com/tgstation/tgstation/issues/88366
Eliminates worries over virtualspace currency being sent to real
accounts.
When I was looking into why there were no flags for bitrunning areas.
Then I saw this mess:
<img width="929" height="889" alt="Code_2we2QjDyFp"
src="https://github.com/user-attachments/assets/8a807bfe-b566-4057-a8ea-2b306325687d"
/>
Not having enough space / being too lazy to refactor this is a silly
reason to not include flags for something like these virtual areas where
it can be quite helpful. Fortunately I am not too lazy ~~in this
moment~~ so here we go:
It was fairly logical to move over some of these to a separate flag,
which I've called `area_flags_mapping` since they pertain to maploading
things and terrain generation mostly. `area_flags` stays reserved for
general properties and now has more room than it did before for you
people to fill it with.
In doing this it's also neatened up the code quit a bit, as UNIQUE_AREA
was kind of everywhere and now that it's implied by default less areas
need to have it defined (or explicitly un-defined).
<details> <summary> Working as intended </summary>
<img width="787" height="448" alt="dreamseeker_p0Qts36tG1"
src="https://github.com/user-attachments/assets/25056f34-8d43-4be2-a293-e53df7a7d1db"
/>
<img width="383" height="59" alt="dreamseeker_Ek7TXCcpbA"
src="https://github.com/user-attachments/assets/89622974-9467-4cdb-8345-d684f7c9004b"
/>
</details>
## Why It's Good For The Game
Fixes an exploit, improves the area flags situation slightly.
## Changelog
🆑
fix: you can no longer send money from virtualspace to a real account
code: adds a flag for virtual areas so they can easily be checked, as
well as an easy helper proc, 'is_area_virtual(your_area)'
/🆑
## About The Pull Request
title
## Why It's Good For The Game
Envirosuits get damaged easily, 1 shredded limb means whole body on
fire.
It is a feedback loop that will result in more damage to the victim and
their gear, life-supporting & the suit itself included.
It is hard to notice by others & needs to be held/worn for fixing.
<img width="127" height="78" alt="image"
src="https://github.com/user-attachments/assets/6645a6c8-27aa-48f2-a1e4-1696b1359f01"
/>
## Changelog
🆑
balance: Plasmamen not catching in fire anymore from the slightest wind
blow on their envirosuits.
/🆑
## About The Pull Request
When take a ghost role from a ghost role sleeper, if you became a ghost
by observing you will be offered the opportunity to spawn in as your
static. Obviously if you joined the round normally or have already
spawned in as a ghost role you won't be prompted. No cloning yourself
allowed.
Not every ghost role allows this, and you won't get the prompt if your
static is a race that breathes plasma (basically just those purple
skeletons) because that opens up a giant can of worms. However, you
_will_ get the prompt if you are playing as any other race. (I'm pretty
sure every ghost role has power for ethereals besides ashwalkers but
that's not one of the ghost roles that lets you spawn as your static for
super obvious reasons)
Some ghost roles, like pirates, will allow you to spawn in as your
static but overwrite your name.
## Why It's Good For The Game
Felinid comms agent felinid comms agent felinid comms agent felinid
comms agent felinid comms agent felinid comms agent felinid comms agent
felinid comms agent felinid comms agent felinid comms agent felinid
comms agent felinid comms agent felinid comms agent felinid comms agent
## Changelog
🆑
add: You may now spawn in as your static when picking a ghost role
/🆑
---------
Co-authored-by: Fghj240 <fakeemail@notrealemail.com>
## About The Pull Request
Adds a wood biological type for limbs and adds internal descriptions for
flesh and wood.
## Why It's Good For The Game
Fixes#93889
## Changelog
🆑 LT3
fix: Peg limbs are now internally classified as wooden
/🆑
## About The Pull Request
Empath has become a component instead of a trait, letting it store
variables or whatever components are good for. Also, it works slightly
differently for empath quirk users and moon heretics alike.
Additionally:
- You can only shiver when you see an evil person once. After that it
won't happen again.
- Empaths no longer get a mood debuff from seeing someone distressed.
- Moon heretic empaths no longer get smited by evil people.
- Moon heretic empaths aren't scared of evil people.
The component also supports empaths being able to tell if a fake dead
body is actually dead, and being able to use empath on yourself, but
those aren't enabled for the empath quirk or moon heretics. (Self-empath
would probably powercreep self aware)
## Why It's Good For The Game
While the empath quirk is incompatible with the evil quirk, the trait
wasn't. That means you could potentially become an evil empath and still
feel bad about other people feeling bad and get smited by other evil
people. Being an empath is different from having empathy, and there's
now a personality trait (compassionate) that has a very similar feature
so the mood debuff got axed and moon heretics can't get smited by
mending touch anymore.
I think being a heretic and looking into pierced realities probably
means you have the mental fortitude to not freak out when you see an
evil person. Evil people are (probably) a lot less scary than whatever
mind destroying thing is in those holes.
As for the only-getting-scared-once bit, freaking out when you see an
evil person is flavorful but annoying after it happens multiple times.
Especially if it happens after examining the same person multiple times.
## About The Pull Request
ports https://github.com/DaedalusDock/daedalusdock/pull/1144
ports https://github.com/DaedalusDock/daedalusdock/pull/1147
full credit to @Kapu1178 for the juice
instead of `reacher.CanReach(target)` we now do
`target.CanBeReachedBy(reacher)`, this allows us to give special
behavior to atoms which we want to reach, which is exactly what I need
for a feature I'm working on.
## Why It's Good For The Game
allows us to be more flexible with reachability
## Changelog
🆑
refactor: refactored how reaching items works, report any oddities with
being unable to reach something you should be able to!
/🆑
## 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
Food items pass down their intrinsic materials during crafting, which
should prevent foods being crafted from meat being red and squishy. The
implementation might be too broad or kinda suck but it worked for the
problem items I tested it on (headcheese, crispy breaded headcheese,
moussaka, ballpark tsukune).
Also properly sets up `material_flags` to be a bitflag when viewing
variables.
## Why It's Good For The Game
Makes intrinsic food materials actually do what they're supposed to do
(prevent food being crafted with meat from being weirdly too meaty).
## Changelog
🆑
code: Materials bitflags should now show the bitflag interface in VV.
fix: Food items now pass down their intrinsic materials during
crafting/processing/microwaving/etc. etc.
/🆑
Co-authored-by: Hatterhat <Hatterhat@users.noreply.github.com>
## About The Pull Request
1. The Energy Katana, when clicking on a mob, no longer refuses to
teleport. It will instead teleport you adjacent to the mob (to the tile
closest to your origin) and immediately perform an attack.
2. Energy Katana is now a bit more consistent about what you can and
cannot teleport to, now abiding by the same rules as the heirophant
staff - you can teleport onto tables, but you can't teleport into dense
objects by clicking on the tile instead of the object.
3. The Energy Katana now has `NEEDS_PERMIT` flag, like the Energy Sword,
meaning Beepsky will consider it a threat (but it won't hunt down Ninjas
over it)
Also added pass_flags_self bitfield and updated pass_flags bitfield.
## Why It's Good For The Game
I ran around with it for like 3 seconds and found it a little clunky. So
I just cleaned it up a bit to make it 1. easier to use 2. cooler to use
The permit thing was just making it consistent with other melee weapons
## Changelog
🆑 Melbert
qol: Energy Katana is now a bit more consistent about what you can and
cannot teleport to, now abiding by the same rules as the heirophant
staff. IE, you can now teleport onto tables.
add: Energy Katana now has a "teleport attack" - if you click on a mob,
you will teleport adjacent to them and immediately perform an attack!
add: Energy Katana is now considered a threatening weapon by secbots.
Ninjas will be unaffected, but if you loot one off a dead ninja and
don't have a weapons permit, it might chase after you.
/🆑
## About The Pull Request
Food items pass down their intrinsic materials during crafting, which
should prevent foods being crafted from meat being red and squishy. The
implementation might be too broad or kinda suck but it worked for the
problem items I tested it on (headcheese, crispy breaded headcheese,
moussaka, ballpark tsukune).
Also properly sets up `material_flags` to be a bitflag when viewing
variables.
## Why It's Good For The Game
Makes intrinsic food materials actually do what they're supposed to do
(prevent food being crafted with meat from being weirdly too meaty).
## Changelog
🆑
code: Materials bitflags should now show the bitflag interface in VV.
fix: Food items now pass down their intrinsic materials during
crafting/processing/microwaving/etc. etc.
/🆑
Co-authored-by: Hatterhat <Hatterhat@users.noreply.github.com>
## About The Pull Request
1. The Energy Katana, when clicking on a mob, no longer refuses to
teleport. It will instead teleport you adjacent to the mob (to the tile
closest to your origin) and immediately perform an attack.
2. Energy Katana is now a bit more consistent about what you can and
cannot teleport to, now abiding by the same rules as the heirophant
staff - you can teleport onto tables, but you can't teleport into dense
objects by clicking on the tile instead of the object.
3. The Energy Katana now has `NEEDS_PERMIT` flag, like the Energy Sword,
meaning Beepsky will consider it a threat (but it won't hunt down Ninjas
over it)
Also added pass_flags_self bitfield and updated pass_flags bitfield.
## Why It's Good For The Game
I ran around with it for like 3 seconds and found it a little clunky. So
I just cleaned it up a bit to make it 1. easier to use 2. cooler to use
The permit thing was just making it consistent with other melee weapons
## Changelog
🆑 Melbert
qol: Energy Katana is now a bit more consistent about what you can and
cannot teleport to, now abiding by the same rules as the heirophant
staff. IE, you can now teleport onto tables.
add: Energy Katana now has a "teleport attack" - if you click on a mob,
you will teleport adjacent to them and immediately perform an attack!
add: Energy Katana is now considered a threatening weapon by secbots.
Ninjas will be unaffected, but if you loot one off a dead ninja and
don't have a weapons permit, it might chase after you.
/🆑
## About The Pull Request
Because it does nothing.
The only reagents that had this flag were inverse reagents & some
medicines but those reagents already had their `inverse_chem` set to
null meaning they are incapable of splitting even without this flag.
From the comments it said the flag had something to do with stomachs
constantly calling `on_mob_add()` which would split the reagent twice
however upon inspecting stomach code no such thing exists so it didn't
create any problems.
Once the reagent enters the mob it splits just once because purity is
preserved when transferring the reagent to different organs so this flag
never had a chance to do anything
Less code to worry about
## Changelog
🆑
code: removed `REAGENT_NOSPLIT` flag
/🆑
## About The Pull Request
Because it does nothing.
The only reagents that had this flag were inverse reagents & some
medicines but those reagents already had their `inverse_chem` set to
null meaning they are incapable of splitting even without this flag.
From the comments it said the flag had something to do with stomachs
constantly calling `on_mob_add()` which would split the reagent twice
however upon inspecting stomach code no such thing exists so it didn't
create any problems.
Once the reagent enters the mob it splits just once because purity is
preserved when transferring the reagent to different organs so this flag
never had a chance to do anything
Less code to worry about
## Changelog
🆑
code: removed `REAGENT_NOSPLIT` flag
/🆑
## About The Pull Request
Open cabin mechs cannot be piloted by silicon pilots. MMI's, uploaded
AI's, positronics or AI control beacons. The mechs can still be tracker
beaconed. It can also be dominated via the malfunctioning AI power.
Adds some flags to help flag which mechs can or cannot be beaconed, or
which are silicon compatible.
## Why It's Good For The Game
I'm not going to lie. I do feel a bit pressured on this change in
particular. This is somewhat meant to be an intended feature.
But I think the cats out of the bag on open cabin mechs and the ways to
circumvent their downsides. And the more I think about it, the more I
come to realize that I frankly haven't had many, if any, good
interactions with a posibrain/MMI mech army. So making that more
efficient is...a problem.
Using a silicon-based pilot can help you evade the potential
consequences of being a flesh and bone pilot inside of a steel mesh
cabin and being shot repeatedly. So you may as well, in those instances,
treat it as a sealed cabin mech. And these mechs are surprisingly pretty
strong statistically. Especially the Paddy with its ability to equip
actual lethal weaponry.
They're cheap, can be mass produced, come out early, and durable. The
only limitation is pilots, and if you're printing positronics and get
ghosts for those positronics, you can usually just keep producing more.
From a purely objective standpoint, there isn't much reason to not push
out posi-paddys over any other mech. Rather than settle for a perfect
answer, let's at least require some human pilots in these mechs so that
their supposed downside is more of an Achilles heel.
## Changelog
🆑
balance: Caged mechs cannot accept silicon pilots. AI uploaded pilots,
AI control beacons, MMIs or positronics. Malfunctioning AIs can still
dominate these mechs.
code: Allows for a higher degree of granularity for what mechs can and
cannot accept by including additoinal mecha flags to block beacon type
installations, pilot uploads and so on.
/🆑
## About The Pull Request
Open cabin mechs cannot be piloted by silicon pilots. MMI's, uploaded
AI's, positronics or AI control beacons. The mechs can still be tracker
beaconed. It can also be dominated via the malfunctioning AI power.
Adds some flags to help flag which mechs can or cannot be beaconed, or
which are silicon compatible.
## Why It's Good For The Game
I'm not going to lie. I do feel a bit pressured on this change in
particular. This is somewhat meant to be an intended feature.
But I think the cats out of the bag on open cabin mechs and the ways to
circumvent their downsides. And the more I think about it, the more I
come to realize that I frankly haven't had many, if any, good
interactions with a posibrain/MMI mech army. So making that more
efficient is...a problem.
Using a silicon-based pilot can help you evade the potential
consequences of being a flesh and bone pilot inside of a steel mesh
cabin and being shot repeatedly. So you may as well, in those instances,
treat it as a sealed cabin mech. And these mechs are surprisingly pretty
strong statistically. Especially the Paddy with its ability to equip
actual lethal weaponry.
They're cheap, can be mass produced, come out early, and durable. The
only limitation is pilots, and if you're printing positronics and get
ghosts for those positronics, you can usually just keep producing more.
From a purely objective standpoint, there isn't much reason to not push
out posi-paddys over any other mech. Rather than settle for a perfect
answer, let's at least require some human pilots in these mechs so that
their supposed downside is more of an Achilles heel.
## Changelog
🆑
balance: Caged mechs cannot accept silicon pilots. AI uploaded pilots,
AI control beacons, MMIs or positronics. Malfunctioning AIs can still
dominate these mechs.
code: Allows for a higher degree of granularity for what mechs can and
cannot accept by including additoinal mecha flags to block beacon type
installations, pilot uploads and so on.
/🆑
## About The Pull Request
Ostensibly https://github.com/tgstation/tgstation/pull/91063 but about
melee weapons. While in combat mode, hitting a mech with a melee weapon
that possesses armor penetration can potentially hit the pilot as well.
This hits both pilot AND mech. (We check for combat mode mostly because
it is convenient as a user intention control)
The calculation to determine the probability of hitting someone inside
of a mech is ``armour_penetration`` - ``MELEE Armor / 2``
The passed attack is reduced by a multiplier equal to the probability /
100. So, if an attack had a 50% chance of penetrating into the pilot, it
would reduce the attack down to just 0.5 of its expected force.
## Why It's Good For The Game
Many of the same factors for projectiles with AP against mechs apply to
melee weapons, even though there are standouts amongst the list that
will destroy a mech in quick order (energy swords mostly). However, many
of the AP weapons that crew get aren't super good at killing mechs
themselves.
Some tider with a spear made of bullshitium glass could stick someone in
an elite modsuit clean through, but for whatever reason this same logic
may not necessarily apply to mechs due to their nature as objects, and
the limitations caused by demolition mods impacting their effectiveness.
IF the weapon can bypass at least half the mechs armor, hitting the
pilot sounds like a reasonable upside for trying to take on a mech in
melee.
Some people are of the opinion that killing a mech in melee is not only
the best approach, but easy. Personally, I think I've killed more people
who believe this to be true and to their horror discover that mechs can
turn on a dime (and have a stun melee punch if they're a combat mech
with a separate cooldown to their guns) than those who actually give
mechs the necessary wide berth to not get skill checked by someone who
knows their shit. But I do respect people who do it anyway so why not
give them a reason to do it and get a cool story out of it?
(Also I want to see a captain stab a pilot to death through his mech
using the sabre. Or the Power Crepe I guess.)
## About The Pull Request
The cell contained within energy guns can sometimes be destroyed due
to...reasons. This makes it so that the cell is bombproof, and if the
gun is indestructible, also indestructible for good measure.
## Why It's Good For The Game
This is basically a constant problem that doesn't seem to ever go away
due to the fact that the cell is an actual physical object and not an
abstraction.
While it remains an actual object, lets just...make it not break and
brick an important item, yeah?
## Changelog
🆑
fix: If an energy weapon is indestructible, so is the cell within the
weapon.
fix: Cells inside of energy guns are bomb proof so as to not brick a gun
that somehow survives being bombed.
/🆑
Revival of https://github.com/tgstation/tgstation/pull/86482, which is
even more doable now that we have rustg iconforge generation.
What this PR does:
- Sets up every single GAGS icon in the game to have their own preview
icon autogenerated during compile. This is configurable to not run
during live. The icons are created in `icons/map_icons/..`
- This also has the side effect of providing accurate GAGS icons for
things like the loadout menu. No more having to create your own
previews.
<details><summary>Mappers rejoice!</summary>
</details>
<details><summary>Uses iconforge so it does not take up much time during
init</summary>
</details>
---
this still applies:
Note for Spriters:
After you've assigned the correct values to vars, you must run the game
through init on your local machine and commit the changes to the map
icon dmi files. Unit tests should catch all cases of forgetting to
assign the correct vars, or not running through init.
Note for Server Operators:
In order to not generate these icons on live I've added a new config
entry which should be disabled on live called GENERATE_ASSETS_IN_INIT in
the config.txt
No more error icons in SDMM and loadout.
🆑
refactor: preview icons for greyscale items are now automatically
generated, meaning you can see GAGS as they actually appear ingame while
mapping or viewing the loadout menu.
/🆑
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
## About The Pull Request
Ostensibly https://github.com/tgstation/tgstation/pull/91063 but about
melee weapons. While in combat mode, hitting a mech with a melee weapon
that possesses armor penetration can potentially hit the pilot as well.
This hits both pilot AND mech. (We check for combat mode mostly because
it is convenient as a user intention control)
The calculation to determine the probability of hitting someone inside
of a mech is ``armour_penetration`` - ``MELEE Armor / 2``
The passed attack is reduced by a multiplier equal to the probability /
100. So, if an attack had a 50% chance of penetrating into the pilot, it
would reduce the attack down to just 0.5 of its expected force.
## Why It's Good For The Game
Many of the same factors for projectiles with AP against mechs apply to
melee weapons, even though there are standouts amongst the list that
will destroy a mech in quick order (energy swords mostly). However, many
of the AP weapons that crew get aren't super good at killing mechs
themselves.
Some tider with a spear made of bullshitium glass could stick someone in
an elite modsuit clean through, but for whatever reason this same logic
may not necessarily apply to mechs due to their nature as objects, and
the limitations caused by demolition mods impacting their effectiveness.
IF the weapon can bypass at least half the mechs armor, hitting the
pilot sounds like a reasonable upside for trying to take on a mech in
melee.
Some people are of the opinion that killing a mech in melee is not only
the best approach, but easy. Personally, I think I've killed more people
who believe this to be true and to their horror discover that mechs can
turn on a dime (and have a stun melee punch if they're a combat mech
with a separate cooldown to their guns) than those who actually give
mechs the necessary wide berth to not get skill checked by someone who
knows their shit. But I do respect people who do it anyway so why not
give them a reason to do it and get a cool story out of it?
(Also I want to see a captain stab a pilot to death through his mech
using the sabre. Or the Power Crepe I guess.)
## About The Pull Request
The cell contained within energy guns can sometimes be destroyed due
to...reasons. This makes it so that the cell is bombproof, and if the
gun is indestructible, also indestructible for good measure.
## Why It's Good For The Game
This is basically a constant problem that doesn't seem to ever go away
due to the fact that the cell is an actual physical object and not an
abstraction.
While it remains an actual object, lets just...make it not break and
brick an important item, yeah?
## Changelog
🆑
fix: If an energy weapon is indestructible, so is the cell within the
weapon.
fix: Cells inside of energy guns are bomb proof so as to not brick a gun
that somehow survives being bombed.
/🆑
## About The Pull Request
Revival of https://github.com/tgstation/tgstation/pull/86482, which is
even more doable now that we have rustg iconforge generation.
What this PR does:
- Sets up every single GAGS icon in the game to have their own preview
icon autogenerated during compile. This is configurable to not run
during live. The icons are created in `icons/map_icons/..`
- This also has the side effect of providing accurate GAGS icons for
things like the loadout menu. No more having to create your own
previews.
<details><summary>Mappers rejoice!</summary>
</details>
<details><summary>Uses iconforge so it does not take up much time during
init</summary>
</details>
---
### Copied from https://github.com/tgstation/tgstation/pull/86482 as
this still applies:
Note for Spriters:
After you've assigned the correct values to vars, you must run the game
through init on your local machine and commit the changes to the map
icon dmi files. Unit tests should catch all cases of forgetting to
assign the correct vars, or not running through init.
Note for Server Operators:
In order to not generate these icons on live I've added a new config
entry which should be disabled on live called GENERATE_ASSETS_IN_INIT in
the config.txt
## Why It's Good For The Game
No more error icons in SDMM and loadout.
## Changelog
🆑
refactor: preview icons for greyscale items are now automatically
generated, meaning you can see GAGS as they actually appear ingame while
mapping or viewing the loadout menu.
/🆑
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
## About The Pull Request
Title. If compiled on 515 the game screen will be black
## Why It's Good For The Game
There is no reason for it to exist if connecting from 515 is not allowed
Introducing more weather types! And yes, you can now have rain be
reagent based!
<details>
<summary>Regular Rain</summary>
</details>
<details>
<summary>Blood Rain</summary>
</details>
<details>
<summary>Acid Rain</summary>
</details>
You can even make it rain ants, plasma, or drugs. All of their effects
get applied to turfs, objects, and mobs depending on the weather options
you select.
Did I mention... there is thunder?
<details>
<summary>Thunder Strikes</summary>
</details>
<details>
<summary>Sand Storms</summary>
</details>
Despite all this new stuff, none of it has been directly added to the
game but the code can be used in the future for:
- Wizard event - Similar to lava on floor, but this time make the
reagent random or picked from a list and give wizard immunity
- Chaplain ability - Maybe make this a benefit or ability once enough
favor has been obtained
- Admin events - I have added a BUNCH of admin tooling to run customized
weather events that let you control a lot of options
- New station maps/biomes for downstreams (Jungle Station, etc.)
- Change Ion storms to use the new weather system that triggers
EMP/thunder effects across the station
- IceBox could get plasma rain
- Lavaland could get thunder effects applied to ash storms
Relevant PRs that removed/added some of the weather stuff I used:
- #60303
- #25222
---
- Rain sprites were added via [novaepee](https://github.com/novaepee) in
https://github.com/tgstation/TerraGov-Marine-Corps/pull/9675
- Sand sprites were added via [TiviPlus](https://github.com/TiviPlus)
(who commissioned them from bimmer) in
https://github.com/tgstation/TerraGov-Marine-Corps/pull/4645
- Rain sounds [already existed on
tg](https://github.com/tgstation/tgstation/pull/25222#discussion_r106794579)
and were provided by provided by Cuboos, using Royalty Free sounds,
presumed under default tg sound license - Creative Commons 3.0 BY-SA
- Siren sound is from siren.wav by IFartInUrGeneralDirection --
[Freesound](https://freesound.org/s/46092/) -- License: Attribution 4.0
The original `siren.ogg` sound used on a lot of SS13 servers doesn't
seem to have any attribution that I could locate. The sound was added
about 15 years ago. So I just looked for a somewhat similar sounding
siren noise on Freesound.
More weather customization!
🆑
add: Added new weather types for rain and sandstorms. Rain now uses a
reagent that gets exposed to the turfs, mobs, and objects. There is also
a thunder strike setting you can apply to any weather.
add: Hydro trays and soil will now add reagents to their trays when
exposed to a chemical reaction. (weather, shower, chem spills, foam
grenades, etc.)
add: Weather temperature now affects weather reagents and mobs body
temperature.
bal: Snowstorm temperature calculations were tweaked to allow universal
weather temperature effects.
sound: Added weather sounds from TGMC for rain and sirens (attributed to
Cuboos and IFartInUrGeneralDirection )
image: Added weather images from TGMC for rain and sand storms
(attributed to Novaepee and Bimmer)
refactor: Refactored a lot of the weather code to be more robust
admin: Admins can now control more weather related options when running
weather events. The weather admin verbs have been moved to their own
"Weather" category under the Admin tab.
/🆑
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
Added two new "layers" to hairstyles. The first draws on the normal hair
layer but resists being affected by hair masks unless a piece of
clothing really insists that it must mask it. The second draws on top of
the headwear layer and will ignore all hair masking, but will disappear
entirely if a piece of clothing covers the part of the head that
hairpiece originates from.
Each of these "Layers" (called "hair appendages" in the code) is
associated with a part of the head that it comes off of (left side,
rear, right side, etc.), which pieces of clothing can cover to prevent
those parts from being shown. For example, a Beret will allow a ponytail
to sprout off the back of a person's head and ignore the normal hair
mask, but a winter coat hood covers every part of the head except the
front, so it will hide the ponytail completely.
## Costs
Hairstyles that use this system require some extra icon blending, but
each hairstyle will cache the result of each blend whenever a new hair
mask is applied, so the extra cost only happens once. The cache will
also be used on hairstyles that don't utilize the additional layers, so
we should end up with less total icon blending over the course of a
round than we currently have.
Adds a new sprite layer, OUTER_HAIR_LAYER, to humans.
Changes hair masks from strings specifying an icon state to datums with
an icon state and a bitfield storing which parts of the head the
headware that uses them cover. The singletons for these datums are
stored in the SSaccessories subsystem.
Any hairstyle that uses this system will need 1-2 more icon states in
the human_face.dmi file. I currently have 32 hairstyles marked that
could reasonably use this system, about half of which use both
additional icon states.
## Images
Old system:
New system:
The new system is currently only implemented on the "Ponytail (High)"
hairstyle for demonstration and testing. I have a branch with the same
update for most similar hairstyles I can push if this is merged.
## Why It's Good For The Game
Hair masks are okay but they look really bad with some hairstyles. This
allows people who really care about their character's look to make their
hairstyles work with their favorite hats.
Potential for fixing #88886
## Changelog
🆑
add: Added a system to create hairstyles with multiple layers to allow
better interaction with hats and helmets
image: Added additional sprite layers to the Ponytail (High) hairstyle
/🆑
---------
Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com>
## About The Pull Request
People have been putting the `STYLE_TAUR` defines in the
`supports_variations_flags` variable even though thats not what its
fuckin for and so some clothes just randomly had a bunch of variation
flags enabled that they dont support the taur stuff just detects if you
have the worn sprite vars set for the taur stuff its automatic theres no
need for the flags it just breaks stuff also some of the stupid lewd
clothing was really broken so i fixed that too
## Why It's Good For The Game
Fixes#3590
## Proof Of Testing
<details>
<summary>Screenshots/Videos</summary>
</details>
## Changelog
🆑
fix: fixed botany apron showing up as overalls on digi users
image: some sprites that were broken on alt body types might be fixed
who knows really
/🆑
## About The Pull Request
Title. If compiled on 515 the game screen will be black
## Why It's Good For The Game
There is no reason for it to exist if connecting from 515 is not allowed
## About The Pull Request
##### Disclaimer - Some of the code/icons/sounds were ported from TMGC.
Introducing more weather types! And yes, you can now have rain be
reagent based!
<details>
<summary>Regular Rain</summary>
</details>
<details>
<summary>Blood Rain</summary>
</details>
<details>
<summary>Acid Rain</summary>
</details>
You can even make it rain ants, plasma, or drugs. All of their effects
get applied to turfs, objects, and mobs depending on the weather options
you select.
Did I mention... there is thunder?
<details>
<summary>Thunder Strikes</summary>
</details>
<details>
<summary>Sand Storms</summary>
</details>
Despite all this new stuff, none of it has been directly added to the
game but the code can be used in the future for:
- Wizard event - Similar to lava on floor, but this time make the
reagent random or picked from a list and give wizard immunity
- Chaplain ability - Maybe make this a benefit or ability once enough
favor has been obtained
- Admin events - I have added a BUNCH of admin tooling to run customized
weather events that let you control a lot of options
- New station maps/biomes for downstreams (Jungle Station, etc.)
- Change Ion storms to use the new weather system that triggers
EMP/thunder effects across the station
- IceBox could get plasma rain
- Lavaland could get thunder effects applied to ash storms
Relevant PRs that removed/added some of the weather stuff I used:
- #60303
- #25222
---
#### Attribution
- Rain sprites were added via [novaepee](https://github.com/novaepee) in
https://github.com/tgstation/TerraGov-Marine-Corps/pull/9675
- Sand sprites were added via [TiviPlus](https://github.com/TiviPlus)
(who commissioned them from bimmer) in
https://github.com/tgstation/TerraGov-Marine-Corps/pull/4645
- Rain sounds [already existed on
tg](https://github.com/tgstation/tgstation/pull/25222#discussion_r106794579)
and were provided by provided by Cuboos, using Royalty Free sounds,
presumed under default tg sound license - Creative Commons 3.0 BY-SA
- Siren sound is from siren.wav by IFartInUrGeneralDirection --
[Freesound](https://freesound.org/s/46092/) -- License: Attribution 4.0
The original `siren.ogg` sound used on a lot of SS13 servers doesn't
seem to have any attribution that I could locate. The sound was added
about 15 years ago. So I just looked for a somewhat similar sounding
siren noise on Freesound.
## Why It's Good For The Game
More weather customization!
## Changelog
🆑
add: Added new weather types for rain and sandstorms. Rain now uses a
reagent that gets exposed to the turfs, mobs, and objects. There is also
a thunder strike setting you can apply to any weather.
add: Hydro trays and soil will now add reagents to their trays when
exposed to a chemical reaction. (weather, shower, chem spills, foam
grenades, etc.)
add: Weather temperature now affects weather reagents and mobs body
temperature.
bal: Snowstorm temperature calculations were tweaked to allow universal
weather temperature effects.
sound: Added weather sounds from TGMC for rain and sirens (attributed to
Cuboos and IFartInUrGeneralDirection )
image: Added weather images from TGMC for rain and sand storms
(attributed to Novaepee and Bimmer)
refactor: Refactored a lot of the weather code to be more robust
admin: Admins can now control more weather related options when running
weather events. The weather admin verbs have been moved to their own
"Weather" category under the Admin tab.
/🆑
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
Added two new "layers" to hairstyles. The first draws on the normal hair
layer but resists being affected by hair masks unless a piece of
clothing really insists that it must mask it. The second draws on top of
the headwear layer and will ignore all hair masking, but will disappear
entirely if a piece of clothing covers the part of the head that
hairpiece originates from.
Each of these "Layers" (called "hair appendages" in the code) is
associated with a part of the head that it comes off of (left side,
rear, right side, etc.), which pieces of clothing can cover to prevent
those parts from being shown. For example, a Beret will allow a ponytail
to sprout off the back of a person's head and ignore the normal hair
mask, but a winter coat hood covers every part of the head except the
front, so it will hide the ponytail completely.
## Costs
Hairstyles that use this system require some extra icon blending, but
each hairstyle will cache the result of each blend whenever a new hair
mask is applied, so the extra cost only happens once. The cache will
also be used on hairstyles that don't utilize the additional layers, so
we should end up with less total icon blending over the course of a
round than we currently have.
Adds a new sprite layer, OUTER_HAIR_LAYER, to humans.
Changes hair masks from strings specifying an icon state to datums with
an icon state and a bitfield storing which parts of the head the
headware that uses them cover. The singletons for these datums are
stored in the SSaccessories subsystem.
Any hairstyle that uses this system will need 1-2 more icon states in
the human_face.dmi file. I currently have 32 hairstyles marked that
could reasonably use this system, about half of which use both
additional icon states.
## Images
Old system:
New system:
The new system is currently only implemented on the "Ponytail (High)"
hairstyle for demonstration and testing. I have a branch with the same
update for most similar hairstyles I can push if this is merged.
## Why It's Good For The Game
Hair masks are okay but they look really bad with some hairstyles. This
allows people who really care about their character's look to make their
hairstyles work with their favorite hats.
Potential for fixing #88886
## Changelog
🆑
add: Added a system to create hairstyles with multiple layers to allow
better interaction with hats and helmets
image: Added additional sprite layers to the Ponytail (High) hairstyle
/🆑
---------
Co-authored-by: SmArtKar <44720187+SmArtKar@users.noreply.github.com>
## About The Pull Request
Makes wrapper procs to support working with bitflags as defined "things"
rather then EXCLUSIVELY numbers, mostly for getting random flags.
I've ~~also added a unit test to prevent bitfields from being double
defined~~ stolen some code form moth to make double definitions here a
compile error.
This does rely on people actually using the bitfield lists, essentially
upgrading them from breaking just admin debug to POTENTIALLY breaking
game logic (slightly). Would like input on this @tgstation/commit-access
## Why It's Good For The Game
More tools for feature coders to play with, more sane code
## About The Pull Request
Change `/obj/item/construction/examine` so that if there's any upgrades
installed it will list their names in the examine text. Also add a
`/datum/bitfield` entry for RCD upgrades for a little debug QOL.
## Why It's Good For The Game
It sucks to accidentally print an upgrade you already have for the RCD.
## Changelog
🆑
qol: The RCD examine text now lists any upgrades it has installed.
/🆑
## About The Pull Request
Change `/obj/item/construction/examine` so that if there's any upgrades
installed it will list their names in the examine text. Also add a
`/datum/bitfield` entry for RCD upgrades for a little debug QOL.
## Why It's Good For The Game
It sucks to accidentally print an upgrade you already have for the RCD.
## Changelog
🆑
qol: The RCD examine text now lists any upgrades it has installed.
/🆑
## About The Pull Request
Fixes https://github.com/tgstation/tgstation/issues/87345
This adds a new item trait, `TRAIT_NO_WORN_ICON`, which is exactly what
it says on the tin - the worn overlay for said item will not be added
when the trait is present, so we give it to items hidden by the hood.
I also refactored the `EXAMINE_SKIP` item flag into
`TRAIT_EXAMINE_SKIP`.
## Why It's Good For The Game
stealth thing having an obvious sprite tell is bad. bugfix good.
## Changelog
🆑
fix: Void Cloaks now properly hide blades and such in the suit storage
from the wearer's sprite.
/🆑
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
## About The Pull Request
I've been meaning to do this for some time. I need this for
portable/handheld aquariums/fishtanks to be possible. I'll sprite and
code them before I call this PR ready, however suggestions and code
reviews are welcome in the meantime.
Being a pretty heavy refactor, some things might break (we have more
than a few unit tests so perhaps not) while others, coincidentally,
might be fixed without me knowing. Anyway I'm sure this PR fixes
aquarium beauty, which wasn't really working to begin with because the
code was so fucking bad. Nothing really worth of a CL entry tho.
TODO:
- [x] handheld aquariums, craftable with a kit and little plastic or
buyable from the fun vendor ig.
- [x] an aquarium upgrade for handheld aquariums to bypass possible
restrictions.
- [x] update the beauty element to consider items, which shouldn't
contribute to the area beauty when held or otherwise not on a turf.
## Why It's Good For The Game
This should make handheld aquariums possible.
## Changelog
🆑
refactor: refactored aquariums heavily. Please report any fishy bug.
add: Added portable/handheld fish tanks to the game. They can be crafted
with an aquarium kit and 5 sheets of plastic. While portable, they
cannot store fish that are too big or if there're too many already. This
restriction can be removed by using the new "bluespace fish tank kit"
techweb item.
map: Replaced the lawyer's stationary pet aquarium with a fish tank, so
you can carry McGill around.
balance: Reduced the iron cost of stationary aquariums a little.
/🆑
## About The Pull Request
You can no longer view operating computer UI while lying down as to
prevent patients from peeking at the computer.
## Why It's Good For The Game
Currently its very hard to pull off a surprise brainwashing surgery on
someone as the patient can always peek at the computer to see what
exactly is going on. With this change players will have to trust their
doctors unless they want to be a victim of surgery related shenanigans.
## Changelog
🆑
balance: You can no longer view operating computer UI while lying down
/🆑
## About The Pull Request
So previously I made a pr for fixing the prosopagnosia quirk, but the
code I wrote was far too ass for what was already incredibly hot code.
In the comments, Mothblocks requested using the same bitflag&signal
logic the other screentip modifiers use.
I, of course, said I'd look into it in a few days.
Anyhow, 199 days later, I've made this pr.
Here we introduce a new `mob_flags` var on `/mob`, where we set
`MOB_HAS_SCREENTIPS_NAME_OVERRIDE`.
Then, based on whether this is set, the screentips system sends a signal
to the user mob to request possible name overrides.
We then make the prosopagnosia quirk set this flag and register the
signal, upon which it just sets the name to "Unknown" if it's a human.
This fixes our issues (in a saner way).
## Why It's Good For The Game
Better is prosopagnosia can't be easily obviated by just having
screentips on.
## Changelog
🆑
fix: Prosopagnosia actually accounts for hover screentips, showing
humans as Unknown in those too.
/🆑
nevimer