## About The Pull Request
This PR adds several circuit features, and changes several
assembly-related features to make them a bit more logical in how they
work. Included are the following changes/additions:
- Assemblies and wires have been refactored with vars that describe
their behavior:
- Assemblies have an `assembly_behavior` bitflag instead of a
`attachable` var. This var has 3 flags:
- `ASSEMBLY_INPUT`: The assembly is able to pulse the wire it is
attached to.
- `ASSEMBLY_TOGGLE_ARMED`: On activation, the assembly toggles whether
it can pulse the wire it is attached to.
- `ASSEMBLY_FUNCTIONAL_OUTPUT`: On activation, the assembly does
something other than just toggling whether it's armed.
- Wires have a `wires_behavior` bitflag with 3 flags:
- `WIRES_INPUT`: The object the wires are attached to does something
when the wires are pulsed.
- `WIRES_TOGGLE_ARMED`: The object the wires are attached to can
activate assemblies attached to those wires, and is fine if all that
activating that assembly does is toggle whether it's armed.
- `WIRES_FUNCTIONAL_OUTPUT`: The object the wires are attached to
expects that assemblies attached to its wires do something other than
toggling themselves when activated.
- Buttons can only accept assemblies with `ASSEMBLY_FUNCTIONAL_OUTPUT`.
- Pressure plates can now accept any assembly with
`ASSEMBLY_FUNCTIONAL_OUTPUT`, not just signalers. Assembly shells
attached to pressure plates will draw power from the powernet if the
pressure plate is under a tile.
- Adds a new circuit component - the wire bundle.
- This component gives the circuit a number of wires corresponding to
the size of the shell.
- Each wire has a corresponding port on the component that can pulse,
and receive pulses from, that wire.
- A circuit can only have one wire bundle component.
- Assembly shells cannot be attached to these wires, and no wires will
be created if the component is added to an assembly shell.
- Available with roundstart tech.
- Adds two new shells.
- The wallmounted shell is a large shell that can be hung on walls, and
uses power from the area it's placed in.
- Frame icon:

- Constructed icon:

- The undertile shell is a small shell that only works when fit under a
floor tile, but uses power from the area it's placed in.

- Both shells support usb cables.
- The above shells are available with the Advanced Shells techweb node.
## Why It's Good For The Game
The wire bundle component complements the functionality of the assembly
shell by allowing circuits to use assemblies directly in their logic.
The wallmounted and undertile shells provide ways of placing circuits
that don't necessarily take up space for machines. The undertile shell
is particularly useful for relaying usb component data over wirenets.
Pressure plates being able to accept assemblies other than signalers
expands their uses significantly.
## Changelog
🆑
refactor: Wires and assemblies have been refactored to have
directionality to them. This mostly makes it so that assemblies can only
be attached to wires it would make sense for them to be attached to.
qol: Pressure plates can now also accept igniters, condensers, flashes,
assembly shells, and door controllers.
add: Undertile circuit shells. They only work when placed under floor
tiles, but support USB cables and use APC power instead of cell power.
add: Wallmounted circuit shells. Large shells that support USB cables
and use APC power instead of cell power.
add: Wire bundle component. Adds a number of wires to the circuit
proportional to the capacity of the shell, allowing you to use
assemblies in circuit logic.
/🆑
## About The Pull Request
Adjusts a bunch of machine board names to comply with the general
machine board naming patterns I see.
First pass just removed a bunch of errant (Machine Board)s that were
still on board names despite them being automatically appended on
initialization, second pass set some board designs to actually have
"Board" on the end to specify that it's a board and not a whole machine.
## Why It's Good For The Game
Machine board naming consistency is probably good, actually.
## Changelog
🆑
spellcheck: A handful of machine boards should no longer have two
(Machine Board)s showing up in their name.
spellcheck: Boulder machinery boards are now labeled as boards from
autolathes/circuit imprinters.
/🆑
---------
Co-authored-by: Hatterhat <Hatterhat@users.noreply.github.com>
## About The Pull Request
Assembly shells now use power from whatever machine/borg/mech/modsuit
they are attached to the wires of, instead of their own power cell, when
appropriate.
As for the meat of this PR, circuit wirenet components function like
NTnet and NFC components, but their signals are transmitted across
whatever cable network the shell (or in the case of assembly shells, the
machine or button it's inserted into) is connected to. These components
are available with roundstart tech.
## Why It's Good For The Game
Provides a somewhat intuitive way to make circuit networks that aren't
dependent on external factors to continue functioning.
NTnet components require a functional NTnet relay, which usually means
they need telecomms to be working. NFC components have a range limit,
and you need to provide a specific reference to the circuit being
communicated with. Wirenet components, on the other hand, just need the
shell to be anchored (or for assembly circuits, the thing whose wire it
is attached to), and for the shell to have a cable under it.
Also might indirectly provide a reason to use cable layers other than
the default one.
## Changelog
🆑
add: Adds circuit wirenet components, allowing data to be transmitted
and received over cable networks.
qol: When attached to a machine, mech, modsuit, or borg, assembly
circuit shells will use power from those instead of the circuit's own
cell.
/🆑
## About The Pull Request
Was just scrolling through the Paradise github since they seem to have
more work done for 516 to see if there's anything I can port over, found
this and thought why not.
Ports parts of https://github.com/ParadiseSS13/Paradise/pull/25105
Specifically, updaing all hrefs to use the internal ``byond://``, and
adding it to grep.
## Why It's Good For The Game
More work towards 516.
## Changelog
Nothing player-facing.
## About The Pull Request

This PR just adds in modulo to the circuit arithmetic component.
## Why It's Good For The Game
You _can_ calculate it yourself, but then it ends up extremely unoptimal
and you're usually better off not doing it. It also ends up really hard
to read.
I want to see more clever circuits and computing things.
## Changelog
🆑
add: Added in the modulo operator to the circuit arithmetic component.
/🆑
## About The Pull Request
This allows you to use a fishing rod during the "manipulate organs" step
of the aforementioned surgery to snatch organs from a target.
Unlike other fish sources, this one has a negative fishing difficulty of
-20, which when summed with the default minigame difficulty should still
result in a negative difficulty. In layman terms, this means the
minigame is skipped here (unless you're wearing some clunky stuff like
insulated or boxing gloves). It also has a wait time of 8 to 13 seconds
versus the more random standard 3 to 25 seconds.
A small side-effect of this is that explosions during the "manipulate
organs" step will basically disembowel you, but it kinda fits anyway.
By the by, because of this, there is a tiny chance bluespace fishing
rods can yield you random organs. Worry not, they're newly generated, so
you won't be snatching it from another player by accident (at least for
now).
## Why It's Good For The Game
It adds more possible weird and rare shenanigans involving surgery.
## Changelog
🆑
Add: You can use a fishing rod to snatch organs during organ
manipulation surgery
/🆑
## About The Pull Request
Fixes issues with var typing and proc arguments, discovered using
OpenDream's WIP TypeMaker feature (using improvements I haven't PR'd
upstream yet).
## Why It's Good For The Game
Codebase maintenance.
## About The Pull Request
This PR kills the abstract internal and external typepaths for organs,
now replaced by an EXTERNAL_ORGAN flag to distinguish the two kinds.
This PR also fixes fox ears (from #87162, no tail is added) and
mushpeople's caps (they should be red, the screenshot is a tad
outdated).
And yes, you can now use a hair dye spray to recolor body parts like
most tails, podpeople hair, mushpeople caps and cat ears. The process
can be reversed by using the spray again.
## Why It's Good For The Game
Time-Green put some effort during the last few months to untie functions
and mechanics from external/internal organ pathing. Now, all that this
pathing is good for are a few typechecks, easily replaceable with
bitflags.
Also podpeople and mushpeople need a way to recolor their "hair". This
kind of applies to fish tails from the fish infusion, which colors can't
be selected right now. The rest is just there if you ever want to
recolor your lizard tail for some reason.
Proof of testing btw (screenshot taken before mushpeople cap fix, right
side has dyed body parts, moth can't be dyed, they're already fabolous):

## Changelog
🆑
code: Removed internal/external pathing from organs in favor of a bit
flag. Hopefully this shouldn't break anything about organs.
fix: Fixed invisible fox ears.
fix: Fixed mushpeople caps not being colored red by default.
add: You can now dye most tails, podpeople hair, mushpeople caps etc.
with a hair dye spray.
/🆑
## About The Pull Request
Closes#86968Closes#86969
## Changelog
🆑
fix: Fixed BCIs sending messages twice and circuit laser pointers
sometimes failing to work
/🆑
## About The Pull Request
<details>
- renamed ai folder to announcer
-- announcer --
- moved vox_fem to announcer
- moved approachingTG to announcer
- separated the ambience folder into ambience and instrumental
-- ambience --
- created holy folder moved all related sounds there
- created engineering folder and moved all related sounds there
- created security folder and moved ambidet there
- created general folder and moved ambigen there
- created icemoon folder and moved all icebox-related ambience there
- created medical folder and moved all medbay-related ambi there
- created ruin folder and moves all ruins ambi there
- created beach folder and moved seag and shore there
- created lavaland folder and moved related ambi there
- created aurora_caelus folder and placed its ambi there
- created misc folder and moved the rest of the files that don't have a
specific category into it
-- instrumental --
- moved traitor folder here
- created lobby_music folder and placed our songs there (title0 not used
anywhere? - server-side modification?)
-- items --
- moved secdeath to hailer
- moved surgery to handling
-- effects --
- moved chemistry into effects
- moved hallucinations into effects
- moved health into effects
- moved magic into effects
-- vehicles --
- moved mecha into vehicles
created mobs folder
-- mobs --
- moved creatures folder into mobs
- moved voice into mobs
renamed creatures to non-humanoids
renamed voice to humanoids
-- non-humanoids--
created cyborg folder
created hiss folder
moved harmalarm.ogg to cyborg
-- humanoids --
-- misc --
moved ghostwhisper to misc
moved insane_low_laugh to misc
I give up trying to document this.
</details>
- [X] ambience
- [x] announcer
- [x] effects
- [X] instrumental
- [x] items
- [x] machines
- [x] misc
- [X] mobs
- [X] runtime
- [X] vehicles
- [ ] attributions
## Why It's Good For The Game
This folder is so disorganized that it's vomit inducing, will make it
easier to find and add new sounds, providng a minor structure to the
sound folder.
## Changelog
🆑 grungussuss
refactor: the sound folder in the source code has been reorganized,
please report any oddities with sounds playing or not playing
server: lobby music has been repathed to sound/music/lobby_music
/🆑
Fixes#86784
## About The Pull Request
Although some of the issues found were a direct result from #86692
(c698196766), there was still 40% of
length-related issues that wouldn't be covered anyways that are fixed in
this PR. I.E.:
* Name inputs without `MAX_NAME_LEN`
* Desc inputs without `MAX_DESC_LEN`
* Plaque inputs without `MAX_PLAQUE_LEN`
* Some people just screwed up the arguments so it would prefill
something like "40" in the `default` var because they didn't name their
vars.
To help me audit I added a lot of `max_length` named arguments to help
people understand it better. I think it might be kinder to have a
wrapper that handles adding `MAX_MESSAGE_LEN` in a lot of these cases
but I think there is some reason for a coder to be cognitive about input
texts? Let me know what you think. I didn't update anything
admin-related from what I can recall, let me know if anything needs to
be unlimited again.
## Why It's Good For The Game
The change to `INFINITY` notwithstanding, there were still an abundance
of issues that we needed to check up on. A lot of these are filtered on
down the line but it is clear that there needs to be something to catch
these issues. Maybe we could lint to make `max_length` a mandatory
argument? I don't know if that's necessary at all but I think that the
limit should be set by the invoker due to the wide arrangement of cases
that this proc could be used in.
This could all be a big nothingburger if the aforementioned PR is
reverted but a big chunk of cases fixed in this PR need to be fixed
regardless of that since people could put in 1024 character names for
stuff like guardians (or more now with the change). Consider this
"revert agnostic".
## Changelog
🆑
fix: A lot of instances where you could fill in 1024-character names
(normal limit is 42) have been patched out, along with too-long plaque
names, too-long descriptions, and more.
/🆑
## About The Pull Request
The direction component outputs the direction of an entity if it's
within 7 tiles of the circuit. Since it already checks the distance, I
added distance as one of its outputs.
Besides that, I did a pass over the generics and shells and resized many
of them. Most I resized to be small or tiny, except for the airlock
shell, which I set to be bulky because it's a whole ass door. The shells
I didn't touch remain at 'normal' size.
1) All handheld shells set to small, compact remote set to tiny
2) all components and the generic of the circuit set to tiny
3) drone shell set to small
4) airlock shell set to bulky
## Why It's Good For The Game
Returning the distance spares any would be circuiteers from having to do
a labyrinthine set of calculations to determine distance themselves.
Making most circuits more portable makes them more attractive for people
to tote around.
## Changelog
🆑 Bisar
qol: The 'direction' circuit component now also returns the distance of
its target.
balance: Most circuit shells and the generic component and generic
circuit have had their size reduced.
balance: The airlock circuit shell has had its size increased.
/🆑
---------
Co-authored-by: Metekillot <ubuntu@ip-172-26-7-23.us-east-2.compute.internal>
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
The binary conversion circuit component is totally busted at the moment,
so I redid the logic and now it actually outputs a series of bits to
represent whatever number you feed it. Additionally, it supports
representing a negative number by setting the leftmost bit of your bit
array to 1.
## Why It's Good For The Game
Fixes a broken circuit component and makes it able to represent negative
numbers
## Changelog
🆑 Bisar
fix: The binary conversion circuit component should work again.
code: The component also now supports representing negative numbers.
/🆑
---------
Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com>
## About The Pull Request
https://github.com/user-attachments/assets/b756bc49-70f0-4c86-8b04-5f0566d606a2
I've made the sound really quiet (quieter than most other sounds in the
game) so it shouldn't be too annoying, there is 7 variants of the clicks
so ear fatigue shouldn't strike too bad.
## Why It's Good For The Game
Clicky sounds release a dopamine surge for players and gives you audio
feedback when you're doing something, it also triggers when someone is
else working at a computer which tells you that they're using it.
## Changelog
🆑 grungussuss
sound: computers now make clicky clacky sounds
/🆑
## About The Pull Request
Removes mutant bodyparts and external organs from the game completely
Digitgrade behaviour was mutant bodypart for no reason
Cat ears now work with the bodyparts overlay system, same as all the
other external organs (since all their behaviour is now just on /organ
It doesn't remove all the /external types, but moves all behaviour to
/organ. I'll follow up with a PR wiping all the /external organ types,
but it's just conflict heaven so not this PR
I've also streamlined a lot of duplicate/weird species regeneration code
Melbert did the same PR as well but due to a lack of time (?) I have
absorbed his PR to double nuke mutant bodyparts
## Why It's Good For The Game
Frees us from the chain of unmodular code, and kills my greatest nemesis
(after the shuttle meteor murder bug)
## Changelog
🆑 Time-Green and MrMelbert
Refactor: External organ behaviour has been moved to /organ, ears now
use the same system as the other organs
Refactor: Mutant bodyparts are dead! This likely does not mean much to
the average person but it's very dear to me
code: Improves digitgrade handling in preference code
/🆑
I have absorbed #85126, using Melberts code to improve and add some
missing changes. Mainly improving the functioning of preferences and
digitgrade legs. I didn't take over the hairstyle improvements.
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
Currently to check for Silicon access, we do:
``if is silicon or is admin ghost or has unlimited silicon privileges or
has machine remote in hand``
What has unlimited silicon privileges? Bots, Drones, and admin ghosts.
To check for AI access, it just checks for AI instead of silicon, and
doesnt check for unlimited silicon privileges.
This was kinda silly, so I thought I should make this a little easier to
understand.
Now all silicon/ai traits come from ``AI_ACCESS_TRAIT`` or
``SILICON_ACCESS_TRAIT``. I made a single exception to keep Admin ghost,
since now instead of being a var on the client, we moved it to using the
same trait but giving it to the client instead, but since we have to
keep parity with previous functionality (admins can spawn in and not
have this on, it only works while as a ghost), I kept previous checks as
well.
No more type checks, removes a silly var on the mob level and another on
the client.
Now while I was doing this, I found a lot of tgui's ``ui_act`` still
uses ``usr`` and the wrong args, so I fixed those wherever I saw them,
and used a mass replace for the args.
Other changes:
- machinery's ``ui_act`` from
https://github.com/tgstation/tgstation/pull/81250 had ``isAI`` replaced
with ``HAS_AI_ACCESS``, this has been reverted. Machine wands and admin
ghosts no longer get kicked off things not on cameras. This was my
fault, I overlooked this when adding Human AI.
- Human AI's wand gives AI control as long as it's in your hand, you can
swap to your offhand. I hope this doesn't end up going horribly,
otherwise I'll revert this part. It should let human AIs not have their
UI closed on them when swapping to eat food or use their door wand or
whatnot.
- Bots previously had special checks to scan reagents and be
unobservant, I replaced this with giving them the trait. I also fixed an
instance of unobservant not being used, so now statues don't affect the
basic creature, whatever that is.
## Why It's Good For The Game
This is an easier to understand way of handling silicon access and makes
these mobs more consistent between eachother.
Other than what I've mentioned above, this should have no impact on
gameplay itself.
## Changelog
🆑
fix: Statues don't count as eyes to creatures.
fix: Human AIs and Admin ghosts no longer get kicked off of machines
that aren't on cameranets.
/🆑
## About The Pull Request
The cooldown length for pathfinding to a position with circuits is
reduced from 30 seconds to 5 seconds, the same time when pathfinding to
a previously located position.
## Why It's Good For The Game
This allows the moving drone and other circuit related operations to be
able to track moving targets, as the 30 second cooldown would render the
component practically pointless.
https://github.com/user-attachments/assets/cba8742c-7e98-411e-931d-4d74f51f6be0
## Changelog
🆑
balance: Reduced pathfinding circuit component cooldown from 30 seconds
to 5 seconds
/🆑
## About The Pull Request
Title. They've been missing quick component addition functionality due
to an oversight and were rather annoying to use.
## Why It's Good For The Game
Simple QOL, you no longer need to add every piece manually and can
develop circuits as actually intended (fully from their UI, as you can
do with primary circuits themselves)
## Changelog
🆑
qol: Integrated circuit modules now can be linked to component printers
/🆑
## About The Pull Request
As the title says
## Why It's Good For The Game
Shouldn't be able to activate these whilst unconscious, or stall
activation to activate at a convenient time whilst unconsious.
## Changelog
🆑
fix: Fixed activating specific BCI actions whilst unconsious
/🆑
---------
Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com>
## About The Pull Request
Added support for remote material insertion type whitelists and utilized
it to allow circuit printers to recycle components. Removing a component
from UI while the circuit has a linked printer will automatically
recycle it.
Also fixed a rogue space appearing when recycling a single item
## Why It's Good For The Game
You literally cannot do anything with components you remove/do not need
anymore so usually they end up littering circuit lab's floors. This
should make developing circuits slightly less annoying.
## Changelog
🆑
qol: Circuit components can now be recycles in circuit printers, and
automatically do so upon being removed if a circuit has a linked printer
spellcheck: Recycling a single item no longer outputs a line with a
rogue space infront of it
/🆑
<!-- 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
Makes circuit health analyzer/scanner components check distance to
target turf instead of target itself similarly to (most) other
components. (There are exceptions, presumably due to balancing?
concerns, but this feels like it should not have been one)
This doesn't feel intentional so I marked it as a fix, given that BCIs
stopping being able to scan their occupant is rather nonsensical
## Why It's Good For The Game
Currently BCIs with health analyzer components stop working if the owner
goes into a locker which is pretty stupid. Most components also only
check for turf distance, and while this could theoretically be used to
pinpoint someone's hiding spot there are far better ways to do so with
circuits
## 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. -->
🆑
fix: Circuit health analyzer/state components now work on targets inside
lockers
/🆑
<!-- 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
Using a multitool inhand tells you where the area APC is
## Why It's Good For The Game
Sometimes it's a bit of a pain to find it. No need to keep it sikret
when map knowledge is a thing.
## Changelog
🆑
qol: Using a multitool inhand tells you where the area APC is
/🆑
## About The Pull Request
They deathgasped once on the carbon level and once on the living level
I also realized this check I added a while back breaks lag check
mechanism so let's just change that around
## Changelog
🆑 Melbert
fix: Lizards and Moths don't deathgasp twice when they die
/🆑
## About The Pull Request
Improved code quality of both so they resemble each other. Some of the
new specs are as follows
1. Moved` COMSIG_CLICK_ALT` & `COMSIG_CLICK_ALT_SECONDARY` up i.e.
before `can_perform_action()` making them pure hooks not bound by any
action checks giving components full control over them
2. Removed range check(`CAN_I_SEE`) & view check(`is_blind()`) out of
the base alt click proc. They now only apply to living mobs and don't
apply to ghosts(ghosts don't get blind & see everything) & revenants
(the range check still applies for revenants though).
This was actually a bug because these 2 checks were only meant to see if
the loot panel could be opened (as stated in
https://github.com/tgstation/tgstation/pull/83736#discussion_r1628097941)
but because they are at the top of the proc they also apply to all alt
click actions which is not intended. Also, by moving these checks down
to mob subtype levels some of the snowflake checks like this
7579e0e173/code/_onclick/click_alt.dm (L23)
can be removed. We should not check for subtypes within the parent type
proc but instead have subtypes override their parent procs to implement
custom behaviour
3. Removed redundant signals like` COMSIG_XENO_SLIME_CLICK_ALT` in
favour of just `COMSIG_MOB_ALTCLICKON`
4. While looking for alt click signal overrides I found alt click for
style meter was run timing, that's fixed now
## Changelog
🆑
fix: alt click runtime no more when using style meter
code: improved alt & ctrl click code
/🆑
## About The Pull Request
As the title says. A standard power cell now only stores 10 KJ and
drains power similar to how it did before the refactor to all power
appliances.
The new standard megacell stock part stores 1 MJ (what cells store right
now). APCs and SMESs have had their power cells replaced with these
megacell stock parts instead. Megacells can only be used in APCs and
SMESs. It shouldn't be possible to use megacells in any typical
appliance.
This shouldn't change anything about how much 'use' you can get out of a
power cell in regular practice. Most should operate the same and you
should still get the same amount of shots out of a laser gun, and we can
look at expanding what can be switched over to megacells, e.g. if we
want mechs to require significantly more power than a typical appliance.
Thanks to Meyhazah for the megacell icon sprites.
## Why It's Good For The Game
Power cell consumption is way too high ever since the power appliance
refactor that converted most things to be in joules. It's a bit
ridiculous for most of our machinery to drain the station's power supply
this early on.
The reason it's like this is because regular appliances (laser guns,
borgs, lights) all have a cell type that is identical to the APC/SMES
cell type. And it means that if we want to provide an easy way to charge
these appliances without making it easy to charge APCs/SMESs through a
power bug exploit, we need to introduce a new cell type to differentiate
between what supplies power and regular appliances that use power. This
is primarily what the megacell stock part does.
This moves us back to what it was originally like before the power
refactor, where recharging power cells wouldn't drain an exorbitant
amount of energy. However, it maintains the goal of the original
refactor which was to prevent people from cheesing power generation to
produce an infinite amount of power, as the power that APCs and SMESs
operate at is drastically different from the power that a regular
appliance uses.
## Changelog
🆑 Watermelon, Mayhazah
balance: Drastically reduces the power consumption and max charge of
power cells
balance: Added a new stock part called the battery, used primarily in
the construction of APCs and SMESs.
add: Suiciding with a cell/battery will shock you and potentially dust
you/shock the people around you if the charge is great enough.
/🆑
---------
Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com>
Co-authored-by: Pickle-Coding <58013024+Pickle-Coding@users.noreply.github.com>
## About The Pull Request
I was looking at sounds (as you do) and I noticed this

These sounds don't exist
We have `portal_open_1`, not `portal_open1`.
This wasn't caught on compile because they used `""` and not `''`.
So I went through and audited a bunch of playsound uses that don't use
`''`. Only one error, fortunately
Likewise there was a ton of places running `get_sfx` pointlessly
(because `playsound` does it for you) so I clened that up.
However while auditing the portal stuff I noticed a few oddities, so I
cleaned it up a bit.
Also also I added the portal sounds to the wormholes event and gave it a
free ™️ optimization because it was an in-world loop
## Changelog
🆑 Melbert
sound: Portals made by portal guns now make sounds as expected
sound: Wormholes from the wormhole event now make sounds when formed
/🆑
## About The Pull Request
- Afterattack is a very simple proc now: All it does is this, and all
it's used for is for having a convenient place to put effects an item
does after a successful attack (IE, the attack was not blocked)

- An overwhelming majority of afterattack implementations have been
moved to `interact_with_atom` or the new `ranged_interact_with_atom`
I have manually tested many of the refactored procs but there was 200+
so it's kinda hard
## Why It's Good For The Game
Afterattack is one of the worst parts of the attack chain, as it
simultaneously serves as a way of doing random interactions NOT AT ALL
related to attacks (despite the name) while ALSO serving as the defacto
way to do a ranged interaction with an item
This means careless coders (most of them) may throw stuff in afterattack
without realizing how wide reaching it is, which causes bugs. By making
two well defined, separate procs for handing adjacent vs ranged
interactions, it becomes WAY WAY WAY more easy to develop for.
If you want to do something when you click on something else and you're
adjacent, use `interact_with_atom`
If you want to do something when you click on something else and you're
not adjacent, use 'ranged_interact_with_atom`
This does result in some instances of boilerplate as shown here:

But I think it's acceptable, feel free to oppose if you don't I'm sure
we can think of another solution
~~Additionally it makes it easier to implement swing combat. That's a
bonus I guess~~
## Changelog
🆑 Melbert
refactor: Over 200 item interactions have been refactored to use a
newer, easier-to-use system. Report any oddities with using items on
other objects you may see (such as surgery, reagent containers like cups
and spray bottles, or construction devices), especially using something
at range (such as guns or chisels)
refactor: Item-On-Modsuit interactions have changed slightly. While on
combat mode, you will attempt to "use" the item on the suit instead of
inserting it into the suit's storage. This means being on combat mode
while the suit's panel is open will block you from inserting items
entirely via click (but other methods such as hotkey, clicking on the
storage boxes, and mousedrop will still work).
refactor: The detective's scanner will now be inserted into storage
items if clicked normally, and will scan the storage item if on combat
mode
/🆑
## About The Pull Request
This PR introduces a limited set of camera components that can be used
by surveillance security consoles and the PDA/laptop camera app.
<img width="366" alt="components"
src="https://github.com/tgstation/tgstation/assets/80724828/0e628863-9998-46d6-8822-e0a44543b4c2">
There is four camera components, each limited to a specified shell
circuit type.
Additionally, drone circuit shells can now use the recharge stations
too, much like how mobs with BCIs can recharge.
### New Components
<img width="136" alt="drone camera"
src="https://github.com/tgstation/tgstation/assets/80724828/fd045871-56bf-44a6-bb4f-ebe895d56d3d">
* Drone Camera
This camera component captures the surrounding area. It has an option to
set the camera range (near 5x5/far 14x14).
<img width="136" alt="bci camera"
src="https://github.com/tgstation/tgstation/assets/80724828/16bf2dd1-823b-4d66-8249-5d0f1bb1b779">
* BCI Camera
This camera component uses the active user's eyes as a camera function.
If the user's sights are damaged, the range will be forced to the near
setting. If the user is unconscious/dead/blinded or has no eyes, the
stream will be cut off.
It has an option to set the camera range (near 5x5/far 14x14).
<img width="136" alt="polaroid camera"
src="https://github.com/tgstation/tgstation/assets/80724828/7c4d53df-b4af-4f7c-8942-a63842510720">
* Polaroid Camera Add-On
This camera component streams to a camera network. The camera range is
hardcoded to the near setting (5x5).
<img width="136" alt="airlock camera"
src="https://github.com/tgstation/tgstation/assets/80724828/5d9e9d55-49fc-45a7-99c8-aaf1ae08f6d1">
* Airlock Camera
This camera component streams to a camera network. The camera range is
hardcoded to the near setting (5x5).
### Features
* The cameras can be EMP'd and will be disabled for 90 seconds if
successful
* When the cameras are active, they will actively drain the cell's power
per second (near range uses 3kJ & far range uses 8kJ)
* Advance camera console/AIs can use these cameras, however the camera
light is disabled (they will be useless in dark areas)
### Screenshots In Action
<details>
This is the drone camera viewed on a security camera console<br>
<img width="425" alt="near"
src="https://github.com/tgstation/tgstation/assets/80724828/e5247828-0fee-4552-9e70-5e5ee897c117"><br>
This is the same drone, now set to the far range setting<br>
<img width="425" alt="far"
src="https://github.com/tgstation/tgstation/assets/80724828/e58e3e85-aa90-4f1a-9dff-957c65764b77"><br>
</details>
## Why It's Good For The Game
This promotes emergent gameplay and improves the overall usefulness for
drones as they can be 100% used remotely.
## Changelog
🆑
add: Added new circuit camera components
qol: Circuit drones can now recharge at recharge stations
/🆑
---------
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
## About The Pull Request
Patches up some things that were lacking post #82905
- Some missing (un)seal messages
- a missed direct use of the mod_parts list
EDIT: Also fixes the modsuit painter, and makes sure modsuits can still
be set to use custom dmi files via
`MOD_ICON_OVERRIDE`/`MOD_WORN_ICON_OVERRIDE`
Fixes#83442
## Changelog
🆑
fix: some missing modsuit (un)sealing messages should no longer be
missing
fix: MOD circuit adapter core deployed parts output should work again
fix: Modsuit painter works again
/🆑
## About The Pull Request
This PR introduces a number of minor quality of life improvements to
already existing circuit components, and adds three new components.
<img width="600" alt="preview"
src="https://github.com/tgstation/tgstation/assets/80724828/85d39b6d-b055-430e-8996-0da088616887">
## Why It's Good For The Game
This improves the overall experience for circuits.
### UI changes
<img width="550" alt="grid aligned"
src="https://github.com/tgstation/tgstation/assets/80724828/cc7b43b5-292f-4643-beab-e01ae675fb19">
Grid align is now an option for circuit designers. It will round objects
to the nearest 10px units internally, and can be toggled on/off by the
new additional button beside the component menu button. This makes
circuits easier on the eyes as things are pixel perfect aligned.
<img width="814" alt="tooltips"
src="https://github.com/tgstation/tgstation/assets/80724828/0d31c98f-3be9-46e0-ab37-20bac3799112">
All three buttons have been given tool tips.
### Tweaked Components
<img width="136" alt="voice activator"
src="https://github.com/tgstation/tgstation/assets/80724828/21dd0f65-cb98-4bd5-aeb0-63315e842cb6">
* Adds a on/off flag to the voice activator component
-- This saves power for circuits as you're not forced to use a compare
flag check to turn off voice activation
<img width="136" alt="speech"
src="https://github.com/tgstation/tgstation/assets/80724828/9137b76c-3077-4597-8411-2d9694b39e9e">
* Adds a quiet mode flag to speech component
-- This is ideal when you want a device to speak, but don't want other
people to hear. A good example would be a handheld translator that you
only want to hear yourself.
### New Components
<img width="136" alt="ntnet list literal"
src="https://github.com/tgstation/tgstation/assets/80724828/657c851b-d442-4a63-8650-410cb8e76089">
* An NTNet Send component that allows everything to be input much like
the list literal component
-- This makes sending stuff over NTNet easier for the user, and use less
power as it won't require an additional list literal component
<img width="136" alt="compare health state"
src="https://github.com/tgstation/tgstation/assets/80724828/0bed076c-3aa1-4931-af90-2b9eb8e1ae9a">
* A health comparison component that checks the entity's health state,
and can return true or false depending if the entity is alive, sleeping,
unconscious, critical or dead
-- This could be achieved by using a health sensor and a compare
component, however it lacks the ability to know when a entity is
unconscious or sleeping
<img width="136" alt="toggle"
src="https://github.com/tgstation/tgstation/assets/80724828/7017b6bf-937a-42ad-87f3-4f1134853ac3">
* A quick toggle component to allow the switching between a true and
false state
-- This could be achieved by using a logic component and self linking,
however this makes it far easier for newcomers to make something as
simple as an on/off switch (such as a handheld translator which uses the
front button to turn on/off)
## Changelog
🆑
qol: Add tooltips to circuit editor buttons
qol: Add grid alignment mode to circuit editor
add: Added new compare health state component
add: Added new NTNet send list literal component
add: Added new toggle component
qol: Added activity toggle to voice activator component
qol: Added quiet mode to speech component
qol: NTNet send component will not use power/trigger if NTNet is offline
/🆑
Scales the hypercharged slime core and wiremod gun cell maximum charge
and charge rate by the STANDARD_CELL_CHARGE and STANDARD_CELL_RATE
defines. Fixes their scale.
Closes#82907
## Changelog
🆑
fix: Fixes hypercharged slime core cells and circuit guns having 1,000
times less energy than intended.
/🆑
## About The Pull Request
This re writes most cell power usage cases with 2 defines
`STANDARD_CELL_CHARGE`(Joules) & `STANDARD_CELL_RATE`(Watts) so changing
cell capacity values in the future won't cause discrepancies.
## Changelog
🆑
code: most cell power usages are scaled with defined constants to help
adapt to future changes
/🆑
## About The Pull Request
Rewrites how alt click works.
Based heavily on #82625. What a cool concept, it flows nicely with
#82533.
Fixes#81242
(tm bugs fixed)
Fixes#82668
<details><summary>More info for devs</summary>
Handy regex used for alt click s&r:
`AltClick\((.*).*\)(\n\t.*\.\.\(\))?`
`click_alt($1)` (yes I am aware this only copies the first arg. there
are no other args!)
### Obj reskins
No reason for obj reskin to check on every single alt click for every
object. It applies to only a few items.
- Moved to obj/item
- Made into signal
- Added screentips
### Ventcrawling
Every single atmospherics machine checked for ventcrawling capability on
alt click despite only 3 objects needing that functionality. This has
been moved down to those individual items.
</details>
## Why It's Good For The Game
For players:
- Alt clicking should work more logically, not causing double actions
like eject disk and open item window
- Added context menus for reskinnable items
- Removed adjacency restriction on loot panel
For devs:
- Makes alt click interactions easier to work with, no more click chain
nonsense and redundant guard clauses.
- OOP hell reduced
- Pascal Case reduced
- Glorious snake case
## Changelog
🆑
add: The lootpanel now works at range.
add: Screentips for reskinnable items.
fix: Alt click interactions have been refactored, which may lead to
unintentional changes to gameplay. Report any issues, please.
/🆑
## About The Pull Request
Fixes#82440
This PR just creates a new macro, `LOWER_TEXT()` (yes the irony is not
lost on me) to wrap around all calls of `lowertext()` and ensure that
whatever we input into that proc will be stringified using the `"[]"`
(or `tostring()` for the nerds) operator. very simple.
I also added a linter to enforce this (and prevent all forms of
regression) because I think that machines should do the menial work and
we shouldn't expect maintainers to remember this, let me know if you
disagree. if there is a time when it should be opted out for some
reason, the linter does respect it if you wrap your input with the
`UNLINT()` function.
## About The Pull Request
I've seen a few cases in the past where LateInitialize is done cause of
the init return value being set to do so for no real reason, I thought I
should try to avoid that by ensuring LateInitialize isn't ever called
without overriding.
This fixes a ton of machine's LateInitialize not calling parent
(mechpad, door buttons, message monitor, a lot of tram machines,
abductor console, holodeck computer & disposal bin), avoiding having to
set itself up to be connected to power. If they were intended to not
connect to power, they should be using ``NO_POWER_USE`` instead.
Also removes a ton of returns to LateInit when it's already getting it
from parent regardless (many cases of that in machine code).
## Why It's Good For The Game
I think this is better for coding standard reasons as well as just
making sure we're not calling this proc on things that does absolutely
nothing with them. A machine not using power can be seen evidently not
using power with ``NO_POWER_USE``, not so much if it's LateInitialize
not calling parent.
## Changelog
🆑
fix: Mech pads, door buttons, message monitors, tram machines, abductor
consoles & holodeck computers now use power.
/🆑
## About The Pull Request
When it comes to deconstructing an object we have `proc/deconstruct()` &
`NO_DECONSTRUCT`
Lets talk about the flag first.
**Problems with `NO_DECONSTRUCTION`**
I know what the comment says on what it should do
b5593bc693/code/__DEFINES/obj_flags.dm (L18)
But everywhere people have decided to give their own meaning/definition
to this flag. Here are some examples on how this flag is used
**1. Make the object just disappear(not drop anything) when
deconstructed**
This is by far the largest use case everywhere. If an object is
deconstructed(either via tools or smashed apart) then if it has this
flag it should not drop any of its contents but just disappear. You have
seen this code pattern used everywhere
b5593bc693/code/game/machinery/constructable_frame.dm (L26-L31)
This behaviour is then leveraged by 2 important components.
When an object is frozen, if it is deconstructed it should just
disappear without leaving any traces behind
b5593bc693/code/datums/elements/frozen.dm (L66-L67)
By hologram objects. Obviously if you destroy an hologram nothing real
should drop out
b5593bc693/code/modules/holodeck/computer.dm (L301-L304)
And there are other use cases as well but we won't go into them as they
aren't as significant as these.
**2. To stop an object from being wrenched ??**
Yeah this one is weird. Like why? I understand in some instances (chair,
table, rack etc) a wrench can be used to deconstruct a object so using
the flag there to stop it from happening makes sense but why can't we
even anchor an object just because of this flag?
b5593bc693/code/game/objects/objs.dm (L368-L369)
This is one of those instances where somebody just decided this
behaviour for their own convenience just like the above example with no
explanation as to why
**3. To stop using tools to deconstruct the object**
This was the original intent of the flag but it is enforced in few
places far & between. One example is when deconstructing the a machine
via crowbar.
b5593bc693/code/game/machinery/_machinery.dm (L811)
But machines are a special dual use case for this flag. Because if you
look at its deconstruct proc the flag also prevents the machine from
spawning a frame.
b5593bc693/code/game/machinery/_machinery.dm (L820-L822)
How can 1 flag serve 2 purposes within the same type?
**4. Simply forget to check for this flag altogether**
Yup if you find this flag not doing its job for some objects don't be
surprised. People & sometimes even maintainers just forget that it even
exists
b5593bc693/code/game/objects/items/piggy_bank.dm (L66-L67)
**Solution**
These are the main examples i found. As you can see the same flag can
perform 2 different functions within the same type and do something else
in a different object & in some instances don't even work cause people
just forget, etc.
In order to bring consistency to this flag we need to move it to the
atom level where it means the same thing everywhere. Where in the atom
you may ask? .Well, I'll just post what MrMelbert said in
https://github.com/tgstation/tgstation/pull/81656#discussion_r1503086862
> ...Ideally the .deconstruct call would handle NO_DECONSTRUCTION
handling as it wants,
Yup that's the ideal case now. This flag is checked directly in
`deconstruct()`. Now like i said we want to give a universal definition
to this flag and as you have seen from my examples it is used in 3 cases
1) Make an object disappear(doesn't dropping anything) when
deconstructed
2) Stop it from being wrenched
3) Stop it from being deconstructed via tools
We can't enforce points 2 & 3 inside `deconstruct()` which leaves us
with only case 1) i.e. make the object disappear. And that's what i have
done. Therefore after more than a decade or since this flag got
introduced `NO_DECONSTRUCT` now has a new definition as of 2024
_"Make an object disappear(don't dropping anything) when deconstructed
either via tools or forcefully smashed apart"_
Now i very well understand this will open up bugs in places where cases
2 & 3 are required but its worth it. In fact they could even be qol
changes for all we know so who knows it might even benefit us but for
now we need to give a universal definition to this flag to bring some
consistency & that's what this PR does.
**Problem with deconstruct()**
This proc actually sends out a signal which is currently used by the
material container but could be used by other objects later on.
3e84c3e6da/code/game/objects/obj_defense.dm (L160)
So objects that override this proc should call its parent. Sadly that
isn't the case in many instances like such
3e84c3e6da/code/game/machinery/deployable.dm (L20-L23)
Instead of `return ..()` which would delete the object & send the signal
it deletes the object directly thus the signal never gets sent.
**Solution**
Make this proc non overridable. For objects to add their own custom
deconstruction behaviour a new proc has been introduced
`atom_deconstruct()` Subtypes should now override this proc to handle
object deconstruction.
If objects have certain important stuff inside them (like mobs in
machines for example) they want to drop by handling `NO_DECONSTRUCT`
flag in a more carefully customized way they can do this by overriding
`handle_deconstruct()` which by default delegates to
`atom_deconstruct()` if the `NO_DECONSTRUCT` flag is absent. This proc
will allow you to handle the flag in a more customized way if you ever
need to.
## Why It's Good For The Game
1) I'm goanna post the full comment from MrMelbert
https://github.com/tgstation/tgstation/pull/81656#discussion_r1503086862
> ...Ideally the .deconstruct call would handle NO_DECONSTRUCTION
handling as it wants, but there's a shocking lack of consistency around
NO_DECONSTRUCTION, where some objects treat it as "allow deconstruction,
but make it drop no parts" and others simply "disallow deconstruction at
all"
This PR now makes `NO_DECONSTRUCTION` handled by `deconstruct()` & gives
this flag the consistency it deserves. Not to mention as shown in case 4
there are objects that simply forgot to check for this flag. Now it
applies for those missing instances as well.
2) No more copying pasting the most overused code pattern in this code
base history `if(obj_flags & NO_DECONSTRUCTION)`. Just makes code
cleaner everywhere
3) All objects now send the `COMSIG_OBJ_DECONSTRUCT` signal on object
deconstruction which is now available for use should you need it
## Changelog
🆑
refactor: refactors how objects are deconstructed in relation to the
`NO_DECONSTRUCTION` flag. Certain objects & machinery may display
different tool interactions & behaviours when destroyed/deconstructed.
Report these changes if you feel like they are bugs
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
Ever since https://github.com/tgstation/tgstation/pull/81215 I havent
been able to scan anyone that was wearing or holding anything with a
circuit multi tool because the options never popped up, the click was
just unresponsive and nothing would happen.
Then I remembered that Ghommie posted a picture of it working when the
pr was first made and went to look at any changes made in the commits
afterwards
For some reason uniqueid set to true was what made the list not appear,
and I cant find any side effects from removing that bit of code.
## Why It's Good For The Game
This works as intended.
https://github.com/tgstation/tgstation/assets/62126254/61a5435c-9d51-462b-927a-9b1fc1cffb0e
## Changelog
🆑
fix: Circuit multitools can now correctly scan carbons who are wearing
clothes or holding objects again.
/🆑
## About The Pull Request
My lua scripts were hitting the topic byte limit, so this makes file
upload of lua scripts able to bypass the topic limit.
## Why It's Good For The Game
Removes arbitrary restriction on how big a lua file can be in bytes.
## Changelog
🆑
admin: Admins can now run lua files bigger than 36 KB by importing them
directly.
/🆑
Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com>
## About The Pull Request
- Fixes#82190
Have to now use the assigned constants and not magic number `10000`.
Also stuff will take the exact charge needed without any wastage.
## Changelog
🆑
fix: recharge stations draw the same amount of power as before but
directly from grid(without using apc cell power) and won't waste any
excess power
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
Removes all arbitrary energy and power units in the codebase. Everything
is replaced with the joule and watt, with 1 = 1 joule, or 1 watt if you
are going to multiply by time. This is a visible change, where all
arbitrary energy units you see in the game will get proper prefixed
units of energy.
With power cells being converted to the joule, charging one joule of a
power cell will require one joule of energy.
The grid will now store energy, instead of power. When an energy usage
is described as using the watt, a power to energy conversion based on
the relevant subsystem's timing (usually multiplying by seconds_per_tick
or applying power_to_energy()) is needed before adding or removing from
the grid. Power usages that are described as the watt is really anything
you would scale by time before applying the load. If it's described as a
joule, no time conversion is needed. Players will still read the grid as
power, having no visible change.
Machines that dynamically use power with the use_power() proc will
directly drain from the grid (and apc cell if there isn't enough)
instead of just tallying it up on the dynamic power usages for the area.
This should be more robust at conserving energy as the surplus is
updated on the go, preventing charging cells from nothing.
APCs no longer consume power for the dynamic power usage channels. APCs
will consume power for static power usages. Because static power usages
are added up without checking surplus, static power consumption will be
applied before any machine processes. This will give a more truthful
surplus for dynamic power consumers.
APCs will display how much power it is using for charging the cell. APC
cell charging applies power in its own channel, which gets added up to
the total. This will prevent invisible power usage you see when looking
at the power monitoring console.
After testing in MetaStation, I found roundstart power consumption to be
around 406kW after all APCs get fully charged. During the roundstart APC
charge rush, the power consumption can get as high as over 2MW (up to
25kW per roundstart APC charging) as long as there's that much
available.
Because of the absurd potential power consumption of charging APCs near
roundstart, I have changed how APCs decide to charge. APCs will now
charge only after all other machines have processed in the machines
processing subsystem. This will make sure APC charging won't disrupt
machines taking from the grid, and should stop APCs getting their power
drained due to others demanding too much power while charging. I have
removed the delays for APC charging too, so they start charging
immediately whenever there's excess power. It also stops them turning
red when a small amount of cell gets drained (airlocks opening and shit
during APC charge rush), as they immediately become fully charged
(unless too much energy got drained somehow) before changing icon.
Engineering SMES now start at 100% charge instead of 75%. I noticed
cells were draining earlier than usual after these changes, so I am
making them start maxed to try and combat that.
These changes will fix all conservation of energy issues relating to
charging powercells.
## Why It's Good For The Game
Closes#73438Closes#75789Closes#80634Closes#82031
Makes it much easier to interface with the power system in the codebase.
It's more intuitive. Removes a bunch of conservation of energy issues,
making energy and power much more meaningful. It will help the
simulation remain immersive as players won't encounter energy
duplication so easily. Arbitrary energy units getting replaced with the
joule will also tell people more meaningful information when reading it.
APC charging will feel more snappy.
## Changelog
🆑
fix: Fixes conservation of energy issues relating to charging
powercells.
qol: APCs will display how much power they are using to charge their
cell. This is accounted for in the power monitoring console.
qol: All arbitrary power cell energy units you see are replaced with
prefixed joules.
balance: As a consequence of the conservation of energy issues getting
fixed, the power consumption for charging cells is now very significant.
balance: APCs only use surplus power from the grid after every machine
processes when charging, preventing APCs from causing others to
discharge while charging.
balance: Engineering SMES start at max charge to combat the increased
energy loss due to conservation of energy fixes.
/🆑
---------
Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com>
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
That's it really.

It's supposed to have a `shock_source` arg, but 2/3 of the procs that
are registered to this signal don't include that in their args list.
## Why It's Good For The Game
Out of order positional args = bad.
## Changelog
Nothing player facing (probably)