## About The Pull Request
Refactors teleporter interference into an item flag, refactors
teleporter interference checks to check your contents for items with
this flag rather than doing a hard check for a bag of holding. Currently
this flag is only used by BOH and SMOH, replicating current (intended)
behavior
Closes#96170
## About The Pull Request
There's a few of these that conflict, mostly relating to timing. This
conflicting won't actually break anything but it does muddy "what is
this doing" somewhat and it's good to be clear so here we go
## Why It's Good For The Game
Makes the MC very slightly harder to confuse yourself with
## About The Pull Request
- Fixes#95651. Catalysts no longer get consumed
- Removed `REACTION_CLEAR_IMPURE` flag as it is now redundant with
`REACTION_CLEAR_INVERSE`
- Removed `REACTION_CLEAR_INSTANT` flag as it was never used
- Other minor nitpicks
## About The Pull Request
There's no lint for these missing so they go largely unnoticed until
someone trying to procrastinate cleaning the house adds them all
manually
## About The Pull Request
If you have a snout (and it isn't already handled elsewhere by your
species), masks will now be pushed 1 whole pixel up and away from you
when facing left or right.
Examples (TOP IS OLD, BOTTOM IS NEW)
(did you know the welding visor has the lizard's snout sticking out the
front)?
<img width="441" height="357" alt="image"
src="https://github.com/user-attachments/assets/5d703afc-2541-4789-956c-f27dc3fdcf31"
/>
I also tried moving it up one tile too, but it didn't look as nice. (To
be clear, these are not the ones being used, the above screenshot is)
(once again top row is old, bottom row is new)
<img width="1443" height="493" alt="image"
src="https://github.com/user-attachments/assets/c7193237-39fb-466b-9dcd-f5db2a646628"
/>
<img width="1138" height="490" alt="image"
src="https://github.com/user-attachments/assets/398154df-3e56-4f59-b350-24a9c9ea04a1"
/>
## Why It's Good For The Game
I think this makes masks fit snouted faces a little bit better?
Currently they sorta clip into the face which is a little bad imo.
## Changelog
🆑
add: Masks now fit snouted species a little bit better, maybe.
/🆑
## About The Pull Request
A weather anomaly can spawn on the station, causing a sandstorm,
snowstorm, or rainstorm to affect the room (and nearby rooms). These
weathers range from "harmless" to "mildly damaging".
They last for around five minutes.
The weather doesn't start immediately, giving people time to neutralize
it before it causes damage.
Neutralizing the anomaly stops the weather.
If they detonate, it just throw objects away from itself.
<img width="407" height="225" alt="image"
src="https://github.com/user-attachments/assets/2de1b797-2b17-442c-9023-11085b4849cf"
/>
<img width="991" height="674" alt="image"
src="https://github.com/user-attachments/assets/afe5a21d-9cf8-4e9d-95ec-adef6fd12a93"
/>
A rarer version of the anomaly can also occur, which brings a lightning
storm, which may damage the station itself.
Also, reactive weather armor. When you are hit, it summons a lightning
strike below nearby assailants.
## Why It's Good For The Game
With the added rain mechanics I wanted to use them, but it's kinda hard
to shoe them into the station because, "why is it raining on a space
station that makes no sense"
However, anomalies are weird, so this fits perfectly
## Changelog
🆑 Melbert
add: Weather anomalies, in four variants: Rain, snow, sand, and the rare
lightning storm.
add: Reactive Weather Armor
/🆑
## 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
/🆑
shayoki