## About The Pull Request
So, my original goal was just a refactor for the emissive overlays of
eyes, as a way to implement the specular emissive introduced by smartkar
some time ago, but somehow I found myself dragged into a bigger refactor
or cleanup of organ damage, thresholds, failures. One of the main
problem was that there were no procs called when a organ suffered enough
damage to fail or when recovering from failure. It'd just enable or
disable a bitflag, leaving it up to subtypes to decide how to tackle
organ failure their own ways: diverse, funky and sometimes incompatible.
More often than not relying on their very own "update_thingamajig" kinda
procs that run whenever the organ takes damage, rather than just when
the threshold is reached (low, high, failure. There are however a couple
organs with their own quirky thresholds, I let those slide).
There's also a bit of old code, especially for ears, with the
`AdjustEarDamage` and temporary deafness both predating the framework
for organ damage as far as I know. It really needed a coat of fresh
paint.
Oh, there were also more than a handful of organs that still heavily
relied on some ORGAN_TRAIT source instead of the `organ_traits` list and
the two add/remove procs `add_organ_trait` or `remove_organ_trait`. This
include organs that lose or gain specific traits when failing et
viceversa.
~~Lastly, felinids (and the halloween ghost species) having reflective
eyes. It's just a nod to the tapetum lucidum that animals with night
vision often have (including cats), which is why their eyes are a bit
brighter in the dark. Felinids however, do not have night vision (nor do
ghosts). This is merely cosmetic.~~ Cut out for the time being due to
issues with the specular emissive...
## Why It's Good For The Game
Refactoring / cleaning up old organ code.
## Changelog
🆑
refactor: Refactored organ damage code a little. Hopefully there won't
be issues (otherwise report them).
/🆑
## About The Pull Request
Adds action buttons for toggling mech equipment without opening the UI
<img width="971" height="140" alt="butt"
src="https://github.com/user-attachments/assets/be2b38ba-6526-4271-9b54-d946ee6fa7e3"
/>
## Why It's Good For The Game
Quick equipment access
Less UI navigation needed
## Changelog
🆑
qol: Added action buttons for toggling mech equipment
/🆑
## About The Pull Request
Projectile refactor pulled armor check above the pre-hit comsig, this
fixes that. No need to check armor before you're hit when you
potentially will not be.
## Changelog
🆑
fix: Sleeping Carp and Cain & Abel no longer tell you about armor
penetration when you reflect projectiles with them
/🆑
## About The Pull Request
Fixes#93199
EMP protection now specifies what it protects
Adds an EMP flag for things which should definitely not indicate they
are EMP proof
## Changelog
🆑 Melbert
fix: EMP proof objects now specify what they protect rather than only
implying it's 100% emp proof
fix: Some objects meant to stealthily be emp proof no longer broadcast
they are emp proof on examine
/🆑
## About The Pull Request
moves all implementations (im aware of) for "Im a parent type dont spawn
me please" to the datum layer to standardized behavior
adds a standerized proc for filtering out "bad" items that we dont want
spawning. applies to it the subtype vendor, gifts, and a new spawner and
mystery box for a random gun (neither playerfacing)
"port" of https://github.com/shiptest-ss13/Shiptest/pull/4621https://github.com/user-attachments/assets/22f6f0b2-b44e-411a-b3dc-6b97dc0287aa
small warning: I dont have EVERY abstract type defined right now but,
ive done a good enough job for now. Im tired of data entry rn
## Why It's Good For The Game
standardizing behavior. Might be a micro hit to performance however
having this lets us not rely on icon state to determine whether
something is a parent type and makes it much easier to tell something is
a parent type (could be applied further to things like admin spawning
menus and things like that).
need feedback on if this is actually good for the game.
## Changelog
🆑
add: Soda cans show up in the silver slime drink table.
add: Examine tag for items that are not mean to show up ingame.
refactor: Standardizes how gifts rule out abstract types.
fix: gifts no longer check if something has an inhand, massively
expanding the list of potential items.
/🆑
## 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
#92354 missed a few uses of Trigger, so blood drunk was missing the
clicker arg and some mecha actions didn't account for the change.
## Changelog
🆑
fix: Fixed blood drunk miner's dash and some mecha actions not working
/🆑
## About The Pull Request
This PR adds the ability to install a B.O.R.I.S. in a circuit that
contains an MMI component. These circuits can then be remotely connected
to by an AI by clicking on them or anything they are inside of. To
indicate that a circuit allows remote AI connection, an indicator is
given to the circuit and anything containing it.
Additionally:
- Refactors the MMI component to use `item_interaction`, since it was
pertinent.
- You cannot insert an MMI/B.O.R.I.S. into a locked circuit.
- You can no longer hotswap MMIs/B.O.R.I.S.es - you must manually eject
the inserted one.
Let me know what changelog labels I should use for the hotswap removal
and the prevention of insertion into locked circuits.
## Why It's Good For The Game
If you can put an MMI or posibrain in a circuit, why not allow an AI to
use it using a B.O.R.I.S.?
## Changelog
🆑
add: B.O.R.I.S.es can be installed inside of integrated circuits with
MMI components, allowing an AI to remotely interface with them the same
way an MMI or posibrain could.
refactor: The MMI component now uses item interaction behavior for
inserting MMIs/B.O.R.I.S.es.
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
I found out this admin only mech couldn't move because the 0 it had as
step power consumption ended up as infinity somewhere.
I removed it since there's no real reason why it shouldn't use power for
movement.
## Why It's Good For The Game
Mechs have legs for a reason.
## About The Pull Request
Don't let un-detachable or un-toggleable equipment be detached or
toggled.
## Changelog
🆑 Melbert
fix: Fixes some potential exploits in mecha ui code
/🆑
## About The Pull Request
<img width="346" height="190" alt="rhJh93UCUl"
src="https://github.com/user-attachments/assets/376199f1-2083-4c9d-b301-461c23c1c03b"
/>
Tin. Caused by someone passing a hard ref in the source arg of
`ADD_TRAIT`. Also does a quick pass for similar bugs.
## Why It's Good For The Game
Less chug
## Changelog
Nothing player facing enough to put in the CL
## About The Pull Request
Removes the Justice mech from the game, including its sprites and some
of the associated code.
Leaves some sprites, effects and sounds in case anyone wants to reuse
them for something else.
If the maintainers prefer that the mech should remain in the game, but
as an admin-only spawn, I will do so.
## Why It's Good For The Game
This mech has been under fire recently because of it being way too
overtuned, which I think has mainly to do with trying to cram a lot of
unusual things for a mech, such as stealth and melee focus, into the
same package.
Aditionally, I don't really like the flavor at all, being a blatant
reference to another unrelated game. If both the ralsei plush and jevil
mask have been removed, I feel like a similar standard should be applied
here.
Finally, this opens up the posibility for someone else to try a new idea
on some of the concepts present on Justice's current iteration, such as
making a melee-focused mech.
## Changelog
🆑
del: The Justice mech has been removed.
/🆑
## About The Pull Request
Fixes the issue of usr pointing to admins by making Trigger pass down
clicker, as usr is fucky and can be passed down by other unrelated
procs. Fun.
Added the clicker arg to all usages of Trigger as well
Also changes isobserver check in antagonist ui_act code that prevents
observers from clicking UI's instead to check if the ui.user is
owner.current
## Why It's Good For The Game
Fixes admins giving heretic to people opening the heretic UI for the
admin instead
## About The Pull Request
# More robust logging
## Ore silo logs have now been refactored in the UI to display:
- Number of sheets is now the relative unit when displaying a given log.
- Instead of `100 iron` being displayed when removing one sheet, it just
says `1 iron`
- Instead of `25 iron` being displayed when using a quarter sheet, it
just says `0.25 iron`
- All information from ID_DATA(log_user) now sent to tgui backend
- The items rendered to ore silo users are:
- Name on ID, job on ID
- If the ID's bank account (if one is registered) is one of the ore
silo's banned users
- If the user for a given entry was wearing a chameleon card, they will
always appear unbanned
- NOTE: The bank account ID # is (currently) not shown to players using
the ore silo.
- Full log information is rendered within a dropdown; the dropdown
one-liner shows
- Action (deposit, eject, item created)
- Amount (deposit/eject? amount of material used. item created? number
of items created.)
- Either name of material (if deposit/eject) or the name of items
crafted
- The name of the user who performed a given operation (if wearing an
unbanned ID) or ID_READ_FAILURE (if ore silo ID requirement has been
disabled and the person is not wearing an ID)
- As name, but instead, the job of the ID (or ID_READ_FAILURE)
# Access control improvements
## Single-user bans
- Anyone with QM access (not silicons) can now ban/unban a user from a
given log from using the ore silo
- Bans are associated to bank account IDs.
- Wearers of chameleon cards bypass any ban restrictions.
- Anyone with QM access on their worn card bypasses ban restrictions.
- Silicons bypass ban restrictions.
- QM access requirement is removed if the ore silo is emagged.
- Silicons can ban/unban people if the ore silo is emagged.
## Worn ID requirement
- Enabled at roundstart, can be disabled by anyone with QM access (not
silicons)
- If enabled, you must be wearing an ID with a bank account associated
to it to use ore silo materials.
- Wearers of chameleon cards bypass this restriction (so-called ID
requirement free thinkers wearing chameleon ID cards)
- QM access requirement to toggle removed if emagged.
- Silicons can toggle this on/off if the ore silo is emagged.
# Access control radio notifications
## Access control operations reported on the radio
- Any operations for access control are reported on radio channels.
- Currently, the policy is always the default.
- In the future, the ore silo UI will allow the quartermaster to modify
what operations are reported on what channels (petty QM broadcasting ban
reports on Common)
- Current default policy:
- Reported on COMMON channel:
- Anyone but the Captain attempts to ban someone with QM access from the
ore silo (nice try dumbass)
- Ore silo ID requirement toggling
- Reported on COMMAND channel:
- Common channel reports.
- Per-user banning/unbanning.
- Anyone without QM access attempts to ban/unban someone.
- Anyone without QM access attempts to toggle the restriction for ID.
- Silicons attempting to tamper with the ID requirement restriction
- Silicons attempting to tamper with the ban/unbanned user list
- A ban attempt failing because a given log entry had a user with no
bank ID.
- Reported on SECURITY channel:
- Common channel reports.
- Per-user banning/unbanning.
- Anyone without QM access tampering with the silo.
- Reported on SUPPLY channel:
- Command channel reports.
- Reporting to the radio is disabled if the ore silo is emagged.
## Modifications to the remote_materials component
- Strictly encompass the behavior for connecting/disconnecting ore silos
to material receptacles (RCDs, machines, etc) into procs on the
component, instead of handling it all over the place
## Why It's Good For The Game
Gives people with ore silo access more fine grained control over ore
silo use without having to resort to heavy-handed fabricator lockouts
Makes the logging on the ore silo more robust so we can make sure we
kill the right Roboticist for using all the materials
Offers an avenue for sidestepping all of this with a chameleon card or
emag if a given traitor (organic or otherwise) is particularly opposed
to DRM mats.
https://github.com/user-attachments/assets/effd2c63-509c-4d33-992f-837a0d62b935
## Changelog
🆑 Bisar
add: The ore silo has had a significant expansion to its logging
capabilities.
add: The ore silo now allows any ID with Quartermaster access (NOT
SILICONS!) to ban/unban specific users from the silo.
add: The ore silo now has a toggle (on by default) that a user of ore
silo materials has an ID with an associated bank account. This can be
toggled by anyone with Quartermaster access (NOT SILICONS!)
add: NanoTrasen discounts any reports that Syndicate contraband
(cryptographic sequencer, agent card) can be used to circumvent any
protocols instituted on the ore silo access control routines.
add: The ore silo now announces operations to ban/unban users and
enable/disable ID requirements on radio channels (check the Github for
actions reported to what channels.)
add: The tgui interface for ore silo log entries has been reworked.
refactor: The code for logging a given access to ore silo materials has
been significantly refactored.
qol: Ore silo log entries now display materials spent in terms of sheets
rather than the obfuscated absolute-units previously display (1 iron
ejected instead of -100 iron, 0.25 used in a craft instead of -25 iron)
/🆑
## About The Pull Request
New changes for Justice mech - traitor mech that can be created on
emaged fabricator(you need robo skillchip to emag it)
1. Charge attack refactor
Charged attack is now used not by pressing the action button but on
holding right click
While you press right click scope will focus on tile mouse looking for
and when you release right button you will charge on this tile (cooldown
5 seconds as before). if your mouse look at position you unable to
charge your mouse icon will become red
2. New Justice block
Now Justice don't have 60% chance to block any damage. Instead of this
rng, justice has 3 engines that orbit around him
Engines can be active and disabled. While all engines active they will
block any range projictiles back.
To deactivate engine you need to melee hit mech. When all engines
deactivated mech loses its ability to deflect for 10 seconds, after
which all cores are recharged and the cycle continues again.
Justice can also recharge one engine when pilot hits someone who not in
crit.
3.
Some balance changes:
Mech hp now 300
Mech melee armor now 50
Mech bullet and laser armor now 30
Mech now don't have speed change when you switch safety mod.
Instead mech becomes faster in invisibility and slower when holding the
right mouse button to charge a charge attack.
Invisibility mode now no longer temporary. You can be invisible as long
as you want until you attack/ bump with someone/ take damage or turn it
off yourself
AoE attack from invisibility is now x2 faster
## Why It's Good For The Game
Lots of changes from recived feedback.
Basically the most annoying thing was the block chances. Praying on luck
to not die from laser spam turned out to be not a very interesting
mechanic. Now mech justice requires more strategic actions to destroy it
and the mechanics create more fun for both the mech user and those who
fight with it. You need to get close to the mech to hit it and only then
will you be able to shoot the laser and user of justice has the ability
to recharge his cores by attacking enemies (if you don't attack, then
you won't be able to recharge the cores (well, only if your other cores
are broken)). This all creates more risk reward elements and not just
rng.
Accordance with block chance changes i also increased HP and armor of
Justice to balance the block changes a bit.
AoE attack speed was needed simply because 100/100 cases everyone said
that the aoe attack is weak and useless because it is almost very easy
to get away from it.
Changing the charge attack work mechanic is necessary to improve the
maneuverability of the mech. pressing the charge button and then getting
messages that you chose the wrong direction is very inconvenient and
deprives comfortable gameplay and pleasant use of the mech.
## Changelog
🆑
add: Justice mech: New block and charge system! Build and try it now!
qol: Justice mech: charge attack is now much more pleasant and
convenient to use!
balance: Justice mech: Increased HP and armor.
balance: Justice mech: Invisibility is now infinite.
balance: Justice mech: stealth aoe attack is now 2x faster.
refactor: Justice mech: Some code clenup and mechanic improvements.
/🆑
---------
Co-authored-by: tgstation-server-ci[bot] <161980869+tgstation-server-ci[bot]@users.noreply.github.com>
Co-authored-by: tgstation-ci[bot] <179393467+tgstation-ci[bot]@users.noreply.github.com>
Co-authored-by: Time-Green <7501474+Time-Green@users.noreply.github.com>
## About The Pull Request
Firstly, mech beacons are limited to one of each type.
Secondly, mechs, when EMP'd, may potentially delete the beacons
installed in itself. The probability is based on the severity of the
EMP. 20% chance if the EMP is light. 40% chance if the EMP is heavy.
## Why It's Good For The Game
> Type limitations
I don't think stacking 10 tracking beacons on the same mech to instacook
it is intended. The extra beacons do not do anything. It's just to make
it easier to EMP.
> Beacon Deletion
So what if I told you that there is code in control beacons that
suggests they are intended to be deleted when EMP'd, which wouldn't make
sense unless it could be EMP'd in the mech? What if I said this code has
been there for a really long time? What if I told you it never worked?
I'm not going to sit here and pretend like this is a fix. We've played
with this being the case for a really long time. But it is dead code and
I'm gonna implement it because I think it solves a really annoying
problem with beacons, which is that once they're in, you can't get them
out again. I do still think the beacon is a strong strategy, even if it
self deletes. And I do think you'll get your moneys worth if you manage
to stick one in the mech. It's not like they can eject it early. Even
just one EMP is going to fuck up that mech. Especially true if it has
both types of beacons (since its two EMPs).
## Changelog
🆑
balance: Mecha that are EMP'd properly delete their tracking beacons
after many years where they haven't. There is a probability for whether
or not the beacon is destroyed from an EMP.
fix: You cannot stack multiple of the same beacon onto a single mech.
/🆑
## About The Pull Request
closes https://github.com/tgstation/tgstation/issues/90904
if you have strafing on your dir doesn't actually change, making this
do_after abusable
## Changelog
🆑
fix: moving out of range of a target you are clamping while strafing
will halt the do_after of mechs
/🆑
## About The Pull Request
If you use the mech clamp offensively, it actually performs an attack
animation and sound, and properly checks armor and block. It only deals
brute damage.
As a consequence of these changes, it actually logs attacks made against
mobs that die when gibbed.
Also, xenos take x3 damage from the clamp.
## Why It's Good For The Game
This is a pretty sinister kind of attack, as it is completely silent
except for throwing a warning into chat, and can be done even in a large
crowd of people. Someone who isn't aware that the clamp can be used this
way may not even understand what is happening before it is too late.
> block check
While mech melee doesn't normally check block, this is an improvised
attack on a non-combat mech. I think it should stay a bit weak compared
to a proper mech melee in most ways and have some additional
limitations.
> Xenos
I thought this was already a thing. It's thematically on point, no?
## Changelog
🆑
balance: Mech hydraulic clamps perform an attack animation and sound
when attacking mobs.
balance: Mech hydraulic clamps can be blocked and respect armor.
balance: Mech hydraulic clamps do triple damage to xenomorphs.
/🆑
## About The Pull Request
Alleviates #91603
As in it does not fix it because i have not been able to reproduce it.
It now checks for invalid values and defaults to `amount`(which is 1)
during `Initialize()` and not null so we don't have to pass the number
`1` when creating a single sheet.
A stack trace is thrown for <= 0 sheet amounts so we can debug & fix
stuff
## Changelog
🆑
code: stacks error on invalid amounts, removed manual passing of number
`1` when creating a single stack in many cases
/🆑
## About The Pull Request
What it says on the tin.
## Why It's Good For The Game
Mech domination is intended to allow a malfunctioning AI to dominate any
mech, with or without a tracker beacon.
I have no idea whether or not this was an accident (some of the checks
seem to hint as such), or the PR was misleading, but this was introduced
in what was supposedly a chat display improvement PR
https://github.com/tgstation/tgstation/pull/90565. The body of the PR
seems to hint it was probably a deceptive nerf, as they acknowledged
this would happen, even though the code changed would not require these
checks to take place or, more importantly, early return if the AI in
question could dominate mechs. Which is a complete behaviour change
worth acknowledging.
Lets not do that in the future, okay?
## Changelog
🆑
fix: Malfunctioning AI's can once again dominate mechs without a beacon.
/🆑
## About The Pull Request
Attaching goliath plating to mechs now requires and takes up an armor
slot.
Also removed some now-unused values on armor modules
##### This is a comission for Ezel/Improvedname
## Why It's Good For The Game
Currently you can get to melee armor cap on Ripley or Paddy by stacking
an armor booster with goliath armor (20 + 30 + nat 40 = 90) which is a
bit absurd. While its strong enough on ripley, a lot of both antagonist
and crew weapons (most, in fact) are melee and thus become absolutely
useless against an already very oppressive roundstart mech that Paddy
is. This makes goliath plates a better option than an armor booster that
you have to go down to lavaland to while preventing it from being
stacked to reach absurd numbers. Also could possibly lead to allowing
attachment of those to other mechs which I think could be neat.
## Changelog
🆑
balance: Ripley goliath plating now takes up an armor slot on the mech
/🆑
## About The Pull Request
What it says on the tin. Attacks against the mech are handled as
attacks, and anything else is handled as item interactions and return
using those relevant values.
## Why It's Good For The Game
These procs are a bit of a mess and it did in fact hinder my last pr
related to mechs, so this should make things a bit easier for
development upon going forward.
## Changelog
nothing player facing
## About The Pull Request
Paddy slow_pressure_step_in from 2 -> 5
Paddy fast_pressure_step_in from 1.5 -> 3
This makes them decently slower than a human, unless they can tag them
with disabler shots first.
## Why It's Good For The Game
I think It's deeply, deeply unhealthy that we give security a tool at
round start that's faster and more oppressive than a security officer.
Antagonists essentially have to plan their entire round around the fact
that they will be run down the moment they pop their head out.
It's incredibly punishing to antags that try to focus on stealth,
because you generally won't have the tools to combat it, and running is
not an option. If your plan falls through, it's over
It's incredibly punishing to antags that don't have access to an EMP,
because it outpaces you if you fight, and it outpaces you if you flight.
If you get tagged, it's over
It's even punishing to antags that DO have an emp or a mech counter - a
traitor has to dedicate 5% of their TC on buying an EMP implant, a
wizard will have to dedicate 20% of their spell points to disable tech,
a heretic isn't allowed to pick anything but rust
And if you don't want to buy an EMP, well, we made EMPs harder to make a
few years back in #73081
TL;DR this thing's speed makes it too oppressive as a roundstart tool,
forcing all antags to play around it, and it's not very fun. Slowing it
down aims to refocus it from "a tool which is capable of running down
literally every antag, including Dragons and Xenos" to "a tool security
can use to lock down an area, such as during a riot"
(Yes other mechas are faster, but they're not available roundstart and
robotics is useless half the time, so they're considerably less
problematic)
## Changelog
🆑 Melbert
balance: Paddy is 2.5x slower
/🆑
## About The Pull Request
My original plan was to just implement materials into crafting so that
items would inherit the materials of their components, allowing for some
interesting stuff if the material flags of the item allow it. However to
my dismay crafting is a pile of old tech debt, starting from the old
`del_reqs` and `CheckParts` which still contain lines about old janky
bandaids that are no longer in use nor reachable, up to the
`customizable_reagent_holder` component which has some harddel issues
when your custom food is sliced, and items used in food recipes not
being deleted and instead stored inside the result with no purpose as
well as other inconsistencies like stack recipes that transfer materials
having counterparts in the UI that don't do that.
EDIT: Several things have come up while working on this, so I apologise
that it ended up changing over 100+ files. I managed to atomize some of
the changes, but it's a bit tedious.
EDIT: TLDR because I was told this section is too vague and there's too
much going on. This PR:
- Improves the dated crafting code (not the UI).
- replaced `atom/CheckParts` and `crafting_recipe/on_craft_completion`
with `atom/on_craft_completion`.
- Reqs used in food recipes are now deleted by default and not stored
inside the result (they did nothing).
- Renames the customizable_reagent_holder comp and improves it (No
harddels/ref issues).
- Adds a unit test that tries to craft all recipes to see what's wrong
(it skips some of the much more specific reqs for now).
- In the unit test is also the code to make sure materials of the
crafted item and a non-crafted item of the same type are roughly the
same, so far only applied to food.
- Some mild material/food refactoring around the fact that food item
code has been changed to support materials.
## Why It's Good For The Game
Improving the backbone of the crafting system. Also materials and food
code.
## Changelog
🆑
refactor: Refactored crafting backend. Report possible pesky bugs.
balance: the MEAT backpack (from the MEAT cargo pack) may be a smidge
different because of code standardization.
/🆑
## 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
Projectiles that have armour penetration can potentially pass through
the cockpit of a mech, and hit the pilot. The possibility of this
happening is a probability roll equal to the projectiles
``armour_penetration`` - the mechs relevant armor flag. BULLET for
ballistics, LASER for lasers, ENERGY for energy projectiles.
If the projectile can just pass through structures (like x-ray lasers
and Penetrator .50BMG), then the bullet ALWAYS go straight into the
pilot.
## Why It's Good For The Game
Dealing with mechs is dealing with a huge bag of mech integrity
(effectively a second lot of health). While AP can usually help with
armor stacked mechs, they often have relatively lower damage to
counterbalance this upside. This is usually fine for using AP weaponry
against humans, but a little less so for when you're trying to race a
mech to 0.
As an alternative way in which AP can interact with mechs, they now have
the ability to hit straight into the pilot if they overshoot the mechs
armor. The pilot is usually weaker than the mech (usually), and wounding
them is almost always as beneficial as damaging the mech.
If the mech's armor is still able to absorb part of the damage, this
still usually ends up being a positive outcome for the shooter since
they've dealt a relatively higher amount of damage than most projectiles
to the mech itself.
This also gives x-ray lasers, which are usually pretty terrible at
killing mechs except Phazons (specifically because they can shoot into
the wall the phazon is phasing through), a novel approach to tackling
mechs; killing the pilot inside the shell.
## 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
Melee attack chain now has a list passed along with it,
`attack_modifiers`, which you can stick force modifiers to change the
resulting attack
This is basically a soft implementation of damage packets until a more
definitive pr, but one that only applies to item attack chain, and not
unarmed attacks.
This change was done to facilitate a baton refactor - batons no longer
hack together their own attack chain, and are now integrated straight
into the real attack chain. This refactor itself was done because batons
don't send any attack signals, which has been annoying in the past (for
swing combat).
## Changelog
🆑 Melbert
refactor: Batons have been refactored again. Baton stuns now properly
count as an attack, when before it was a nothing. Report any oddities,
particularly in regards to harmbatonning vs normal batonning.
refactor: The method of adjusting item damage mid-attack has been
refactored - some affected items include the Nullblade and knives.
Report any strange happenings with damage numbers.
refactor: A few objects have been moved to the new interaction chain -
records consoles, mawed crucible, alien weeds and space vines, hedges,
restaurant portals, and some mobs - to name a few.
fix: Spears only deal bonus damage against secure lockers, not all
closet types (including crates)
/🆑
## About The Pull Request
PR adds new unique weapons for mechs - thermal cannons. You can only buy
them in cargo in the "armory" category for 5k, which adds cooperation
between cargo and science (maybe even security, since you need their
access to open the crate).
Thermal guns only work better in pairs, allowing them to reload faster.
You can't have 2 of the same thermal guns (not that you could use them
anyway even if you could install the same ones)
Sprites by: https://github.com/sylvia-from-fulp-stationhttps://github.com/user-attachments/assets/d78504b9-90b8-4f8b-b850-fa96dd8ef554
## Why It's Good For The Game
Mechs don't need buffs, but a greater variety of weapons. Thermals will
be a good example of combining both energy weapons and ballistic weapons
(which mechs lack so much, since all we have from ballistics is Hades,
which does not damage at all). It will also be, in my opinion, the first
interesting weapon that not only shoots, but also gives some bonuses
when used correctly.
## Changelog
🆑
add: Added heavy thermal guns for mechs. Works on the principle of
regular hand guns. Can only be purchased in cargo, as they are
experimental.
/🆑
## About The Pull Request
Makes it so that it is impossible to enter a mech if your hands are
full.
## Why It's Good For The Game
This can result in some...very unintended behavior should somehow you
cannot be forced to drop items in your hands.
## Changelog
🆑
fix: You must have both your hands empty before entering a mech. (But
items which replace your hand, like the light later or the hand of god,
won't prevent you from getting in)
/🆑
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
## About The Pull Request
Adds the Ablative Insulation. A type of mech armor.
The armor module protects the mech from energy weapons (such as thermal
pistols), and also protects the wires from EMPs (only the wires, not the
mech itself). However, it makes it weaker against melee and ballistic
weapons.
The Dark Gygax and Mauler both obtain a version of this module as part
of their default loadout that does not have any disadvantages against
melee and ballistic weapons.
## Why It's Good For The Game
This is a complimentary PR to this one.
https://github.com/tgstation/tgstation/pull/90830
Wire scrambling for mechs is an extremely irritable system, but it does
force mech pilots out of the mech to repair some of the effects
attached. or at least to a standstill.
This can often feel a bit like a knowledge check to resolve for some
pilots, since the optimal solutions for this typically involve pulsing
the wires in some way, utilizing assemblies like voice analyzers,
circuits or signalers.
While I would like a more obvious way for pilots to resolve these
problems without having to set up signal networks, I do think it should
come at some expense in other defenses so that it isn't such a catchall
solution compared to the other armor booster modules. There would
otherwise be no reason not to use this armor booster if there was no
downside, since it completely negates a weakness. Therefore, we're
aiming for a slight upside/downside exchange. You get a very good
upside, but you now need to compensate for weaker defenses elsewhere
(such as risking internal damage effects due to lower armor, see this PR
https://github.com/tgstation/tgstation/pull/90844)
We've given nuclear operatives an improved version because their mechs
are A) expensive as shit, and B) meant to be a huge all-in but have
suffered immensely from many years of refactors, rebalances and gear
availability changes that definitely have left them underperforming for
their promised value. I would much rather nuclear operative mechs feel
like they are less beholden to the weaknesses that crew mechs need to
contend with if only because they exist for what might be a fraction of
the time, if they are even spawned at all due to their price.
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and its effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
add: Adds the Exosuit Ablative Insulation armor booster module. Protects
the mech from energy-based attacks and its wires from EMPs (only the
wires, not the mech). However, the armor booster makes the mech weaker
to ballistic and melee weapons.
add: The Dark Gygax and Mauler now come pre-packaged with a special
version that has no weakness to ballistic and melee weapons.
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
## About The Pull Request
https://github.com/tgstation/tgstation/pull/16607 - As far back as this
PR, mech power loss from EMPs was severely dampened. This change was
with the expectation that mechs would be shot with ion rifles, and seems
as though EMP grenades were not factored at all in how they were meant
to interact with mechs.
Additionally, mechs strangely gain armor based on their capacitor value,
and this armor value is what is used to determine the damage inflicted
from EMPs. This is another design decision with ion rifles in mind, and
absolutely no regard to any other type of EMP that the mech may
encounter.
In this PR, I've changed how both EMPs damage cell charge, as well as
how EMPs damage the mech itself.
### Charge Loss
Charge loss from an EMP now utilities the capacitor tier as a multiplier
by which the mech loses charge, based on a fraction of its max charge
rather than a fraction of its current charge. This is then impacted by
severity.
The formula is as follows
``(Max Cell Charge / 2) / (Severity (Heavy = 1, Light = 2) * Capacitor
Tier (1-4)``
Even at maximum capacitor tier, the mech will still lose its entire cell
charge in about 8 Heavy EMPs. That's 8 shots from an ion rifle, or 8 EMP
grenades. Not accounting for already existing power drain.
### Integrity Loss
Mechs suffer from a varied damage roll. The severity of the damage is
affected by how severe the EMP is, and how good the mech's capacitor is.
At extremely poor capacitors, EMPs can quickly total a mech. At higher
capacitors, mechs will still suffer a considerable amount of damage from
EMPs, but it will take a few more hits before it is destroyed.
## Why It's Good For The Game
Mech EMP vulnerability has never really been an effective measure
against mechs. Most people know that mechs are durable against a large
variety of attacks. And if used correctly, can be exceptionally
difficult to bring down.
Their supposed weakness is EMPs. Yet the values used for determining the
consequences of getting EMP'd are usually quite meager. They seemed to
be designed with ion rifles in mind, but that isn't the typical kind of
EMP used most of the time. Usually, you see mechs hit with grenades
instead.
The way it works presently, EMP grenades are quite literally next to
useless. And that kind of sucks.
We have to bite the bullet somewhere. Mechs need something to bring them
back down to the same level as a carbon if their attacker is
sufficiently prepared for it, because they otherwise possess a great
deal of other protections that leave few options open for how to attack
them.
Now, you may ask yourself, PR reader. Doesn't this mean ion rifles will
eat mechs alive?
Yes. We'll have a look at the ion rifle at a later date.
## Changelog
🆑
balance: Mechs are considerably more vulnerable to EMPs than they were
previously.
balance: The tier of capacitor inside a mech will substantially improve
a mech's defenses against EMP damage. Having only tier 1 capacitors will
result in your mech rapidly destroyed from repeat EMPs.
balance: Mechs suffer more power loss from EMPs. It can take upwards of
8 heavy strength EMPs to deplete a mechs cell if it has a tier 4
capacitor. It takes only two if it has a tier 1.
balance: Mechs suffer more integrity loss from EMPs. A durand can
withstand around 8 heavy strength EMPs before being destroyed if it has
a tier 4 capacitor. It won't survive more than two or three if it has a
tier 1.
/🆑
## About The Pull Request
- Address
https://github.com/tgstation/tgstation/pull/90476#discussion_r2051701283.
Makes pill bottle code cleaner
- Datumized some more storage values(monkey guncase toolbox & crafter
toolbox) making their init slightly faster
- Moved all standard storage subtypes(bags, boxes, lockboxes etc) that
is scattered across various files & folders in the codebase into their
respective files under `code/game/objects/item/storage` folder.
This means for e.g. if you want to see all boxes in the game you can
find them in `code/game/objects/item/storage/boxes` folder & don't have
to go looking for hidden subtypes in various module files or folders
where they were hidden away.
Makes looking for stuff & modifying these storages much saner & easier
## Changelog
🆑
code: organized storage subtypes under the same files & folders
/🆑
---------
Co-authored-by: _0Steven <42909981+00-Steven@users.noreply.github.com>
## About The Pull Request
When duct tape repairs mechs, windows or clothing, it properly updates
icons and other effects that normally occur when repaired.
## Why It's Good For The Game
It ends up creating some weird interactions due to directly repairing
the objects integrity.
## Changelog
🆑
fix: Duct tape properly updates the various icons and visuals of mechs,
windows and clothing that it repairs.
/🆑
## About The Pull Request
People can now pet held mothroaches and pugs if they want to, or use
items on them, hopefully without causing many issues. After all, it only
took about a couple dozen lines of code to make...
...Oh, did the 527 files changed or the 850~ lines added/removed perhaps
catch your eye? Made you wonder if I accidentally pushed the wrong
branch? or skewed something up big time? Well, nuh uh. I just happen to
be fed up with the melee attack chain still using stringized params
instead of an array/list. It was frankly revolting to see how I'd have
had to otherwise call `list2params` for what I'm trying to accomplish
here, and make this PR another tessera to the immense stupidity of our
attack chain procs calling `params2list` over and over and over instead
of just using that one call instance from `ClickOn` as an argument. It's
2025, honey, wake up!
I also tried to replace some of those single letter vars/args but there
are just way too many of them.
## Why It's Good For The Game
Improving old code. And I want to be able to pet mobroaches while
holding them too.
## Changelog
🆑
qol: You can now interact with held mobs in more ways beside wearing
them.
/🆑
