## About The Pull Request
<img width="194" height="63" alt="image"
src="https://github.com/user-attachments/assets/8b81ede5-3ac1-427c-b580-f75a4b05fae5"
/>
Tripwires, for mechs. A very sturdy cable hung over a space 2-5 tiles
wide, that mechs will trip over if they aren't paying attention.
https://github.com/user-attachments/assets/eb77ac44-73ad-43f7-aa48-3008aedc79e0
It also hurts people it falls on in pretty much the same way as a
vending machine. (it's using `fall_and_crush()`)
https://github.com/user-attachments/assets/97fccb33-d479-4170-8601-07a5b32fe740
To humans, the tripwire blocks movement unless you carefully step over
it(walk) or crawl under it. All beings suffer no issue walking across
the tripwire the long way.
The tripwire is created from wiring together two tripwire poles with a
tripwire cable item. The poles are created from iron rods and iron, the
cable is created from just cable. The wiring takes 3 seconds * how far
the posts are to complete, to a maximum of 12 seconds.
They take significantly increased (10x) damage from any sharp object,
and can be cut in a few seconds using wirecutters. They otherwise have a
`max_integrity` of 500, so a powerful demolition tool(like a mech's
fists or a drill) or a sharp object are fairly necessary to take them
down in a combat-reasonable amount of time.
The tripping has four effects - the damage to the being that the mech
fell on, the paralyzing of that being, damage to the mech pilot's head,
and the time it takes for the mech to get back up. All four of these
numbers are based off of the mech's max health divided by 5, or
`damage_value`.
`damage_value` is applied directly as damage to whoever it falls on.
That person is paralyzed for `damage_value` / 10 seconds.
The pilot of the falling mech recieves `damage_value` / 5 to their head,
with a significant wound bonus. Wear a helmet.
The mech itself recieves `damage_value` * 0.15 seconds of immobility(can
still attack, but can't rotate). (`damage_value` / 10 * 1.5)
What these numbers mean on common exosuits:
- odysseus - mob under hit for 24 damage & 2.4 seconds, pilot hit for ~5
damage, immobile for 3.6 seconds
- ripley - mob under hit for 40 damage & 4 seconds, pilot hit for 8
damage, immobile for 6 seconds
- gygax - mob under hit for 50 damage & 5 seconds, pilot hit for 10
damage, immobile for 7.5 seconds
- durand - mob under hit for 80 damage & 8 seconds, pilot hit for 16
damage, immobile for 12 seconds
- marauder - mob under hit for 100 damage & 10 seconds, pilot hit for 20
damage, immobile for 15 seconds
All of these stun times are large enough to where if there were multiple
people with good weapons around, they could most certainly kill you
before you stand back up. So, don't trip.
Finally, obviously, the clarke is immune. Who'd have thunk.
## Why It's Good For The Game
First, let's all thank the ideas guy. The ideas guy for today is
[dubblywumps](https://discord.com/channels/699727870846697493/705679956021215264/1523883105276919969).
Thank you, dubblywumps. Good idea.
So, what's the point of it? It's an effective area denial tool and
fortification specifically effective against mechs. You can set them up
in the hallways in a reasonable length of time, and it'll at the very
least slow a rampaging mech down, as while they're not strong enough to
handle more than a few punches from a mech, they're strong enough to
handle a few. Falling over as a mech is obviously extremely punishing,
so unless they can take a delay to destroy the wire(or a long delay to
destroy the wire at range), or get around it by tearing through
walls(also a delay), they have to abide by your preferred positioning.
No other tool exists that can truly force a delay in a mech's movement
besides actual walls & windows, which delay humans far more
significantly.
It is not remotely practical in a directly offensive sense, with even
the shortest 2-tile barricades taking too long to set up to do so before
you've been clobbered and perforated. It is practical in an indirectly
offensive sense, to force a fight to continue and prevent the worst part
about fighting a mech: when it walks away. This requires forethought or
teamwork, though. It is also practical in a defensive sense, in
combination with normal barricades to block projectiles you could
reasonably hold a mech off for a while or even potentially force a
stalemate using ranged weapons.
They're very, very cheap materials-wise, but the expense in their
creation is in the time to set them up in a good location. Because they
also slow down people, people won't be setting scores of them up in the
middle of the halls. And if they did, wirecutters take them down faster
than they can be put up.
You may be balking about the immobility time applied to the mech. The
numbers mean that in order to destroy the mech while it lays on the
ground, you must deal a flat 33 + armor damage per second for the
duration of the stun. This is an unreasonable task for one person with a
good crew melee weapon, a reasonable task for two, and an easy task for
three. I think that two people being able to beat you to death after you
failed to take heed of the not-at-all-hidden anti-mech weapon is
reasonable. This is also assuming you have no support team or second
mech, which would be perfectly capable of defending you during your
stun.
## Changelog
🆑
add: Added craftable anti-mech tripwires. A mech that foolishly steps on
one will fall down and be immobilized temporarily. Don't let it fall on
you!
/🆑
## About The Pull Request
You don't always have a user here.
<img width="1782" height="1013" alt="firefox_3cAiBstQyQ"
src="https://github.com/user-attachments/assets/64a40f12-1a24-491a-bbfb-cf56b0309340"
/>
_try to figure out what is going on in this runtime_
## Why It's Good For The Game
Fixes an oversight
## Changelog
🆑
fix: fixed an issue that would prevent an emped mech from being able to
melee attack a target
/🆑
## About The Pull Request
Makes more machinery using MAP_SWITCHes so their fancy preview icons
could be displayed in SDMM. MAP_SWITCH takes original icon+icon_state of
machinery as first argument and icon+icon_state (basically a machinery
part because the naming system, like `MAP_SWITCH("computer",
"/obj/machinery/computer/slot_machine")` ) from
icons/obj/fluff/map_previews.dmi
Adds a tool (subsystem) for that need that generates preview icons for
stuff that has overlays. To include them in preview generating you have
to set specific variable to TRUE.
## Why It's Good For The Game
Lets us do this instead of black boring consoles:
(before)
<img width="641" height="575" alt="image"
src="https://github.com/user-attachments/assets/35fc5a19-bc24-4c02-957a-43ddef86e684"
/>
(after)
<img width="641" height="575" alt="image"
src="https://github.com/user-attachments/assets/99310823-747f-4e0a-acf8-60abcc8f2ed1"
/>
## Changelog
🆑
qol: Made machinery with overlays actually be properly displayed in SDMM
editor.
/🆑
## About The Pull Request
Mechs store almost all of their behaviors on base /mecha type, such as
Maradeur's smoke charges and zoom or Phazon's phasing. I've moved all
mech type specific variables and interactions onto their own types,
cleaned up general code and refactored how Durand's shield is handled
(it is now displayed in vis_contents and no longer an object present on
the turf)
## Changelog
🆑
code: Cleaned up generic mech code and moved subtype specific behaviors
to said subtypes
refactor: Refactored how Durand's shield works
/🆑
## About The Pull Request
In similar fashion to what was done with crafting recipes last year,
this year it's time for techweb designs and printed items to be audited.
This is mostly just about consistency, we've a lot of items that can be
printed by protolathes, autolathes, circuit printers and techfab etc.
However they almost all (except most stacks, mainly) have custom
materials that do not match in one way or another with the materials
used by the design, which is what this PR is for.
"But items printed from lathes etc. already get the mats used to make
them." Yes, they do, however that isn't the case for items of the same
type that were spawned in some other way (cargo shuttle, space/maints
loot, mapped, admins), this create a subtle discrepancy. It isn't a huge
deal (in spite of the size of this PR, ton of designs), but given that I
have done something similar with crafting recipes before, I may as well
give it a second arc of some sort and bring things to completion. And
fix a few possible oversights.
TL;DR consistency and stuff
## Why It's Good For The Game
Consistency, unit test checks to make it harder not to be consistent in
the future. Still has a few TODOs like:
- [x] Fixed newly printed, fully charged RCDs costing less than the RCD
cartridges required to fully charge one. EDIT: I had to tweak the newly
added RDD as well because it suffered from the same fundamental issue.
- [x] Fixed plates being made of iron and yet shattering like ceramic
ones. A new subtype for metallic ones has been made.
## Changelog
🆑
refactor: Refactored a few things with techweb designs (the ones for
autolathes, protolathes, circuit printers, mechfabs etc.) to make sure
that the materials of items that can be made from these designs more
closely match the materials used to make them.
fix: Lizard fries no longer need a plate to be made, like all other
treats that used to require plates in a distant past.
balance: Tweaked the materials cost of RCD, RDD and RCD cartridges.
image: Oven trays now have a more metallic hue.
balance: Plates printed printed from lathes won't shatter like ceramic
ones, in virtue of them being made out of iron instead.
/🆑
## About The Pull Request
Reduces mining drill CD from whopping 1.5 seconds to 0.15 seconds when
drilling turfs.
## Why It's Good For The Game
1.5 seconds is absurdly slow for a drill, mechs already have a 5x5 AOE
PKA on them, and mining equipment at this stage has even lower delays
than that.
## Changelog
🆑
balance: Mech drills have a 90% reduction in delay when used to drill
turfs (1.5 seconds -> 0.15 seconds)
/🆑
## About The Pull Request
- Fixes https://github.com/tgstation/tgstation/issues/96553
This refactors the VIM vehicles used for pets and critters into a
functional mech. It also fixes the vehicle missing a sealed air
compartment, which meant they weren't initially spaceproof despite using
spacesuits for their crafting recipe and apart of their sprite.
The VIM mech features:
- No arms and thus cannot be equipped with any weapons
- Room for 1 armor module
- Room for 3 utility modules (jetpack, radio, etc.)
- Cannot be used by silicons, AI, carbon mobs, or large mob types. (only
small-sized simple/basic mobs)
- Can pass underneath mobs and tables since it is tiny
- Can only be crafted via the crafting recipe (cannot be made from
robotics fab or researched)
## Why It's Good For The Game
<img width="1920" height="1080" alt="WIyLe0jcll"
src="https://github.com/user-attachments/assets/b642ba87-d09d-488b-92eb-dc0d3df41122"
/>
The cat NTOS theme is so cute.
## Changelog
🆑
fix: Fix VIM not being spaceproof
refactor: Refactor VIM vehicles into mech
/🆑
<!-- 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
Brought to you by Team Powercrèpe.(same group of people that delivered
the Heretic Overhaul)
This PR ports the TGMC Tacmaps and grants em to our NukeOps.
Code by Me, @Xander3359, @Arturlang, @Absolucy.
Mapping by @RipGrayson
Sprites by @KillerOrcaCora
Writing bits by @necromanceranne
Tacmaps are essentially dynamically generated minimaps,
<img width="1711" height="1335" alt="Tac map examples"
src="https://github.com/user-attachments/assets/f936fac0-fb7c-4b84-970d-7195b4995ca7"
/>
<img width="1274" height="714" alt="Tac-Maps Icons"
src="https://github.com/user-attachments/assets/0f04e388-af4b-4955-be7a-04650cfd746b"
/>
As you can see from the screenshots above, departments are classified by
color, hovering your cursor over an area or a team mate, will display
their name, the system does allow the user to switch between Multi-Z,
and lastly you can draw and add labels to the map, although the last
option is only available to the NukeOps Leader and OW agents.
The functionality is tied to the Syndicate implants nukies start with,
Cayenne, Syndie borgs and Mechs also have the ability to toggle the map.
Likewise, the tacmaps will display the positioning of the following in
real time!
- Nuke ops agents
- Syndie borgs and Mechs
- Cayenne
- Location of the nuclear fission device (and beer nuke)
- Location of the Nuclear Authentication Disk.
<img width="1274" height="714" alt="SkyBridge OFF"
src="https://github.com/user-attachments/assets/3915e7d7-644a-4e9a-b213-997834dde2ea"
/>
<img width="1274" height="714" alt="SkyBridge ON"
src="https://github.com/user-attachments/assets/13748290-fd16-42ba-a9c4-a6b4f7e69c79"
/>
<img width="566" height="459" alt="Holo table done"
src="https://github.com/user-attachments/assets/1a43c5b7-ee51-4794-9c09-16b4fb50e2ad"
/>
https://github.com/user-attachments/assets/caf38538-ef04-4330-992c-3137a67ea0d0
Lastly The tactiical map implant cannot be be used on the nuke ops
base,If the team wishes to interact with the map they'll have to
Interact with the "Reconnaisance Platform" (Sprite by Orcacora) in the
briefing room, which has seen some mapping changes (Brought to you by
TheLastGrayson).
<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->
## Why It's Good For The Game
Originally this feature was planned for the Upcoming Contractor Rework
our team is currently working on, but given the massive size of it all,
we decided to atomize it.
But without that consideration in mind, I think it makes sense for
Nuclear operatives of all antagonists to have the means to Recon and
plot an assault plan onto the station and actually be able to know the
whereabouts of their teammates.
Obviously this feature has a lot of other potential applications, we
have wanted to have functional Maps for a very long time, if someone
wants to give it a go once the feature is merged, by all means.
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and its effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
add: Tactical Maps have been added to the game!
add: Nuclear Operatives implants now grant the ability to open a
Minimap, this map will display and show the names of various areas of
the station, and the positioning of the Nukeops team,borgs,mechs,Cayenne
and the nuke disk in real time!
add: Nukie leaders and OW agents can also draw and apply labels to the
map.
add: the "Recoinassance Platform" has been added to the Nukie Base, it
allows displaying of the Tactical maps while on the Syndicate Base Z
level.
map: The briefing room in the NukeOps base has been remapped to better
accomodate the new Holographic table.
map: Changed the front shutters on the Syndicate Infiltrator to the more
fitting Syndicate Shutters.
/🆑
<!-- 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. -->
---------
Co-authored-by: Xander3359 <66163761+Xander3359@users.noreply.github.com>
Co-authored-by: Artur Lang <24881678+Arturlang@users.noreply.github.com>
Co-authored-by: Lucy <lucy@absolucy.moe>
Co-authored-by: Copilot <copilot@github.com>
Co-authored-by: RipGrayson <49290523+RipGrayson@users.noreply.github.com>
Co-authored-by: necromanceranne <40847847+necromanceranne@users.noreply.github.com>
## About The Pull Request
Refactor the majority of the current gasmix mole change use cases into a
proc called adjust_gas which simply adds the designated mole count of
the species into the gas mix while also handling asserting the gas and
garbage_collect()
I also added adjust_multiple_gases and convert_gas() for modifying
multiple gases and within a gasmix
## Why It's Good For The Game
Lemon wanted this to be done as part of the air group refactor
## Changelog
🆑
refactor: refactored majority of gas_mix mole change into adjust_gas()
proc
/🆑
## About The Pull Request
Removes a lot of cargo cult copypasta with
`default_deconstruction_screwdriver`, `default_deconstruction_crowbar`,
and to a lesser extent `default_pry_open` and
`default_change_direction_wrench`
ALL you gotta do now if you want your machine to have an openable panel
or be deconstructible with a crowbar is this
```dm
/obj/machinery/dish_drive/screwdriver_act(mob/living/user, obj/item/tool)
return default_deconstruction_screwdriver(user, tool)
/obj/machinery/dish_drive/crowbar_act(mob/living/user, obj/item/tool)
return default_deconstruction_crowbar(user, tool)
```
`default_deconstruction_screwdriver` no longer directly sets
`icon_state`, requiring the user pass in the open and closed icon
states. Now, it just calls `update_appearance`, and everything that once
passed the icon state now uses `base_icon_state` and
`update_icon_state`.
## Why It's Good For The Game
Many of these procs were terribly overcomplicated and difficult to work
with for what should be a relatively simple action
Streamlining it makes it easier for coders to understand and work with
## Changelog
🆑 Melbert
refactor: A majority of machines had their screwdriver/crowbar/wrench
interactions rewritten, report any oddities like being unable to open a
machine's panel or deconstruct a machine
/🆑
## About The Pull Request
``/datum/action/proc/Trigger(mob/clicker, trigger_flags)`` has a lot of
children, many of which use mixed ``. = ..()`` or no parent calls at
all.
https://github.com/tgstation/tgstation/blob/d65ee47f6ebd0384d463a1f2a044c321ff2d912f/code/datums/actions/action.dm#L163-L170
This PR attempts to standardize all the children procs to call parent in
a uniform way, or cements that they *shouldnt* call parent for whatever
reason.
## Why It's Good For The Game
Base proc calls are important, yanno?
The base proc has the action button signals and availability proc on it,
so its technically possible for children procs of trigger() to have
check_flags enabled, but never blocked (i.e AB_CHECK_CONSCIOUS,
AB_CHECK_HANDS_BLOCKED).
Some children procs have IsAvailable on them, but its possible they can
be skipped over if a coder is not paying attention. This reduces that
risk.
## About The Pull Request
<img width="444" height="318" alt="image"
src="https://github.com/user-attachments/assets/d2b21460-0b11-499a-b05e-33d3a9768e71"
/>
Walking through snow or sand leaves behind a trail of prints similar to
that of bloody footprints (they use the old sprites, in fact). Like
bloody footprints, you can examine them to get a hint at what left the
prints (shoe type or leg type if barefoot).
When weather comes through (snow storm or sand storm), all prints will
be cleared off. During a raging snow or sand storm, you won't leave
prints at all.
Snowprints can be filled with snow to remove them as well.
Some equipment or effects will stop you from leaving snowprints (ski
shoes, ice shoes*, heretic's cloak of shadows). Also you obviously don't
leave prints if you're flying or crawling or riding something.
**We don't have snow shoes*
## Why It's Good For The Game
Initially I made this as a cute little detail, but I realized it has far
reaching implications for play on Icebox (and many, many sandbox
applications)
On Icebox, any average joe can run into the wastes and become
untraceable, which makes it almost impossible to track down antagonists.
Snowprints... are a method for tracking people who run off into the
snow.
But you can play around it - You can make fake trails and retrace your
steps. You can wait for a snowstorm to clear your tracks. You can even
fill in your tracks with snow if you're patient. Alternatively,
acquiring snow shoes means you leave no trail... or you could learn to
fly, crawl through the snow, use a vehicle, so on.
If you're assigned to assassinate a miner, you can follow their
snowprint trail as they head into the wastes. However, this may only
works early in the round, as the caverns have no snowstorm to clear
prints - as miners come and go, it will become harder to follow trails.
Speaking of miners, they can follow their co-workers trail if they get
injured, or look for prints to see if a ruin has been looted. Similarly
if a crew member falls down to the mining layers, they could find a
miner's trail to follow it back to the station.
And If you're a paramedic and someone was wounded out in the wastes, you
might be able to find their trail to track them down. But you can't
dilly-dally, as the storm will wipe away any chance of that.
Ultimately I think a small detail like this has some big potential for
emergent gameplay which could be cool. My intent is not to affect
antagonists too negatively, so more tools to avoid leaving prints (snow
shoes) could be added.
## Changelog
🆑 Melbert
add: Walking in snow or sand leaves behind prints. You can examine the
turf to see what left the prints, like with bloodprints.
add: Snowstorms or sandstorms clear away any footprints left behind in
the snow or sand.
add: Some equipment or effects, like skis or snowshoes, prevent you from
leaving prints in the snow.
add: You can fill in snowprints with snow.
/🆑
## About The Pull Request
[Adds a visual tick helper, integrates it into SSmove and
such](https://github.com/tgstation/tgstation/commit/e97035f9f74fad5c67c5bf19d8d5d3bb4bd476b4)
Basically, if we do "stuff" during verb time then the next chance
clients have to actually see it is on the next visual tick (rather then
the normal "this tick"). This is cause clients get their next frame
during maptick, and maptick runs before verbs.
We want to be able to handle this properly because if you say, create an
object and then move it on the same VISUAL tick (NOT game tick), it will
just teleport instead of playing out the move. I don't want this for
stuff like sparks, so we need a way to work around it.
[Moves most users of the _FAST flag to
_INSTANT](https://github.com/tgstation/tgstation/commit/6f96daac00519c69adc7554f52114798a65f3ad5)
These are the kids that don't immediately spawn something and the move
it, and we want to allow them to move actually as soon as possible
(important for stuff like space)
[Improves basic effect systems, makes their products delete when they
stop
moving](https://github.com/tgstation/tgstation/commit/172cb25d80ed34e1ec523172a1677fb524239fba)
Moves some stuff out to getters or vars so children can better decide
how long effects should last/how fast they should move. Uses this to
clean up weird dupe code used by explosions.
Makes all these effects delete on contact with something that stops
them. I'm doing this because an effect just hanging in the air looks
really really odd. Does have consequences for sparks that are already
moving at a wall though, might need a better way to handle that.
Makes all these effects use _FAST loops so they don't just hang in the
air for a second on spawn
Adds a setter proc on sparks for their duration, gonna use this to
improve their effects some
[Refactors overlay lights, adds support for animating their
images](https://github.com/tgstation/tgstation/commit/3ad0083cf2b536df51a6d93dca40eac20c1d62d1)
Implements light_render_source and relevant setters, this allows us to
replace the components of an overlay light with basically whatever we
want
Refactors overlay lighting to handle its images more consistently,
allowing us to hook into an image being modified
Combining the two of these will allow us to consistently copy a light's
image, modify it in some way, and then relay that modification back
down. Allowing us to animate it or do more advanced effects painlessly
Also, fixes ranges of 1 or less not rendering at all on initial set
(thank you kapu)
[In which I get fed up and add a macro helper for UID
generation](https://github.com/tgstation/tgstation/commit/aab48b03d407104d4f9cf9acb034494237def911)
[adds vv hooking for all existing lighting
vars](https://github.com/tgstation/tgstation/commit/b81c6200a0d74c36b440aa3f4c1f22c422090a2d)
[Upgrade effect system's dir picking to avoid duplicates when
possible](https://github.com/tgstation/tgstation/commit/18b622586b509c6be4c4bca4e3e7c175ad75fe91)
[Uses the technique described above to animate spark's lights out as
they
move](https://github.com/tgstation/tgstation/commit/67ba177982213799984a70e89536c5efb3d17e14)
This is a decently nice effect imo, it allows us to bump their power
(read, alpha) since it'll get animated away. I try to sync the animation
to the actual icon state's flow (it's 0.7s long). I also sped them up
somewhat to hopefully have a nicer looking effect? we'll see.
[Abstracts away intercepting overlay lights into a holder
datum](https://github.com/tgstation/tgstation/pull/95362/commits/b3f1fe74f2c3bab1d8912ab8a666bd05677ad032)
This should make it far easier to reuse this pattern!
[Fixes overlay lights flashing to double intensity when picked up off
the
ground](https://github.com/tgstation/tgstation/pull/95362/commits/1d83f2031fa2b33312b2aea4359c0c37c9d04ac7)
We needed to clear out their underlays BEFORE the animation
[Adds a flickering effect to flares and their
children](https://github.com/tgstation/tgstation/pull/95362/commits/b7a858e04a607c58b6c7fbe1476ffe2239e63bde)
I'm still not 100% happy with this, I was trying to avoid it feeling
like a heartbeat with random noise and I.. THINK it worked? it's
honestly quite hard to tell
[Adds the same flickering to lighters, welding tools and life
candles](https://github.com/tgstation/tgstation/pull/95362/commits/3ec44027e17835ae96702cec5f0b12d1f4deb32b)
Also, updated light candles to mirror the appearance of normal candles
and use overlay lighting
EDIT:
I realized while working on flares that I accidentally double applied
color, so if you saw the sparks animations before now it was different
(less vibrant). IDK if I like this better or worse but it is RIGHT and
that's what matters.
## Why It's Good For The Game
I got mad about how bad these looked, and this is a start at improving
them.
Also, adds a framework for more dynamic effects applied to overlay
lights (you could use this to apply a sort of "emergency rotating"
effect, or flicker/buzz for example).
<details>
<summary>Before</summary>
https://github.com/user-attachments/assets/66437f27-ee3c-4f14-a7ee-4a1c3e68533ahttps://github.com/user-attachments/assets/ed14fff8-a7eb-47fe-bab5-9a490ac96629
</details>
<details>
<summary>After</summary>
https://github.com/user-attachments/assets/fb24ff2e-c745-42a5-8e11-c8a1eeef35a5https://github.com/user-attachments/assets/fd8c2116-cb92-4fe6-ad3e-786a6538e52a
</details>
## Changelog
🆑
add: Reworks how sparks render. They're now a bit brighter, will fade
out as they move/if they hit something, will stack with each other less
and also won't start hang in the air on spawn.
add: Added a flickering effect to lighters, welding tools, flares,
torches and candles (since they're flames).
fix: Overlay based lights (think flashlights) will no longer flash to
double intensity while being picked up.
refactor: Reworked how some effects (explosion particles, sparks, some
reagent stuff) function, report any bugs!
/🆑
## About The Pull Request
`shock` was copy pasted across a bunch of base types
I needed the behavior unified and it was fairly trivial to do
So now we have `/obj/proc/shock` which all the old implementations call
## Changelog
🆑 Melbert
refactor: Made some minor changes to how things like airlocks, vendors,
and autolathes shock you. Report any wierdness with that
/🆑
## About The Pull Request
Deletes `can_hear`, replaces it with trait-checking deafness.
The only two non-trait sources of deafness (hardcrit and lacking ears)
were refactored into using the trait.
## Why It's Good For The Game
Many places inconsistently check for the deaf trait rather than use
can_hear which meant behavior was not consistent.
Some code would treat "do we lack ears?" as being deaf, some would not.
This unifies all the behavior so being deaf means you're deaf
everywhere.
It also means we can now easily react to gaining and losing deafness via
signal, where before we could not react to it without hooking the trait,
organ remove, AND stat change. Which no one did, of course, because who
would ever think to do that?
## Changelog
🆑 Melbert
refactor: Refactored how deafness is tracked. Please report any weird
interactions with sounds, like messages or sfx being missing.
fix: Lacking ears and being in hard crit now consistently treats you as
"being deaf". This affects a few minor interactions like empath, the
jukebox, and sleeping.
/🆑
## About The Pull Request
This PR refactors ``effect_system``s to be a bit easier to use by
getting rid of ``set_up``, allowing ``attach()`` to be chained into
``start()`` and refactoring most direct system usages in our code to use
helper procs.
``set_up`` was unnecessary and only existed to allow ``New``'s behavior
to be fully overriden, which is not required if we split
sparks/lightning/steam into a new ``/datum/effect_system/basic`` subtype
which houses the effect spreading behavior. This allows us to roll all
logic from ``set_up`` into ``New`` and cut down on code complexity.
Chaining setup as ``system.attach(src).start()`` also helps a bit in
case no helper method exists
I've added ``do_chem_smoke`` and ``do_foam`` helpers, which respectively
allow chemical smoke or foam to be spawned easily without having to
manually create effect datums and reagent holders.
Also turns out we've had some nonfunctional effect systems which either
never set themselves up, or never started, so I fixed those while I was
at it (mostly by moving them to aforementioned helper procs)
## Why It's Good For The Game
Cleaner code, makes it significantly easier for users to work with. Also
most of our effect system usage was copypasta which was passing booleans
as numbers, while perfectly fine helper procs existed in our code.
## Changelog
🆑
refactor: Refactored sparks, foam, smoke, and other miscellaneous effect
systems.
refactor: Vapes now have consistent rigging with cigs using the new
system.
fix: Fixed some effects never working.
/🆑
## About The Pull Request
ID cards/MMI mech access/simple mob access/pAIs now use signals instead
of checking specific slots with mob checks. We do this through mob's
``get_access`` proc that collects all access a mob has with a
collect_access signal.
## Why It's Good For The Game
It looks cleaner and we no longer individually check `check_access` for
every single item that may have access. It's cleaner to put it all
together and check in one go with all the access we've got. This also
makes it easier to add items that hold access that aren't necessarily
IDs but you want to be able to open stuff with.
## Changelog
🆑
refactor: ID checking for access has been reworked, please make a bug
report if anything that's supposed to grant access is not working.
/🆑
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
## About The Pull Request
This was LONG overdue and its finally time. Refactors 2 components to
regular datums
- `/datum/component/material_container` -> `/datum/material_container`
- `/datum/component/remote_materials` -> `/datum/remote_materials`
Reduced memory overhead and stops misuse of component i.e. storing it in
a variable
## Changelog
🆑
refactor: refactored material container code to reduce memory overhead.
Report bugs on github
/🆑
## About The Pull Request
Just a very simple PR to fix an oversight where the Mauler exosuit
doesn't have the AI_COMPATIBLE flag, meaning as well as being unable to
be beaconed - which is intended - you also couldn't use an intellicard
to manually install an AI into it.
## Why It's Good For The Game
If a squad of nukies wants to shove an AI into their Mauler, then why
not? The base Marauder model which the Mauler is based on has AI
compatibility, so does the Seraph! Also brings parity with the Dark
Gygax which currently _can_ have an AI installed.
## Changelog
🆑
fix: Fixed the inability to shove an intellicarded AI into a Mauler-type
exosuit.
/🆑
## About The Pull Request
Mechfabs weren't passing ID_DATA to the silo, preventing material
ejection. Also added ID_DATA to the ORM as to allow miners to be tracked
in the silo (if they insert ores by hand or by dragging a box next to
the ORM)
## Changelog
🆑
fix: Fixed sheet ejection on mechfabs
qol: Miner ORM deposits are now logged in the ore silo
/🆑
## About The Pull Request
A first, small change so that robot customers and mech wreckages produce
robot debris upon being killed/destroyed, rather than simply deleting
themselves. Customers, in specific, will undergo a similar gibbing
process as real borgs: sparking and scattering robot debris without the
animation. Wreckages, instead, will make a large noise, shake the camera
of close people, and collapse into a single robot debris (as it was
already mostly destroyed by this point).
## Why It's Good For The Game
The destruction of these two entities is otherwise underwhelming when
they disappear into the aether with little fanfare. Also provides the
chef and janitor with another thing to get mad about when John Assistant
throws sharp sticks at the kitchen's customers.
## Changelog
🆑
add: Robot customers and mech wreckage destruction are messier. Bring a
mop!
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
(the glass and grille being broken in a single hit is the change here)
- The Paddy and Ripley are the only mechs without enough force to
one-shot windows (they two-shot instead).
Reinforced plasma windows, plastitanium, basically any window except
basic reinforced (and weaker) takes a bit more to kill but not
substantially more.
## Why It's Good For The Game
If walls and reinforced walls can be beaten through in a single hit,
then surely that same mech will have no problems bashing through a glass
window.
## Changelog
🆑
Balance: increases mech damage to windows to feel more realistic
/🆑
## About The Pull Request
Currently mech construction icons correspond 1:1 with construction step
<img width="1357" height="349" alt="image"
src="https://github.com/user-attachments/assets/65763f51-776c-44a7-bc9e-b710db9342a1"
/>
This means if you want to add a new step in the middle of an existing
construction chain you are SOL and have to update everything manually
This suuuucks, and you will notice in the picture above that many states
*are identical*
So I have lightly refactored it:
- When steps are instantiated, it will automatically attempt to fill in
`icon_state`s according to the index in the list, as it does currently
- If the step specifies its own icon state, nothing happens, but index
goes up
- If the step specifies `skip_state`, it will neither set an icon state
nor increment the index
This means you can insert a step in the middle of an existing chain with
`skip_state = TRUE` if your state has no icon associated, OR you can
insert a step with `icon_state = "new_state", skip_state = TRUE` to add
your icon without needing to edit every existing icon
Now in an ideal world we get rid of this auto-setting system wholesale
and set bespoke icon states (`mecha_wires`, `mecha_internal_armor`,
etc). We would just define a step's `state = "wired"`, `state =
"armored"`, and so on. However, I feel like having the option of using
"default states" makes it easier during development.
Also I *could* go through and remove all the duplicate states and
replace them with `skip_state` instructions but I'm lazy. (Maybe I'll do
it anyways though)
Other changes
- Completing a construction step sends you a chat message about the next
step, so you don't have to examine the chassis to find out
- Changed around how the Phazon accepts its anomaly core
## Changelog
🆑 Melbert
refactor: Refactored how mech icons update mid-construction, report any
disappearing mechs please
fix: One of the Phazon's mid construction icons was not visible in the
past, now it is again. Yippee.
/🆑
## About The Pull Request
The AI core structure now fully integrates item/tool interactions and no
longer uses attackby/take_damage overrides. Construction behaviour has
been isolated into its own file.
All handling relating to the AI core's status when shunted has been
turned into signals. For this reason, helper procs for managing core
link state have been made and integrated into the relevant users (APC
shunting, mech takeover). The AI core no longer references the remote AI
mob.
/obj/structure/ai_core/deactivated has been removed from code since it
had no function after refactoring. There was only a single instance of
it being used in a map, which has been replaced with a var edit.
There may be more things I changed, but I'm h
## About The Pull Request
High frequency blades, both null rod variant and admeme variant, can
block mech melee attacks. For the former, that is the only thing it can
block. Great if you're fighting a lot of mechs as a chaplain I guess.
And you're also really committed to the bit.
Weapons that were vibro subtypes are now claymore subtypes. The only
difference here is that they now have 30% block instead of 35% AP.
Null rod high frequency blades are now two-handed. This mostly
determines force changes (10 unwielded, 18 wielded), and mech attack
block chances.
Mech melee attacks respect block...assuming the blocking source can even
block the attack in the first place. Currently, the few sources that can
block/avoid mech attacks are;
- high frequency blades
- energy katanas
- Those staff nullrods (its a holy force field, iunno)
- wizard modsuit shield (and it will eat literally every single charge
it has to do that)
- Sleeping Carp evasion (and only at half the possible chance)
- CQC defense mode (themed as dodging the attack, and also halved)
- probably something I overlooked when I implemented OVERWHELMING_ATTACK
originally and have overlooked here as well.
Just think 'could this help avoid being hit by a road roller being
dropped on you' and go with your gut as to whether or not it is
appropriate if you spot something in the wild that seemingly can block a
mech.
## Why It's Good For The Game
> High Frequency Blade
I wanted to elevate the meme and that is as deep as this goes. Also I
wanted to make this two-handed, much like the true version.
The only thing it is lacking is the cool attack functionality, but I'll
be damned if I can get that to work in a sensible fashion for a crew
weapon...
> Vibro subtype
A lot less of these than I thought. And most of them seemed more
appropriate as claymore types anyway.
> Mech Block
I seeded this previously by making mech clamps respect block. I've now
come back to fully implement it in order to facilitate MGR memes.
For the most part, mechs should still enjoy being largely unblocked by
most sources, even from things like operative suit shields, and
certainly not from actual shields (which I've stripped the ability to
block the attack from entirely) and melee weapons.
The sources that can block them do so poorly. Or, in the case of the
high frequency blade, very well and that's pretty much the only thing it
IS good at blocking.
## Changelog
🆑
balance: High frequency blades (both null rod and admin versions) are
able to block melee attacks from mechs.
balance: High frequency blade null rods are now two-handed weapons.
balance: Mech melee attacks can be blocked or avoided by a few rare
sources.
/🆑
## About The Pull Request
Atomized from #94190
<img width="372" height="406" alt="image"
src="https://github.com/user-attachments/assets/53cd3e28-d2bd-41b3-8c76-44bc16b115f7"
/>
Yes, it updates if you add armor plating.
## Why It's Good For The Game
All the stats are already in the game's code and wiki that anyone can
look up. You can also see what armor plates are there on examine, so why
not show the stats? Makes it way easier for everyone.
## Changelog
🆑
qol: Exosuits have a tag like body armor that shows their armor values
upon inspection
/🆑
Co-authored-by: Fghj240 <fakeemail@notrealemail.com>
## About The Pull Request
It's just a partial cleanup of
anti-[STYLE](https://github.com/tgstation/tgstation/blob/master/.github/guides/STYLE.md)
code from /tg/'s ancient history. I compiled & tested with my helpful
assistant and damage is still working.
<img width="1920" height="1040" alt="image"
src="https://github.com/user-attachments/assets/26dabc17-088f-4008-b299-3ff4c27142c3"
/>
I'll upload the .cs script I used to do it shortly.
## Why It's Good For The Game
Just minor code cleanup.
Script used is located at https://metek.tech/camelTo-Snake.7z
EDIT 11/23/25: Updated the script to use multithreading and sequential
scan so it works a hell of a lot faster
```
/*
//
Copyright 2025 Joshua 'Joan Metekillot' Kidder
This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program. If not, see <https://www.gnu.org/licenses/>.
//
*/
using System.Text.RegularExpressions;
class Program
{
static async Task Main(string[] args)
{
var readFile = new FileStreamOptions
{
Access = FileAccess.Read,
Share = FileShare.ReadWrite,
Options = FileOptions.Asynchronous | FileOptions.SequentialScan
};
FileStreamOptions writeFile = new FileStreamOptions
{
Share = FileShare.ReadWrite,
Access = FileAccess.ReadWrite,
Mode = FileMode.Truncate,
Options = FileOptions.Asynchronous
};
RegexOptions regexOptions = RegexOptions.Multiline | RegexOptions.Compiled;
Dictionary<string, int> changedProcs = new();
string regexPattern = @"(?<=\P{L})([a-z]+)([A-Z]{1,2}[a-z]+)*(Brute|Burn|Fire|Tox|Oxy|Organ|Stamina)(Loss)([A-Z]{1,2}[a-z]+)*";
Regex camelCaseProcRegex = new(regexPattern, regexOptions);
string snakeify(Match matchingRegex)
{
var vals =
matchingRegex.Groups.Cast<Group>().SelectMany(_ => _.Captures).Select(_ => _.Value).ToArray();
var newVal = string.Join("_", vals.Skip(1).ToArray()).ToLower();
string logString = $"{vals[0]} => {newVal}";
if (changedProcs.TryGetValue(logString, out int value))
{
changedProcs[logString] = value + 1;
}
else
{
changedProcs.Add(logString, 1);
}
return newVal;
}
var dmFiles = Directory.EnumerateFiles(".", "*.dm", SearchOption.AllDirectories).ToAsyncEnumerable<string>();
// uses default ParallelOptions
// https://learn.microsoft.com/en-us/dotnet/api/system.threading.tasks.paralleloptions?view=net-10.0#main
await Parallel.ForEachAsync(dmFiles, async (filePath, UnusedCancellationToken) =>
{
var reader = new StreamReader(filePath, readFile);
string oldContent = await reader.ReadToEndAsync();
string newContent = camelCaseProcRegex.Replace(oldContent, new MatchEvaluator((Func<Match, string>)snakeify));
if (oldContent != newContent)
{
var writer = new StreamWriter(filePath, writeFile);
await writer.WriteAsync(newContent);
await writer.DisposeAsync();
}
reader.Dispose();
});
var logToList = changedProcs.Cast<KeyValuePair<string, int>>().ToList();
foreach (var pair in logToList)
{
Console.WriteLine($"{pair.Key}: {pair.Value} locations");
}
}
}
```
## Changelog
🆑 Bisar
code: All (Brute|Burn|Fire|Tox|Oxy|Organ|Stamina)(Loss) procs now use
snake_case, in-line with the STYLE guide. Underscores rule!
/🆑
## About The Pull Request
closes#93805
## Why It's Good For The Game
we actually have almost no emp logging at all lol, not even emp chem
reaction, so you barely can track potential griefer?
## Changelog
🆑
admin: EMP logs are improved, additionally chemical EMP reactions are
now logged.
/🆑
## About The Pull Request
Fixes all instances of numbers being used as assoc list keys in things
that aren't alists, either by turning them into alists or changing the
keys to something else. Also adds new macros to support creating global
alists, as a few global lists became alists. Most of these are pretty
simple and self-explanatory but
- The GLOB.huds one necessitated rewriting because code depended on it
being a non-assoc list, which it technically was because the defines it
used as keys were numbers so BYOND turned it into a regular list, most
of this was for loops through all the subtypes of
`/datum/atom_hud/data/diagnostic` of which there's only one, so I just
changed it to get that type directly by key
- NT Frontier used number indexes which it looped through for some
reason and also passed to TGUI, changed these to strings and adjusted
the TGUI to match, I tested this and it works fine
## Why It's Good For The Game
Makes the code compile, I couldn't test everything but I tried to check
all usages of affected vars to make sure they wouldn't break from being
switched to alists, a TM might be in order just to be sure nothing's
fucked
## Changelog
🆑
refactor: rewrote all cases of numbers being used as keys in non-alist
associative lists
/🆑
## About The Pull Request
When a camera update is triggered, it is instead added to a queue on a
background subsystem
An AI entering a camera chunk which is queued to update will force the
update immediately (bypassing the queue)
While the root problem of this is, ultimately, not addressed...
<img width="554" height="58"
alt="467828777-eff3f0e5-49d6-4997-b4d7-05eff6432155"
src="https://github.com/user-attachments/assets/c2d6a5f5-d958-463e-959f-116bd0dab475"
/>
...the change will ultimately prevent update spam from consuming all of
the server's resources - instead allocating updates to the backburner in
times of high server stress (or on multi-z maps)
## Changelog
🆑 Melbert
refactor: Refactored the way camera updates are handled to hopefully
reduce some lag. Report any oddities
/🆑
## About The Pull Request
Adds equipment action buttons for cargo module and fire extinguisher
YOU can access YOUR mech cargo module without using mech UI screen
simply press left click to unload first item OR right click to select
item to unload(comes in dat radial menu thing)
<img width="300" height="259" alt="riplaey"
src="https://github.com/user-attachments/assets/4469bfb9-ec64-4e71-b774-4b5e8aa964ce"
/>
also works for fatty if ANYONE cares about him
<img width="272" height="234" alt="fatty"
src="https://github.com/user-attachments/assets/ff6cf41a-ab7a-48fa-b490-8ce98448b647"
/>
My baby boy fire extinguisher mech module was untouched by original mech
action buttons PR so i had to do him right
left click to spluff, right click to refill
Also made so fire extinguisher now goes on all mechs because its more
usefull in combat scenario than for firefighting (3x3 slips??? yes
please!!!)
## Why It's Good For The Game
more action buttons bloat on screen less use of clanky UI
## Changelog
🆑
add: Added UI buttons for mech cargo module, left click to dispose first
item in the list and right click to select an item to drop.
add: Added UI button for mech fire extinguisher, left click to splash
and right click to refill.
balance: Mech fire extinguisher module now goes on any mech, combat
slips with a press of a button!
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
Replaces (the only two uses of) "Vey-Medical" with "Deforest
Corporation"
## Why It's Good For The Game
While a funny reference (which apparently dates back 14+ years according
to the blame on the Ody), DeForest has kinda been established as the
leading medical equipment producer, so I think it's more appropriate to
use them instead.
I know we can allow one-off corporations to exist for "worldbuilding
™️", but this is just a joke name. So I don't feel like replacing it
is much of a loss.
If you (the maintainer reading this) think outright removal is too 1984
I can leave the reference in somewhere, that's fine by me
## Changelog
🆑 Melbert
spellcheck: Replaced mentions of "Vey-Medical" with "DeForest
Corporation"
/🆑
## 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.
/🆑
