## 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
So apparently RLD glowsticks just straight up didn't glow, but also
thought they were on.
Looking into it, this seemed to be an issue of it using `G.light_on =
TRUE` rather than `G.turn_on()`.
Replacing it with the latter fixes our issue.
We then also just, replace the single letter variable `G`.
## Why It's Good For The Game
Y'know I think glowsticks should probably like, actually glow, right?
## Changelog
🆑
fix: RLD glowsticks actually glow again.
/🆑
## About The Pull Request
**1. Qol**
- Screentips & examines for welder, wrench & plunger tools
- Examining plumbing machinery will display the reagents & their
respective volumes present inside
- Plumbing grinder now has a grind/juice mode which can be changed by
hand
**2. Code Improvements**
- Rapid plumbing device now uses the new attack
chain(`interact_with_atom()` & `interact_with_atom_secondary()`) instead
of the general `attackby()`
- Same attack chain improvements applied for plumbing grinder
- Plumbing grinder now processes items that enter into it asynchronously
**3. Fixes**
- Fixes#83538. Contains various sub changes
- You can now attack the plumbing grinder with any item in combat mode
without the grinder trying to consuming it
- You can deconstruct the plumbing grinder with the Rapid plumbing
device without the grinder trying to consuming it
- You cannot grind abstract & hologram items in the plumbing grinder
- Growing vat now uses the correct layer selected on rapid plumbing
device
## Changelog
🆑
qol: more examines & screentips for plumbing machinery
qol: plumbing grinder has a grind/juice mode which be toggled by hand
code: improved attack chain for RPLD & plumbing grinder
fix: You can deconstruct the plumbing grinder with the RPLD
fix: You can attack the plumbing grinder with any item in combat mode
without getting that item consumed
fix: You cannot grind abstract/ hologram items in the plumbing grinder
fix: growing vat now uses the correct layer selected on rapid plumbing
device
/🆑
## About The Pull Request
Increased the speed by 10 times. Was annoying when I was in localhost
testing something.
## Why It's Good For The Game
Admin and debugging tools should be OP for increasing productivity and
making life easier for coders/jannies.
## Changelog
🆑 grungussuss
admin: admin RCD now works much faster.
/🆑
Adds names and icon states to RCD/RPD upgrades
I don't have a pile of 6 disks on the lathe that all look identical and
the RCD going YOU HAVE THAT ONE INSTALLED ALREADY, TRY AGAIN IDIOT as I
fall into further despair
## 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
Using these search regexes:
Ending in 0:
`addtimer\((.*),\s?(\d{1,3})0\b\)`
replacement:
`addtimer($1, $2 SECONDS)`
Two digit ending in odd:
`addtimer\((.*), (\d)([1-9])\)$`
replacement:
`addtimer($1, $2.$3 SECONDS)`
Single digit ending odd:
`addtimer\((.*), ([1-9])\)$`
replacement:
`addtimer($1, 0.$2 SECONDS)`
## Why It's Good For The Game
Code readability
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
## About The Pull Request
Using these search regexes:
Number ending in 0:
`do_after\((\w+), (\d+)0,`
Replace:
`do_after($1, $2 SECONDS,`
Single digit number:
`do_after\((\w+), [1-9],`
replace:
`do_after($1, 0.$2 SECONDS,`
Double:
`do_after\((\w+), (\d)([1-9]),`
Replace:
`do_after($1, $2.$3 SECONDS,`
## Why It's Good For The Game
Code readability
## 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
Yeah i am not about to create 30 different PR's to address 1 issue at a
time. The changes are small enough to be grouped together in bulk.
This fixes the following issues specified in #82196
- Borg & exosuit RCD (Fixes#82193)
- Motorized wheelchair
- Canister shielding
- Electrolyser
- Potato cell
- Space heater
- Microwave
## Changelog
🆑
fix: Fixed cell energy usage for a bunch of stuff(Part 1). See PR 82197
for details
/🆑
---------
Co-authored-by: Pickle-Coding <58013024+Pickle-Coding@users.noreply.github.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
- Fixes#82060
We don't need information about the cost & delay. Just enough to know
the intent behind the action
This also removes the 2nd argument in `log_tool()` because it was unused
and nobody should look at json logs to see the mob behind the action
## Changelog
🆑
fix: RCD logs are more human readable & stores the player name behind
the action.
/🆑
## About The Pull Request
Adds logging for RCD construction and deconstruction. Hallucinated
projectiles no longer causes logs. Flamethrowers log gas mixture
information, the flamethrower, the gas tank, tank distribution pressure
and whether it was lit. Adds a lot more logging to records consoles.
Frozen objects now log when they get shattered.
## Why It's Good For The Game
Closes#68452Closes#71798Closes#78008Closes#81098Closes#81130
## Changelog
🆑 Pickle-Coding and Rhials
admin: RCD construction and deconstruction are logged.
admin: Hallucinated projectiles no longer log.
admin: Gives more detail to flamethrower logging.
admin: More actions are logged for records consoles usage.
admin: Frozen object shattering is logged.
/🆑
---------
Co-authored-by: Rhials <Datguy33456@gmail.com>
## About The Pull Request
While on the floor, you can:
- Use the UIs of Atmos machinery (except thermomachine and bluespace gas
vendor), Holopads, Crayons (spray cans too), radios, and Disposal bins
- Close extinguisher cabinets with Right-Click
- Click and drag yourself onto a photocopier to climb onto it.
I also changed all instances of ``ui_status`` to have all the args it's
being passed, I was messing with it a bit but it's gonna be for a later
PR.
## Why It's Good For The Game
It's an extra layer of harmless realism, also nice QoL for people who do
not have functional legs and do not have a wheelchair.
## Changelog
🆑
qol: You can use atmos machines, holopads, crayons, spray cans, and
disposal bins while floored.
fix: You can close extinguisher cabinets while floored.
fix: You can climb onto a photocopier from the floor.
/🆑
## About The Pull Request
I recently played a game where I rotated my skeleton model while
rotating my own character at the same time and it being in sync gave me
the realization on how cool it would be if the Coroner was able to
simply control the skeleton body.
I find skeleton displays very funny and I want to see more funny things
happen with them, so I thought this would be a good place to start, with
the benefits that it also works on mannequins and statues too so they
aren't left out.
Basically, while it is unanchored, if you have a statue/mannequin
grabbed, it will change its direction as you do, and speak the same
words you do. Your own messages can only be heard if the person is
directly next to you, revealing that it was you talking through it all
along.
I was originally gonna add this to the simple rotation component but
moved off when I decided to add talking through it, I left in the code
improvements I made to the component though since it is one of the
oldest components and hasn't been touched in a while.
Video demonstration (before I added the person also talking, just ignore
that missing)
https://github.com/tgstation/tgstation/assets/53777086/27242fc3-9649-418d-95cb-b31619319e97
While fixing the Toilet bong's rotation stuff I noticed a lot of it
wasn't up to proper code standards so I went over it and fixed issues I
had with it. It now doesn't give text saying you found something nasty
to species that still likes mice (like flypeople), and fixed its update
appearance to match the codebase standard set by the introduction of
``update_appearance`` many years ago.
## Why It's Good For The Game
It's a funny small idea I had and got inspired to add, it's a niche
mechanic that I think fits the aesthetic I am going for with Coroner and
also give a funny interaction with the human-like inanimate objects.
## Changelog
🆑
fix: Species that can eat mice don't get disgusted from seeing one in
the toilet bong.
add: Grabbing an unwrenched statue/mannequin/skeleton model will now
move its direction as you move yours, and you can talk through it.
/🆑
## About The Pull Request
This gives the mounted RCD the same functionality as the handheld
version, from upgrades to destruction scanning. Upgrades can be
installed by using them on either the mech or the equipment item, and
both the scanner and RCD menu can be accessed in the equipment's menu.
Because mechs don't have different left/right click actions,
deconstructing is toggled in the menu as well.
## Why It's Good For The Game
Gives exosuits more things to do that aren't combat-related, which I
feel is lacking currently.
## Changelog
🆑
add: Exosuit-mounted RCDs now have the same functionality as the
handheld version.
/🆑
## About The Pull Request
[Converts all manual extraction of rbg with rgb2num. It's just
better](ae798eabd5)
[Yanks out old HSV management, replaces it with list
stuff](4997e86051)
There's this old lummy era clunky code that passed HSV as text
We can now cleanly replace it with passing hsv as lists from a rgb2hsv
proc
So let's just do that.
Also, cleans up spraytan code (and ethereal lighting)
## Why It's Good For The Game
Code better
## About The Pull Request
Adds a button to RPD tgui that lets you build multiple pipe layers with
the RPD with 1 click
## Why It's Good For The Game
Saves a lot of time when using multiple layers, especially all 5, and is
very useful for SM setups and other convoluted atmos contraptions
https://github.com/tgstation/tgstation/assets/46101244/04993fee-7b35-483f-8cb1-a8b58ff1246a
## Changelog
🆑
qol: You can now build multiple pipe layers with the RPD, with just 1
click!
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
I woke up today and thought 'what would be easy thing to do today so I
can say I've done something?'. Then I remembered I saw several gangtool
usages the time I split radio up, and I could remedy those. 7 hours
later, device.dmi is split in a folder of its own, and I've also given
unique sprites to door remotes and landing desginators.
## Why It's Good For The Game
The device.dmi was kind of a mess.
## Changelog
🆑
/🆑
## About The Pull Request
Lets you instantly delete pipes/atmos devices with the RPD rather than
wait 0.2s
## Why It's Good For The Game
Playing atmos is a pain because of how time consuming it is, 0.2s adds
up. It's especially annoying if a bomb goes off and you have to click on
every single little loose pipe/heatpipe/device and wait to get rid of
them
## Changelog
🆑
balance: Deleting and reprogramming pipes/devices with RPD is now
INSTANT!
/🆑
## About The Pull Request
Code to handle this flag only ever existed on the `/obj` sublevel, so
there's no need for it to be on the `/atom` level `flags_1`. There was
probably a point in time in which mobs or turfs conducted electricity
but there's zero code for it anymore so we truly just live in a society
now.
## Why It's Good For The Game
Frees up a slot on `flags_1` (which is really nice actually), proper
scoping of certain bitflag stuff, etc.
## Changelog
Not relevant to players.
I may have screwed something up, will be doing a few passes on this
myself to ensure all the search and replaces went alright but we should
be good™️
## About The Pull Request
- Fixes https://github.com/Skyrat-SS13/Skyrat-tg/issues/23788
So after #77858 was merged an unintentional side effect was rcd could no
longer build directional windows on grills if they already existed on
the turf. Sure rcd won't build a grill and then build a directional
window on top of that but if a grill already exists on the turf the rcd
should still be able to build directional windows on that grill as it
helps in repairing mapped in directional windows and such.
If you want to build a grill first set the mode to full tile window,
build the grill and then switch to directional window to build a window
on top of that grill. Or just select directional window mode and build
the windows directly without a grill, choice is yours
## Changelog
🆑
fix: RCD can build directional windows on top of existing grills &
without them.
/🆑
## About The Pull Request
Third /icon/ cleansing splinter 1. Comments on commits say all it does
pretty much.
## Why It's Good For The Game
Inhand for walkietalkie was requested in the project, gets rid of some
usecases of old 'gangtool', headset splitoff requested by Fazzie.
Inhands reflecting the items they are supposed to represent is nice.
## Changelog
🆑
image: Following now have unique item sprites: syndicate war declaration
radio, curator and chief beacon's, chaplain beacon.
image: Following now have unique inhand sprites: radio, export scanner,
walkie-talkie, syndicate war declaration radio, curator and chief
beacon's, chaplain beacon.
/🆑
## About The Pull Request
Closes#79301
Saw this PR, realized how much this annoyed me whenever I played. Not a
hard fix either, since RCD's were a perfect example.
(In the future perhaps items that use upgrades like this could have one
base type of disk, and a component for 'upgrade_disk_tool', but that's
way, WAY out of my experience. Just something I noticed between the RPD
and RCD disks.)
One on the Left already has the upgrade. Neither try to double-install
it! (Shown for posterity)
Ones on the right are installed both ways. One, the RPD on the Disk. The
other, the Disk on the RPD!
---
Actual PR changes:
- New proc on the RPD called `install_upgrade()` - If the upgrade disk
isn't installed, it installs it onto the RPD and deletes the disk. So,
the same as the RCD one, but fewer checks since the RPD's got a lot
fewer disks. But, easier to add new ones now.
- Since `install_upgrade()` is a thing, the attack chain's code for how
RPD's originally got upgraded is now much shorter. It still functions
the same, though - nothing was removed in this PR!
- Adds an attackby check - if the RPD's attacked by an upgrade disk it
will try to `install_upgrade()`. So basically, what RCD's have.
## Why It's Good For The Game
Consistency between the RPD and RCD upgrade-wise. The RPD's other method
of installing (hitting the disk WITH the RPD) still works, but now
players used to the RCD won't get confused.
## Changelog
🆑
qol: The RPD now accepts upgrade disks inserted by hand, as well as
their original method of hitting the disk with the RPD
/🆑
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
## About The Pull Request
#67676 described a bug where PDAs can apparently emit a small amount of
light after being affected by the light eater. As it turns out, the bug
is even worse than that. It doesn't work for just PDAs, it works for
basically any light source that can be turned off and on. Even
flashlights. In the following pictures, a flashlight has been
light-eaten and then turned off and on again:
Observe how the nightmare jaunt is available, as it should be. However,
one step closer to the flashlight:
The nightmare jaunt can no longer be used, because the flashlight is
still emitting light.
This PR just fixes that behavior. Light-eaten objects will now be
totally dark again, even after being power cycled. Closes#67676.
## Why It's Good For The Game
Bugs bad.
## Changelog
🆑
fix: Light-Eaten objects can no longer emit light after being turned off
and then back on.
code: Flashlights now use light_on instead of defining their own
variable. Please report buggy behavior.
/🆑
## About The Pull Request
When switching between "Construction" & "Airlocks" tab the UI would not
update unless you closed & reopened the UI. This was annoying so I fixed
it & now the UI updates properly. Same applies for RTD when switching
between floor types
## Changelog
🆑
fix: RCD & RTD ui updates when switching between root categories
/🆑
## About The Pull Request
The changes made can be best summarized into points
**1. Cleans up `code/_DEFINES/construction.dm`**
Looking at the top comment of this file
0fb8b8b218/code/__DEFINES/construction.dm (L1)
One would expect stuff related to materials, rcd, and other construction
related stuff. Well this file is anything but
Why is there stuff related to food & crafting over here then?
0fb8b8b218/code/__DEFINES/construction.dm (L91-L94)
It gets worse why are global lists declared here?
0fb8b8b218/code/__DEFINES/construction.dm (L115)
There is a dedicated folder to store global lists i.e.
`code/_globalvars/lists` for lists like these. These clearly don't
belong here
On top of that a lot of construction related defines has been just
dumped here making it too large for it's purposes. which is why this
file has been scraped and it's
1. crafting related stuff have been moved to its
`code/_DEFINES/crafting.dm`
2. global lists for crafting moved to
`code/_globalvars/lists/crafting.dm`
3. Finally remaining construction related defines split apart into 4
file types under the new `code/_DEFINES/construction` folder
- `code/_DEFINES/construction/actions.dm` -> for wrench act or other
construction related actions
- `code/_DEFINES/construction/material.dm` -> contains your sheet
defines and cable & stack related values. Also merged
`code/_DEFINES/material.dm` with this file so it belongs in one place
- `code/_DEFINES/construction/rcd.dm` -> dedicated file for everything
rcd related
- `code/_DEFINES/construction/structures.dm` -> contains the
construction states for various stuff like walls, girders, floodlight
etc
By splitting this file into multiple meaningful define file names will
help in reducing merge conflicts and will aid in faster navigation so
this is the 1st part of this PR
**2. Debloats the `RCD.dm` file(Part 1)**
This uses the same concepts as above. i.e. moving defines into their
appropriate files for e.g.
0fb8b8b218/code/game/objects/items/rcd/RCD.dm (L170)
1. Global vars belong in the `code/_globalvars` folder so these vars and
their related functions to initialize them are moved into the
`code/_globalvars/rcd.dm` file
2. See this proc
0fb8b8b218/code/game/objects/items/rcd/RCD.dm (L200)
This proc does not belong to the `obj/item/construction/rcd` type it's a
global "helper function" this is an effect proc as it creates rcd
holograms so it has been moved to the `code/game/objects/effects/rcd.dm`
file which is a global effect that can be used by anyone
And with that we have moved these vars & procs into their correct places
& reduced the size of this file . We can go even further
**3. Debloats the `RCD.dm` file(Part 2)**
This deals with the large list which contains all the designs supported
by the RCD
0fb8b8b218/code/game/objects/items/rcd/RCD.dm (L42)
This list contains a lot of local defines. We can scrape some of them
and reduce the overall bulkiness & memory requirements of this list and
so the following defines
```
#define WINDOW_TYPE "window_type"
#define COMPUTER_DIR "computer_dir"
#define WALLFRAME_TYPE "wallframe_type"
#define FURNISH_TYPE "furnish_type"
#define AIRLOCK_TYPE "airlock_type"
#define TITLE "title"
#define ICON "icon"
#define CATEGORY_ICON_STATE "category_icon_state"
#define CATEGORY_ICON_SUFFIX "category_icon_suffix"
#define TITLE_ICON "ICON=TITLE"
```
Have all been removed making this list a lot more cleaner. Why? because
a lot of these are just semantic sugar, we can infer the value of a lot
of these defines if we just know the type path of the structure the rcd
is trying to build for e.g. take these 2 defines
0fb8b8b218/code/game/objects/items/rcd/RCD.dm (L13-L15)
These defines tell the rcd UI the name and the icon it should display.
Rather than specifying these manually in the design we can infer them
like this
```
var/obj/design = /obj/structure/window //let's say the rcd is trying to build an window
var/name = initial(design.name) //we have inferred the name of the design without requiring TITLE define
var/icon = initial(design.icon_state) //we have inferred the icon of the design without requiring ICON define
```
And so by using similar logic to the remaining defines we can eliminate
a lot of these local defines and reduce the overall size of this list.
The same logic applies to the different modes of construction, the
following defines
0fb8b8b218/code/__DEFINES/construction.dm (L186-L192)
Have all been removed and replaced with a single value `RCD_STRUCTURE`
All these modes follow the same principle when building them
1. First check the turf if the structure exists. If it does early return
2. If not create a new structure there and that's it
So rather than creating a new construction mode every time you want to
add a new design we can use this mode to apply this general approach
every time
The design list has also now been made into a global list rather than a
private static list. The big advantage to this is that the rcd asset
cache can now access this list and load the correct icons from the list
directly. This means you no longer have to manually specify what icons
you want to load which is the case currently.
0fb8b8b218/code/modules/asset_cache/assets/rcd.dm (L8-L9)
This has lead to the UI icons breaking twice now in the past
- #74194
- #77217
Hopefully this should never repeat itself again
**4. Other RCD like device changes**
- Fixed the broken silo link icon when the radial menu of the RLD was
opened
- replaced a lot of vars inside RLD with defines to save memory
- Small changes to `ui_act` across RCD, Plumbing RCD and RTD
- Removed unused vars in RCD and snowflaked code
- Moved a large majority of `ui_data()` to `ui_static_data()` making the
experience much faster
Just some general clean up going on here
**5. The Large majority of other code changes**
These are actually small code changes spread across multiple files.
These effect the `rcd_act()` & the `rcd_vals()` procs across all items.
Basically it
- Removes a large majority of `to_chat()` & `visible_message()` calls.
This was done because we already have enough visual feedback of what's
going on. When we construct a wall we don't need a `to_chat()` to tell
us you have a built a wall, we can clearly see that
- replaces the static string `"mode"` with a predefined constant
`RCD_DESIGN_MODE` to bring some standard to use across all cases
Should reduce chat spam and improve readability of code.
**6. Airlock & Window names**
The rcd asset cache relies on the design name to be unique. So i filled
in the missing names for some airlocks & windows which are subjective
and open to change but must have some value
**7 Removes Microwave PDA upgrade**
The RCD should not be allowed to build this microwave considering how
quickly it can spawn multiple structures and more importantly as it's a
special multipurpose machine so you should spend some effort in printing
it's parts and acquiring tools to complete it. This upgrade makes
obsolete the need to carry an
- A RPED to install the parts
- A screwdriver to complete the frame
- The circuit board for the microwave
The most important point to note here is that whenever an RPED/circuit
board is printed at an lathe it charges you "Lathe Tax". The RCD with
this upgrade would essentially bypass the need to "Pay Taxes" at these
lathes as you are just creating a circuit board from thin air. This
causes economy imbalance(10 cr per print) which scales up the more of
these machines you make so to avoid this let's end the problem here
Not to mention people would not find the need to print the circuit board
for a regular microwave now if they have an RCD because they can just
make this microwave type making the need for a regular microwave
completely pointless.
Just build a machine frame with the RCD and complete the microwave from
there
## Changelog
🆑
code: moved global vars, lists and helper procs for construction related
stuff to their appropriate files
code: reduced overall code size & memory of rcd design list and removed
unused defines
refactor: removed a ton of chat alerts for rcd related actions to help
reduce chat spam
refactor: some airlock & window default names have changed
fix: broken icon in radial menu of rld silo link
remove: removes microwave pda upgrade from RCD. It's a special machine
so spend some time in building it rather than shitting them out for free
with the RCD. Use the RCD upgrade to spawn a machine frame instead & go
from there
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
For the hard-working tradesperson who's in the middle of nowhere and
just wants to warm up their pastry-based savoury item purchased from an
overpriced vending machine, introduces the engineer themed wireless
microwave.
No more going hungry in a pinch, this variant uses changeable power
cells instead of APC power. Can be built normally or printed with a
furnishings-upgraded RCD.
The other upgrade now available: PDA charging. Upgrade the capacitors in
the microwave to add a Charge mode for your portable device!
Also cleans up microwave code a bit and adds much needed context hints
for when it's broken, dirty, etc.
Swaps a few break room microwaves to upgraded variants on mapload, adds
a microwave/donks to Birdshot, donks to Tramstation.
## Why It's Good For The Game
Slap together a semi-portable microwave with your components on hand,
have an engineering picnic in space or wherever else the day takes you.
With increased PDA drain, adding another option to charge your PDA in
common areas is useful. Microwaves are already strategically placed
around the station. Please ensure the model you're using has the
charging feature before operating.
## Changelog
🆑 LT3
add: Introducing Nanotrasen Wave! A Nanotrasen exclusive, Waveallows
your PDA to be charged wirelessly through microwave frequencies. You can
Wave-charge your device by placing it inside a compatible microwave and
selecting the charge mode.
add: Microwaves can be upgraded to add wireless charging
add: Cell-swappable microwave for the engineer on-the-go
add: Microwave now has a wire to swap charge/cook modes
add: Furnishings RCD upgrade now includes wireless microwave
add: Tramstation and Birdshot engineering break rooms now have microwave
and donk pockets. Some microwaves come pre-equipped with wireless
charging and an upgraded cell.
fix: The microwave in the snowdin ruin is now real, not a fluff prop
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
This takes all the gib related procs:
- `gib()`
- `spawn_gibs()`
- `spill_organs()`
- `spread_bodyparts()`
And adds heavy documentation that communicates what the procs are used
for and how the different bitflags affect them. The difference is
noticeable:
`gib(TRUE, FALSE, FALSE, null)` vs `gib(DROP_ORGANS|DROP_BODYPARTS)`
The code is now much more legible which is important considering it's
used in a lot of places!
Another robust change, is that we had several places in the code where
there were double negatives like so:
```
/mob/living/carbon/spill_organs(no_brain, no_organs, no_bodyparts)
if(!no_bodyparts) // DOUBLE NEGATIVES ARE BAD M'KAY?!?
// do stuff here
```
This is a mindfuck to untangle. I inverted a lot of these parts so we
don't lose our sanity.
Last thing that was changed was a big `if()` loop in the `spill_organ()`
proc. This was refactored to just be a simple `for` loop with `continue`
statements where we needed to skip enabled bitflags. It's now shorter
and cleaner than before.
The only slight gameplay change this affects is that gibbing a mob now
guarantees to drop all items unless the `DROP_ITEMS` bitflag is
deliberately omitted. Some places like admin gib self, we don't want
this to happen.
## Why It's Good For The Game
Gib code is very old. (~15 years) People kept adding more arguments to
the procs when it should have been a bitflag initially. By doing it this
way, there is more flexibility and readability when it comes to adding
new code in the future.
## Changelog
🆑
refactor: Refactor gib code to be more robust.
qol: Gibbing a mob will result in all items being dropped instead of
getting deleted. There are a few exceptions (like admin gib self) where
this will not take place.
/🆑
## About The Pull Request
Continuation of https://github.com/tgstation/tgstation/pull/77946, I
missed quite a few of these it seems.
## Why It's Good For The Game
Stop the spread of these typos!!
## Changelog
Nothing player facing
## About The Pull Request
Fixes#77852
RCD can build wall mounts on reinforced walls
Closes#77848
Not a fix so labelling this as a qol cause it was always intentional but
now RCD can build directional windows without building a grill first.
Saving some matter units from building a grill is a plus
Added auto doc for some procs & made the extra delay when building
multiple structures into a define
## Changelog
🆑
fix: rcd can build wallmounts on reinforced walls
qol: rcd can build directional windows without requiring/building a
grill
/🆑
## About The Pull Request
Fixes flipped transit tube stations being inaccessible and adds a new
rotator disposal pipe which rotates the incoming atom 90 degrees no
matter which direction the atom comes from.
## Why It's Good For The Game
Adds new disposal pipe usage for cool projects and fixes a bug.
## Changelog
🆑
add: New rotator disposal pipe.
fix: Flipped transit tube stations are now accessible in the RPD again.
image: New rotator disposal pipe sprite.
/🆑
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
1. Removes `/obj/machinery/ore_silo/proc/remote_attackby()`. This proc
calls `datum/component/material_container/user_insert()` anyway which
performs all the checks necessary for inserting stuff into the ore silo
and `/obj/machinery/ore_silo/proc/remote_attackby()` was just repeating
its code & checks. So now inserting into the ore silo is directly
handled by the mat container without this proxy proc making the
operation slightly faster
2. Removed silo `attackby` code. Same operations can be done via
`screwdriver_act` & `crowbar_act` procs much cleaner
3. The ore silo now hooks onto signals
`COMSIG_MATCONTAINER_ITEM_CONSUMED` and
`COMSIG_MATCONTAINER_SHEETS_RETRIVED` and logs into silo when they are
triggered. This means when you insert/eject sheets from the silo the
connected machine performing the operation no longer has to do the
logging manually thus the proc `silo_log` has been removed from a lot of
places ,reducing overall code size
4. A lot of stuff that use materials from the ore silo follow this
pattern.
i.e. They first use the materials from the silo and then log it via
`silo_log` proc. This code pattern is repeated in a lot of places so
let's just merge these 2 lines with some extra sanity checks into a
single proc inside `remote_materials` itself. That's what was done and
the number of places where you log manually into the silo has been
removed further reducing code size everywhere.
5. Added auto doc & cleaned up some procs
Since logging is now done by the ore silo directly, we need a way to
pass the machine that is inserting items into the silo to the signal
handlers of the ore silo [via the `context` var]. So other code changes
elsewhere is because of this var
## About The Pull Request
- Gives engineers an RCD as part of their round start equipment
- RCD by default will build/deconstruct slower if you already have
another one in progress. This can be upgraded with the new cooling
upgrade disk. Reconstructing (anything that was there roundstart as per
the destructive scan) doesn't have this downside, only
construction/deconstruction.
- RCD construction effects can now be attacked in order to cancel them.
This can be deterred with the anti-disruption upgrade disk.
- RCDs for nukies and whatever don't have these downsides
- The CE's roundstart RCD also doesn't have these downsides
## Why It's Good For The Game
Construction and reconstruction are currently one of the worst aspects
of SS13--they are so slow and tedious that any sort of mass destruction
goes unfixed for 10-30+ minutes, if fixed at all. This limits us because
it means people don't want traitors to create large explosions, for
instance--I do and so I think it's crucial that we fix construction.
Reconstruction has already been improved on the RCD with the destructive
scans, but I see no reason to limit this to something so out of the way.
Ideally the RCD even gets more functionalities, like the ability to
print stock parts (or having stock parts removed), etc, in order to
lessen this burden.
## Changelog
🆑
add: Engineers now have an RCD round start.
balance: RCD construction/deconstruction effects can now be attacked in
order to cancel them. You can get the anti-disruption upgrade disk to
prevent this.
balance: RCD construction/deconstruction is now slower if you already
have another effect up. This does not effect reconstruction.
balance: Both of the above effects do not effect the CE's roundstart
RCD, nor any other RCDs such as combat RCDs.
/🆑
---------
Co-authored-by: Fikou <23585223+Fikou@users.noreply.github.com>
## About The Pull Request
What it says on the tin. This may seem anal but it really helps with
reducing diffs in downsteams when they need to add things.
## Changelog
Absolutely nothing player facing
## About The Pull Request
- Removed the `category` var from all plumbing machinery, now all the
designs are organized by category in a single static list(1 list for
each plumbing rcd type). This makes it easy to add new designs to 1 list
in the future and since the list is static memory is saved when multiple
plumbing RCDs are made in game
- Removed redundant `machinery_data` list. This list simply stored the
cost of designs from the `plumbing_designs` list. Rather than wasting
memory with this list we can derive the cost from `plumbing_designs`
list ourselves
- Removed unused list `choices`. No idea what that did back then
- When low on ammo the plumbing RCD would display multiple balloon
alerts. That's fixed now
- Made the icon sizes of designs in the UI slightly smaller so they
don't clip and look blurry
## Changelog
🆑
fix: multiple balloon alerts when the plumbing RCD is low on ammo
code: organized all plumbing designs into static lists for memory
savings
refactor: removed unused vars for further memory savings
/🆑
## About The Pull Request
What it says on the tin. Some machines, like the plumbing IV, could not
be deconstructed because they were not `/obj/machine/plumbing` subtypes.
It now simply checks whether the item we're attacking is one of our
designs and, if so, deconstructs it.
Additionally made the plumbing IV not drop metal when deconstructed for
the sake of consistency. I'd say it's a fix, because it seems like an
oversight, but if you'd like to label it as balance just tell me.
## Why It's Good For The Game
Fixes#77507 and avoids any similar issues in the future.
As mentioned, the removal of the metal is just for consistency. It
inherits it from the base IV type when, in my mind, it should behave
like a plumbing machine.
## Changelog
🆑
fix: Plumbing Constructors can now deconstruct every machine they can
make, including the plumbing IV.
fix: Plumbing IV drips no longer drop metal when deconstructed
/🆑
## About The Pull Request
1. Fixes#77177
Some things were not connecting to the ore silo round start because the
silo was not initialized yet so it went to local storage. Now it
connects with the ore silo again
3. Removed some unused code in remote materials
4. Protolathe uses `eject_sheets()` defined in remote materials and not
it's own version because that's redundant
5. Don't put the item back in the players hand when inserting it in the
material container cause we haven't even removed it yet
6. `fast_split()` is now even faster & robust and is a global proc
7. Some code cleanup for RHD silo link
## Changelog
🆑
fix: some things not connecting to the ore silo round start
/🆑
## About The Pull Request
Replaces a ton of `turn(dir, 180)` calls with the aforementioned macro.
## Why It's Good For The Game
Afaik, `REVERSE_DIR` was coded to be faster than the classic `turn(dir,
180)` call, being a simple set of binary operations. To sum it up, micro
optimization.
## Changelog
N/A
## About The Pull Request
**1. Material container clean-up & refactor**
- Replaced `total_amount` var with `total_amount()` proc, this var can
be easily computed by summing up all material amounts rather than
storing it as a var which is tedious to update & keep track of when
materials are added/removed
- Removed unused procs `transer_amt_to()`, `can_insert_amount_mat()`,
and `get_categories()`. These procs are not used anywhere in the
codebase so let's remove them & make some space.
- Callbacks are replaced with signals, the callbacks don't need to be
explicitly garbage collected & having macros & procs marked with
`SIGNAL_HANDLER` makes your intentions more readable & explicit.
- Fixes#76151
All material adding, removal, checking operations are "Integer"
operations, i.e. the final value is rounded & them made 1 if the final
value is 0 using the macro `OPTIMIZE_COST`[coudn't come up with a better
name]. No more dealing with decimal value materials
The problem was after the protolathe was upgraded with better parts all
the design costs were multiplied with a decimal `efficiency_coeff`
value, this means even though in the UI the cost was displayed as 60
bluespace crystals its actual cost was `60.0001` something in the
backend causing this check for materials to fail & print the error
message.
- Replaced `GetComponent(/datum/component_material_container)` with just
a simple ref to the material container when adding the component, so we
can save some overhead from calling this proc
- Gave all procs a ton of documentation with documentation having
documentation
- Fixes#76506 RCD and other devices that uses the silo link upgrade now
have the correct material usages
- Fixes#72096. It wasn't just a problem with ancient protolathe but
with all machines that used `datum/component/remote_materials` the
problem was remote materials would add an instance of
`datum/remote/material_container` if it wanted to use local storage but
this component would get added before `datum/component/remote_materials`
could be registered i.e. it comes before remote_materials in the
component list. So when the machine is destroyed it will first destroy
`material_container` & then `remote_materials` therefore destroying the
materials before they could get ejected
- Silo link is established when parent is registered with remote
materials raher than adding an external timer which is faster
- Everything that uses a material container will auto eject their sheets
when destroyed
- Moved this & remote materials into its own folder for better
organization
**2. Material UI Changes**
- Removed the x25 & x50 print buttons from the autolathe, now they just
have x5 & x10 buttons like the protolathe, These buttons were of no use
since you could just type the exact amount you want to print in the
`[Max: <some amount>]` side bar. The code to compute these buttons was
just plain right nasty & some of it unused in the UI.
- The material eject button in the material bar does not gray out when
you can eject exactly one sheet
- All material cost are integer values rounded
- Fixes#76253 Exosuit Fabricator sends the material container static
data to the UI so its material bar is not greyed out when there are
sufficient materials to eject
- Component printer material bar sends the material container static
data to the UI so its material bar is not greyed out when there are
sufficient materials to eject
- Autolathe Material bars now display number of sheets available
- Max printable amount of items are now computed & updated correctly in
the UI. They were displaying wrong values & now get updated when items
are printed, materials are removed
- Silo hold actually works now. When a machine is put on hold it calls
this proc
e929cf39cd/code/datums/components/remote_materials.dm (L78-L87)
Notice how the key is `src` so we should be consistent during checking
if a machine is on hold using the same `src` var. But for some reason we
did dumb shit like this
e929cf39cd/code/datums/components/remote_materials.dm (L150-L153)
What is category? Why do we care for the area the machine is in? None of
it made sense so i removed all that junk and just made it check for
`src` like it should
- Removed redundant `removable` & `sheets` var from the material
container ui_data. These vars are unused in the UI
- If an item does not have the required materials then upon clicking
that item you will not get any error message but instead nothing happens
## Changelog
🆑
fix: items can be printed from autolathe & protolathe when the exact
material amounts are present in them after upgrading
fix: max printable amount now shows the correct value & updates when
items are printed, materials are removed in the autolathe & protolathe
fix: component printer material bar is not greyed out when there are
sufficient materials to eject
fix: rcd and other devices that uses the silo link upgrade now have the
correct material usages
fix: silo hold actually works
fix: machines using local storage to hold materials will eject it's
materials as sheets when deconstructed/destroyed
refactor: Autolathe Material bars now display number of sheets available
refactor: printing an item that does not have enough materials will fail
silently with no error messages
refactor: Drone dispenser will eject sheets upon deconstruction
refactor: all things that store materials will auto ejects its sheets(if
there is sufficient material) when destroyed
refactor: inserting an item into the material container will display the
units consumed as sheets not absolute units
refactor: removed x25 & x50 print buttons from the autolathe
## About The Pull Request
New malf AI upgrade
Remote safety overrides: Mid-cost, Mid-supply. Allows the AI to remotely
emag things it can see and can access.
1. Very useful for psychological warfare (Emagging APCs to throw the
crew off their trail)
2. Logically makes sense - why, of all things, can the AI not emag
anything when it's fundumentally integrated with the station's
electronics?
3. Generally speaking can only access things that make sense for it to
access - it cannot emag ethereals, sadly
In order for this to work, emag_act now returns a boolean, designating
if the emag had any effect.
While I was in there, I also added args to every single emag_act I could
find and added far more feedback/converted a lot of things to balloon
alerts to allow the AI to see if its emag had any effect.
## Why It's Good For The Game
It just makes sense that the AI, the most electronically-sensitive
entity in the game, would be able to emag things. Plus, more options
given to malf that aren't strictly MURDER KILL MURDER are always a plus,
especially if they allow for fancier plays.
## Changelog
🆑
add: New malf ability: Remote safety overrides. Allows the AI to
remotely emag things it has access to.
code: emag_act() now returns a boolean designating it's success in
emagging
code: All instances of emag_act() now have the proper arguments
qol: Most usecases of emagging now have some kind of feedback, and
existing feedback has been sanity checked and converted to balloon
alerts.
/🆑
## About The Pull Request
Further continous organizing and cleaning the Icons folder. There are
still some minior nitpicks left to do, but I reached my daily sanity
expenses limit again, and the faster these get in the less issues for
both me and others later. Also cleans some mess I caused by my blindness
last PR.
## Why It's Good For The Game
Saner spriters = better sprites
## About The Pull Request
rcd can make girders at half the cost of making a wall in 1.3 seconds
## Why It's Good For The Game
more "rapid" than using iron for girders and putting whatever material
on it
## Changelog
🆑
add: rcd can make girders now
/🆑
## About The Pull Request
Fixes mousewheel changing the selected piping layer when the RCD is
in-hands, but not in the active hand.
Also dmdocs, changes some var names, grammar checks some stuff and adds
balloon alerts when installing the wrench upgrade and reprogramming a
pipe.
Removes `activate()` proc that was just a `playsound()`, makes the sound
used for that a define here so it's obvious why's the sound being played
## Why It's Good For The Game
Closes#54844 (it was fixed at some point actually so you couldn't
mousewheel to change layers on an RPD on your belt slot, but the in-hand
inconsistency remained)
Code's a little cleaner
Installing an upgrade's a little more obvious
## Changelog
🆑
fix: fixed RPD switching layers on mousescroll when not in active hand
qol: installing an RPD wrench upgrade & reprogramming a pipe via RMB
produces a balloon alert
/🆑
## About The Pull Request
**1. Craftable & Removed from RPD UI**
1. Air sensor's are now craftable
2. You can turn them on/off with hand. Even though turning off the
sensor will change it to a diffrent type[from `obj/machinery/air_sensor`
-> `obj/item/air_sensor`] it's I/O port's are sill preserved when
turning them on although you have to assign it a new name again which is
usefull if you want to change the sensor's purpose in game.
3. They can now only be deconstructed by a welding tool and should be
wrenched in place to turn them on.
4. Turned off air sensor's once unwrenched can be picked up like any
regular item
5. Air sensor's are removed from the RPD UI because they don't go with
pipes so it logically doesn't make sense to group them with pipe related
device's
Removed unused code in the process
https://github.com/tgstation/tgstation/assets/110812394/3439a0f3-9c48-43ac-8f4b-98135435ec13
**2. New ID System**
The problem with air sensor's is that each sensor is assigned a unique
ID which is then stored in `GLOB.objects_by_id_tag` list. Each sensor
name it's assigned based on the gas it's trying to sense(for naming only
even though it can detect other gases) So if 2 sensor's having the same
ID are made they will overwrite each other in this list leaving one
sensor orphaned in the world which cannot be referenced because it's
value was overwritten by a new sensor having the same ID in this list.
The Solution? Rather than having all atmos computer's look up sensor's
from this 1 global list make each computer keep track of all sensor's
it's responsible for in it's own local list[which i called
`connected_sensor's`] this way 2 sensor's can have randomly generated
names in the global `GLOB.objects_by_id_tag` list but the computer will
know what sensor to look up in this list based on the stored sensor ID's
in the `connected_sensor's` list
Basically what i am getting at is now you can make as many air sensor's
as you wish but you will know have to connect that sensor to the
computer using a multitool.
Notice in the video how i made 2 sensor's called `Supermatter Chamber
Sensor's`] and every time you try to connect an sensor which has the
same name[`Supermatter Chamber Sensor's` in this case] they will
ovewrite the old sensor in it's list as shown in the video
https://github.com/tgstation/tgstation/assets/110812394/b5283c3b-c8a1-4b94-a6a8-8ba7a0007615
**Why it's good for the game**
I agree. Also air sensor's taking up a full Tab/Section in the RPD UI
wasted a lot of UI space so that's removed now. Also making the air
sensor's wrenchable and pickable item's was also requested in
https://github.com/tgstation/tgstation/pull/72019#issuecomment-1355499873
so you relate them to device's like meter's
Another huge issue was that the number of air sensor's you can make in
the world was limited because each sensor in the world must have a
unique ID but that's finally fixed now so yeah make as many sensor's as
you want.
## Changelog
🆑
add: air sensor's are craftable
refactor: air sensor's can now be turned off by hand and can only be
deconstructed by a welding tool
refactor: removed `Params()` proc
qol: unwrenched air sensors can be picked up & recycled like regular
item's
del: air sensor are removed from the RPD UI
qol: air sensor's are no longer restricted by their unique ID's which
mean you can craft as many air sensors as you want.
/🆑
---------
Co-authored-by: Time-Green <timkoster1@hotmail.com>
## About The Pull Request
The recent changes were aimed at better UX, yet there were reports about
their flaws.
This PR should address some of the concerns.
The Devices tab was reduced, creating a new tab for Pumps and Valves,
called "Binary" (perfect timing for such tab 🤭) No scrolling required
now.
Also moved options to the left side for less mouse movements and
consistency with RCD and Plumbing RCD.
## Why It's Good For The Game
Better UI according to feedback from the main users - atmos techs.
## Changelog
🆑
qol: RPD UI: Devices split in two categories, options are aligned to the
left
/🆑
Safeguards against #74965 happening in the future.
Noticed a bunch of these were using ITEM_SLOT_HANDS. This is incorrect,
as the element already automatically updates held items. grep'd it to
catch future instances.
Likewise, a number of objects weren't passing slot_flags to the element,
meaning it wasn't actually updating those things properly when they were
being worn. I've simplified this so now the element will automatically
update all slot_flags, and passing an additional slot to the element
when being added is only needed for additional slots that might need to
be updated. This also means if slot_flags change, the element will now
update correctly as well.
🆑 ShizCalev
code: The update_icon_updates_onmob element will now automatically
update all slots in an item's slot_flags var. This does fix multiple
things that weren't updating properly. Passing a slot to the element is
now only necessary if you want to add additional slots to be updated.
/🆑
