## 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
/🆑
## About The Pull Request
Introduces a new MODule in the uplink, makes the user transperent and
grants the ability to siphon light sources to recharge your suit.
Ingame demonstration: https://www.youtube.com/watch?v=bhXNOAMDy4U
## Why It's Good For The Game
I've been playing a ton of Splinter Cell and Intravenous recently and
this random idea popped in my head.
"Wouldn't it be cool if traitors could blend in the darkness to get a
jump on their opponents?"
Also unrelated
"Wouldn't it be cool if tots had a tool to recharge their suit that
didn't involve sitting in a pod for 10 minutes?"
This PR introduces a new module to the uplink, the Wraith.
It comes with a passive and active component.
Passively it works exactly like the crew version of the cloaking module
with just a couple of differences.
1) Doesn't need to be manually activated, if you lose the cloak it's
regained after 5 seconds.
2) Lower stealth alpha value( how trasperent you are basically),
slightly less visible than the crew version, not as good the ninja
module however , I tuned it just enough so that you are more or less
undetectable in the dark.
The active component of the module lets you destroy stationary lights to
recharge your suit power, if used on handheld or borg lights it turns
them off for a minute.
**Why do we need this module when we already have the stealth implant
and the chameleon projector?**
I can think of a few reasons.
1) MODsuits were designed to be customizible, traitor suits range
between 6 to 16 TC, having to invest in a 7-8 TC item after you already
bought a suit is fairly expensive.
2) This MODule would be a better fit for ambushes, as it doesn't have
the *uncloaking* delay of its counterparts.
It is however considerably worse if you get caught, as the cloak is
disrupted on bump or damage.
3) It has better interactions with the sandbox.
Lights can go out for many reasons, maybe it’s just a power outage, or
some assistant broke it, or maybe it was anightmare.
It leaves room for plausible deniability, adding to the paranoia.
It's also not complete invisibility, if you want to stay undetected you
need to lurk in the darkness, you might expand your domain, at the cost
of the crew eventually wising up to your shaeneningans.
Lastly, since the active component of the module uses the same proc of
the saboteur handgun, I've updated the code to be a generic proc rather
than a signal, to make it easier to reuse in the future.
Item desc provided by NecromancerAnne.
Module sprite made by Orcacora.
## Changelog
🆑
add: The Wraith Cloaking Module is now available in the uplink, costs 3
TC.
code: the saboteur handgun now uses a generic proc rather than a signal
/🆑
---------
Co-authored-by: Xander3359 <66163761+Xander3359@users.noreply.github.com>
Co-authored-by: Ghom <42542238+Ghommie@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
it's - conjunction of "it" and "is"
its - possessive form of "it"
grammar is hard, and there were a lot of places where "it's" was used
where it shouldn't have been. i went and painstakingly searched the
entire repository for these instances, spending a few hours on it. i
completely ignored the changelog archive, and i may have missed some
outliers. most player-facing ones should be corrected, though
## Why It's Good For The Game
proper grammar is good
## Changelog
🆑
spellcheck: Numerous instances of "it's" have been properly replaced
with "its"
/🆑
## 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
Sooooooooo I was recently notified of an issue (#84185) that popped up
from me replacing the `attackby(...)` chain on id cards, where it's no
longer possible to put money into IDs inside of PDAs by slapping it
against the PDA.
As I expected, this is because modular computers both still use
`attackby(...)`, and would call `attackby(...)` on the ID they contained
if hit with cash.
24a23009e8/code/modules/modular_computers/computers/item/computer.dm (L799)
Now this could've been an easy one line no-gbp fix where I just replace
it with a direct call to `insert_money(...)` on the ID and call it a
day!
But hey. Might as well get rid of the `attackby(...)` altogether while
we're at it.
First off, because the `attackby(...)` proc was getting quite bloated,
we split off all the specific item behaviours into `[X]_act(...)` type
procs to clean it up.
We then make those return item interaction flags, so we can call them on
`item_interaction(...)` after the right typecheck passes and immediately
return their results.
This also involves replacing the `application_attackby(...)` on
applications with an `application_item_interaction(...)`, and making it
return the item interaction flags too.
The code of each subsection isn't significantly different, though
reorganized a bit in some cases.
Like inserting a computer disks now tries to move it into the computer
_first_ before swapping out whichever disk is already in there, so it
doesn't swap out the disk if putting the new one in fails.
## Why It's Good For The Game
Fixes#84185.
Having more stuff be updated to the proper `item_interaction(...)`
system is cool and good.
## About The Pull Request
Made the NT Frontier app look for valid experiment files not only on the
local file system, but also on the data disk.
## Why It's Good For The Game
Less clicks.
## Changelog
🆑
qol: NT Frontier app now allows to select experiments from inserted data
disks
/🆑
## About The Pull Request
Same idea as #82656 but for ctrl click & ctrl shift click cause why not
- Does your signal & `can_perform_action()` checks using
`interaction_flags_click` flags before delegating the event down to
`ctrl_click()` proc.
- The one new change now is that `ctrl_click()` proc is now blocking,
meaning returning `CLICK_ACTION_SUCCESS` or `CLICK_ACTION_BLOCKING` will
stop the object from getting grabbed/pulled. So remember to return these
values if you want to stop the grab action or return `NONE` if you want
to process the click but still want the object to get grabbed as well
## Changelog
🆑
refactor: Ctrl click & Ctrl shift click has been refactored. Please
report bugs on GitHub
/🆑
## About The Pull Request
Mouse drag & drop has been refactored into its own attack chain. The
flowchart below summarizes it
Brief summary of each proc is as follows
**1. `atom/MouseDrop()`**
- It is now non overridable. No subtype should ever touch this proc
because it performs 2 basic checks
a) Measures the time between mouse down & mouse release. If its less
than `LENIENCY_TIME`(0.1 seconds) then the operation is not considered a
drag but a simple click
b) Measures the distance squared between the drag start & end point. If
its less than `LENIENCY_DISTANCE`(16 pixels screen space) then the drag
is considered too small and is discarded
- These 2 sanity checks for drag & drop are applied across all
operations without fail
**2. `atom/base_mouse_drop_handler()`**
- This is where atoms handle mouse drag & drop inside the world. Ideally
it is non overridable in most cases because it also performs 2 checks
- Is the dragged object & the drop target adjacent to the player?.
Screen elements always return true for this case
- Additional checks can be enforced by `can_perform_action()` done only
on the dragged object. It uses the combined flags of
`interaction_flags_mouse_drop` for both the dragged object & drop target
to determine if the operation is feasible.
We do this only on the dragged object because if both the dragged object
& drop target are adjacent to the player then `can_perform_action()`
will return the same results when done on either object so it makes no
difference.
Checks can be bypassed via the `IGNORE_MOUSE_DROP_CHECKS` which is used
by huds & screen elements or in case you want to implement your own
unique checks
**3. `atom/mouse_drop_dragged()`**
- Called on the object that is being dragged, drop target passed here as
well, subtypes do their stuff here
- `COMSIG_MOUSEDROP_ONTO` is sent afterwards. It does not require
subtypes to call their parent proc
**4. `atom/mouse_drop_receive()`**
- Called on the drop target that is receiving the dragged object,
subtypes do their stuff here
- `COMSIG_MOUSEDROPPED_ONTO` is sent afterwards. It does not require
subtypes to call their parent proc
## Why It's Good For The Game
Implements basic sanity checks across all drag & drop operations. Allows
us to reduce code like this
8c8311e624/code/game/machinery/dna_scanner.dm (L144-L145)
Into this
```
if(!iscarbon(target))
return
```
I'm tired of seeing this code pattern `!Adjacent(user) ||
!user.Adjacent(target)` copy pasted all over the place. Let's just write
that at the atom level & be done with it
## Changelog
🆑
refactor: Mouse drag & drop attack chain has been refactored. Report any
bugs on GitHub
fix: You cannot close the cryo tube on yourself with Alt click like
before
/🆑
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com>
## About The Pull Request
This PR makes the computer console's print feature work on a signal
instead of wasting paper every string update, changes the flashlight
color change to do the same, fixes the on/off signal not turning the
console on, and fixes the signal for the console turning off not
functioning.
## Why It's Good For The Game
Besides the bug fixes, this makes the console components more consistent
with every other circuit component. The refactor is to prevent worrying
about nulls for colors or errors because of early returns.
## Changelog
🆑
fix: computers with no lights can now turn on using the on/off signal
fix: RGB lights on PDA circuits now use a signal
fix: the is_off signal now works on consoles
fix: printing text on a console component now uses a signal
refactor: each input signal in console circuits now have their own proc
/🆑
## About The Pull Request
This adds a span notice on examine to PDAs containing a power cell that
the cell can be removed by right clicking
Discussed this morning in coder general:
* Lots of functions have been moved to PDAs, but their batteries deplete
obnoxiously quickly
* Dedicated PDA chargers are not wanted per Mothblocks, and would be map
clutter
* Existing rechargers cannot be made more available because they
recharge guns, but are the only 'obvious' way to recharge PDAs.
* PDA batteries can actually be removed and externally recharged - but
there is nothing in game telling players this.
* There is also nothing on the wiki telling players this.
* Left click w/ screwdriver = nothing, but right click removes cell is
completely non-intuitive and inconsistent with all other tool use.
## Why It's Good For The Game
Actually telling players about an interaction is good and the
description of this PR is already longer than the code change.
## Changelog
🆑
fix: On examine PDAs will now inform players that the power cell can be
removed for recharging or replacement, and how to do so.
/🆑
## 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
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
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
Refactors a lot of the unused defines.
## Why It's Good For The Game
Refactors a lot of the unused defines.
## Changelog
Nothing player facing
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
This PR does many things, I'll try to explain the basic/background stuff
to the main thing first:
1. Adds a new remote that allows a human to function like an AI. It
controls a fly that will fly around the station slowly, and when it
reaches a machine then the person can interact with it as if they were
an AI. This required changing a lot of silicon/AI checks with one that
also checks for this remote, and some messing with shared ui state.
2. Moves req_access from the obj and bot to ``/atom/movable`` which lets
it be shared between the two, no more copy-paste and one side lacking
features/checks/signals the other has.
3. Adds a check for AI config for AI-related station traits, which was
lacking prior
Now for the good part...
Adds a new station trait that replaces the AI with a Human.
This person is equipped with an AI headset (including Binary), an
advanced camera console, an omni door wand, the machine controller, and
their laws.
They are immune to the SAT's turrets (even if set to target borgs) and
are slow outside of the SAT, mimicing the actions of the AI.
They interact with the world through their advanced camera console,
which allows them to do most AI stuff needed, and the holopad they can
connect to without having to ring first (like Command can).
They are given a paper with the laws they must follow, but since they
are human they are able to bend it. Cyborgs that run the default lawset
are "slaved" to them via an unremovable law 0, so the Human AI can bend
the laws if they really need to (for their own survival n such), and
make the cyborgs obey their commands above laws, but in general this
shouldn't be a frequent occurrence. This does take into account the
unique AI trait, so it's not guaranteed Asimov.
When this station trait rolls, all Intellicards, AI uploads, and AI core
boards are destroyed and are unresearchable. They can be spawned by
admins in-game if necessary. Maybe in the future we can also exclude
Oldstation from this but I haven't really decided.
Extra perks:
Human AI spawns with a Robotic voicebox (unless they are a body purist)
and teleport blocking implant, so they can't use teleporters to bypass
their on-station slowdown.
They also have an infinite laser pointer that can be used to blind
through their camera console. This is unfortunately nerfed from the
recent borg balance PR that removed its stun. This was meant to be the
alternative to no longer being able to permanently lock borgs down like
AIs can (or more than one, for that matter).
They aren't affected by Roburgers, Acid, and Fuel's toxicity.
Bots salute them like they do Beepsky (which is now a trait)
They spawn with SyndEye to replace the AI's tracking ability
They do not have a bank account
### The machine remote
The machine remote has a little fly in it that flies to the machines it
is pointed to, working as the arms and legs of the Human AI. It scans
the machine and punches in the action the AI does, and is how the AI
accesses basically anything. This fly slowly moves from one machine to
the next, and can be recalled with Alt Click.
It works on machines and bots.
### Video (Low quality to fit Github)
https://github.com/tgstation/tgstation/assets/53777086/e16509f8-8bed-42b5-9fbf-7e37165a11e8
## Why It's Good For The Game
I've seen a funny screenshot one day of a person replacing the AI by
using a bunch of door remotes, camera console, crew monitoring console,
and a few other things. I've been thinking about that for a few years
and really wanted to make it official if not easier to make possible,
because it is an incredibly funny interaction.
This makes it a reality, and while they aren't as powerful as regular
AIs, I think it makes for better and funnier in-game moments. With the
same weight as Cargorilla (1), I hope this wouldn't be rolling too often
and ruin rounds, but instead show off the different capabilities that
Humans and AIs can do, to do the job of an AI. You win some you lose
some.
## Changelog
🆑 JohnFulpWillard, Tattax
add: Adds a new station trait job: The Human AI.
/🆑
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
## About The Pull Request
[Fixes static lights not
moving](ffef43c05a)
Worked fine when the owner moved, but if the owner was inside something
else, it would try and trigger an update on the PARENT's lights, which
are obviously not us.
[Renames MOVABLE_LIGHT and STATIC_LIGHT to better describe what they
do](de73a63bd4)
People keep trying to change the lighting system of lamps and it makes
me mad.
I choose OVERLAY_LIGHT and COMPLEX_LIGHT here, I couldn't figure out a
better name for turf matrix lighting. Suggestions welcome
## Why It's Good For The Game
Closes#80005
Hopefully improves understanding of lighting at a glance
## Changelog
🆑
fix: Fixes fancy lights not updating their source location when picked
up and moved
/🆑
## About The Pull Request
It turns out the messenger circuit wasn't working as intended, because
list components tend to convert datum keys into weakrefs, creating
incoherence between composite datum/atom and simple datum/atom
datatypes, which at least just spares us from the headache of clearing
the refs on del from lists too.
So, taking the shortest path, I decided to adapt the messenger to the
weak ref usage.
Another thing, instead of refusing altogether to send message that
trigger the pda filter regexes, the messenger circuit will instead
replace the matches with grawlix, since we have no way to inform
whoever's responsible for said message about the filters in an orthodox
way.
Beside that, I've noticed several of the circuits from my PR were
lacking trigger outputs or similar when needed, pretty making them only
as half as functional, at least to a noob like me.
And another small issue with missing ports from the status display
circuit.
One more suggestion from moocow is to add a cooldown to the ringtone
trigger for the messenger circuit, because he said it's pretty spammy
and some admins are fickle.
## Why It's Good For The Game
Bugfixing and improvements.
## Changelog
🆑
fix: Fixed the messenger circuit not sending messages.
fix: Added several ports to modpc circuits that were missing or needing
them.
fix: Fixes ever-expanding ports whenever circuits are re-inserted in a
modular computer.
/🆑
## About The Pull Request
I had made the bad assumption that a pAI card always had a pAI mob in
it, which is not the case.
This fixes the runtime error, thus allowing people to eject a pAI card
that doesn't have a pAI in it.
I've also added a check in the pAI's Initialize to give them the ability
to use the modPC if they are made in it, so you don't have to eject and
reinsert the pAI, fixing another issue.
## Why It's Good For The Game
Closes https://github.com/tgstation/tgstation/issues/81043
Fixes inconsistency and runtime.
## Changelog
🆑
fix: pAIs downloaded while in a PDA now gets the action button to
control said PDA.
fix: pAI cards can now be ejected from a PDA when there is no pAI
inhabiting it.
/🆑
## About The Pull Request
This PR integrates circuits for modular computers and a good bits of
their programs.
The peculiarity here is that modular computers have no fixed amount of
unremovable components (except the base one with just a couple ports for
now), instead, they're added and removed along with programs. With a few
exceptions (such as the messenger and signaler), for these program
circuits to work, their associated program has to be either open or in
the background.
For a reason or another, not all programs have a circuit associated to
them, still, however the programs with a circuit are still a handful.
They are:
- Nanotrasen Pay System
- Notepad
- SiliConnect
- WireCarp
- MODsuit Control
- Spectre Meter
- Direct Messenger*
- LifeConnect
- Custodial Locator
- Fission360
- Camera
- Status Display
- SignalCommander
*By the by, sending messages has a cooldown, so it shouldn't be as
spammy. If it turns out to not be enough, I can make it so messages from
circuit will be ignored by other messenger circuits.
The PR is no longer WIP.
## Why It's Good For The Game
I believe modular computers could make for some interesting setups with
circuits, since they're fairly flexible and stocked with features unlike
many other appliances, therefore also a speck more abusable, though
limits, cooldowns, logging and sanitization have been implemented to
keep it in check.
## Changelog
🆑
add: Modular Computers now support integrated circuits. What can be done
with them depends on the programs installed and whether they're running
(open or background).
add: Modular Consoles (the machinery) now have a small backup cell they
draw power from if the power goes out.
/🆑
## About The Pull Request
This PR adds in a new app that scans the nearby area for "spookiness"
(e.g. presence of ghosts, mobs with the spirit biotype, objects made
with hauntium or containing hauntium). A bit clunky by all means. It's a
maintenance app, and as such is more often found in the rare maintenance
computer disks, or downloadable from emagged PDAs (IIRC), or perhaps the
black market item which I've also added here as well, that might contain
it amongst other things.
Oh, if you also have the camera app, it'll let you take pictures of
ghosts like the 'camera obscura' does.
Oh, and there's also a maintenance version of the arcade program too;
just , like, lazier and easier.
## Why It's Good For The Game
Mostly a shower thought, 'cause I felt the idea maintenance disks to be
quite interesting yet lackluster, almost too niche. As for the remote
thought of using the app for validhunting, it isn't something you can
reliably get every and every other round, and if someone's got enough
ghosts circling them, chances are they're some big, loud antag or doing
something so cheeky, that they kinda deserve it.
Also, yeah, more black market stuff. Except for the misc section, it's
pretty lacking in uniqueness.
Screenshot of the UI, taken at the distance of one tile from a revenant:
## Changelog
🆑
add: The Spectre-Meter modular computer app. A little, amatuerishly
coded app that, as the name implies, scan an area for spectral presence.
It can be found amongst other apps in maintenance computer disks.
add: An easier, lazier version of the Arcade app, also found in
maintenance.
add: Black market computer disks, which contains programs not readily
available to the average assistant.
/🆑
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
## About The Pull Request
This is an update that touches many more things all at once (compared to
my other PRs) meant to make PDAs in general feel more consistent and not
take away from one of the experiences we want to encourage: interaction
between players.
1. Replaced all checks of a 'pda' with a 'modular pc'. This means
technically (though not done in-game currently) other modpcs can hold an
uplink, and microwaves can charge laptops.
2. Speaking of microwave, they now don't break and require
deconstruction if the cell is removed mid-charge.
3. When a Mod PC is out of power, it will now allow the Messenger to
work (which now also doesn't consume any additional power), if the app
exists on the PC. Here's a video demonstration
https://github.com/tgstation/tgstation/assets/53777086/7ae12f81-a271-49b8-95fa-2ba54d2e2d1f
4. Flashlights can't be turned on while the cell is dead
5. I replaced a bunch of program vars with ``program_flags`` and renamed
``usage_flags`` to ``can_run_on_flags``.
6. Added a debug modPC that has every app installed by default. Mafia
had some issues in the past that were unknown because Mafia wasn't
preinstalled with any tablet so was never in create & destroy nor in any
other unit test. This was just an easy solution I had, but PDAs should
get more in-depth unit tests in the future for running apps n stuff- I
just wanted to make sure no other apps were broken/harddeling.
## Why It's Good For The Game
Currently when a PDA dies, its only use is to reply to PDA messages sent
to you, since you can still reply to them. Instead of just fixing it and
telling players to cope, I thought it would be nice to allow PDA
Messenger to still work, as it is a vital app.
You can call it some emergency power mode or whatever, I don't really
mind the reason behind why it is this way.
When I made cells used more on PDAs, my main goal was to encourage
upgrading your PDA and/or limiting how many apps you use at once, I did
not want this to hit on players who use it as a form of interaction.
This is the best of both worlds, I think.
The rest of the changes is just for modularity, if some downstream wants
to add tablets, phone computers, or whatever the hell else, they can
still get just as far as PDAs should be able to get to, hopefully.
## Changelog
🆑
add: PDAs with a dead power cell are now limited to using their
Messenger app.
fix: Microwaves now stop charging PDAs if the cell was removed
mid-charge.
fix: Microwaves can now charge laptops.
fix: PDA Flashlights can't be turned on while the PDA is dead.
fix: You can now hold a laptop up to a camera (if it has a notekeeper
app installed) like PDAs already could.
/🆑
---------
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
## About The Pull Request
Implements half of this (with some minor changes):
The ultimate goal of this is to split our attack chain in two:
- One for non-combat item interactions
- Health analyzer scanning
- using tools on stuff
- surgery
- Niche other interactions
- One for combat attacking
- Item hit thing, item deal damage.
- Special effects on attack would go here.
This PR begins this by broadining tool act into item interact.
Item interact is a catch-all proc ran at the beginning of attack chain,
before `pre_attack` and such, that handles the first part of the chain.
This allows us to easily catch item interaction and cancel the attack
part of the chain by using deliberate bitflag return values, rather than
`TRUE` / `FALSE`*.
*Because right now, `TRUE` = `cancel attack`, no matter what, which is
unclear to people.
Instead of moving as much as possible to the new proc in this PR, I
started by doing some easy, obvious things. More things can be moved in
the future, or technically they don't even need to move in a lot of
cases.
## Changelog
🆑 Melbert
refactor: Refactored some methods of items interacting with other
objects or mobs, such as surgery and health analzyers. Report if
anything seems wrong
/🆑
This flag only worked on the `/obj/structure` and `/obj/machinery`
level, so let's rescope it from `flags_1` and put it where it belongs -
`obj_flags`.
Bitflag operators should be scoped to their subtype specific bitfield,
not really useful to have this take up a spot on the `/atom` level if
absolutely nothing other than `/obj`s use it.
## About The Pull Request
I've stumbled across this enough to finally go through the entire
codebase and fix it. I left out changelogs simply because rewriting
history logs is bad.
## Why It's Good For The Game
I find it pretty annoying because I stumble across words that are
misspelled for a few seconds, and I'm likely not the only one who feels
like this. Less spelling mistakes in code are better.
## Changelog
🆑
spellcheck: Occurrences of "recieve" has been changed to "receive".
/🆑
## About The Pull Request
I deleted the documentation file of ModPCs because it was barebones and
had no new information to give that autodoc couldn't. Just to make sure
this isn't a net-negative, I improved on much of the autodoc and
comments in general around ModPC code to help people understand easier
what's going on around it.
I also renamed vars that were too easily confused with other var names,
and reworked the ntnet downloader a little;
- it now has a search bar
- it now has more sections to scroll through, hopefully making it more
accurate and easy to find what you need.
- also organized the apps that were previously shoved in 'other'.
- i also upgraded it to a .tsx because why not
video demonstration
https://github.com/tgstation/tgstation/assets/53777086/cbba4c1c-b8a8-4ba4-8628-aea8389999fc
## Why It's Good For The Game
Adds in a lot of comments that were previously missing, clears up some
sources of confusion within ModPC code, and improves NTNet Downloader,
something I've procrastinated on doing for a very long time now.
## Changelog
🆑
qol: NTNet Downloader now has a search bar, and programs are now better
sorted.
/🆑
## About The Pull Request
Currently, every time you open/close a program, that activity is logged
for the RD to see. This includes Nukies opening their disk tracking app.
Now, emagged PDAs will no longer log activities to Wirecarp, but I did
replace it with a log when the PDA is first emagged.
Basically, nukies are undetected, but Traitors can still be figured out.
## Why It's Good For The Game
Closes https://github.com/tgstation/tgstation/issues/77201
I thought this would be better as it makes more sense to stop logging
when you're emagged, but as you are being emagged it will report the
modification instead.
## Changelog
🆑
fix: PDAs now log that they've been emagged, but will no longer log any
further programs they open beyond that. This means Nukies don't sell
themselves out by opening their disk tracking app.
/🆑
## About The Pull Request
Mafia is now friggin playable from the PDA, I also changed other stuff
too
- You can't use abilities on dead people if you're not supposed to (cant
kill the same person over and over)
- Changelings cant kill other Changelings
- Changelings can now only talk to eachother at night, rather than using
:j
- Everyone starts spawned in the center of the map, since people playing
on PDA can't move their characters. This is so everyone can hear PDA
users in person, as I don't want the chat log to be mandatory.
To do this, all messages you are meant to be able to see, is now logged
for you to see in your Mafia panel. This essentially means that people
playing through the PDA get a downgraded version of it, but I don't know
how much larger I want this UI to be.
Playing Mafia through the PDA will not tell you of other players ahead
of time when signing up (as it shows ckeys + pdas), but they can see the
names in-game. Unfortunately this means we'll have to remove your
customization coming with you, to prevent using it to tell who is dead
in round.
Things I am missing
- Program overlays on PDA/Laptop/Computer
- Icon for the app's header while a game is active
I'm not a spriter and can't make either of these
This is the new UI
I also fixed alert calls for PDAs and stuff
and removed the X at the top on computers since they had no battery
Looks a little better now hopefully 👍
## Why It's Good For The Game
- The current Arcade app sucks, and is a solo game. This is much more
entertaining and you can talk to others in it, which is swag as fuck.
- There's a larger potential playerbase for the Minigame making it more
likely to be played.
- Sets groundwork for a better version of
https://github.com/tgstation/tgstation/pull/75879
- Adds more suspense and teamwork in the minigame.
## Changelog
🆑 JohnFulpWillard, sprites by CoiledLamb
add: You can now play Mafia on your PDA.
balance: Mafia changelings can now only talk to eachother during the
night.
fix: Mafia abilities can't be repeatedly used on people.
/🆑
## About The Pull Request
So one aspect of PDAs that I quite liked previously was managing and
upgrading your power.
This was lost when all cell parts got removed, mostly, and now I'd like
to re-add it.
PDAs and Tablets now use more power each second it's on
Programs being active/idle now take charge too.
And all this now takes ``seconds_per_tick`` into account.
Screenshots of APC use before and after having 6 programs open at once
PDA default power cells have a max charge of 1000, each cell use is
around ``1.00970340315`` power, which is ``1.01013789399`` w/ 2 programs
in idle and 1 active program (which is what PDAs are capable of). This
means it takes about 990 ticks to fully drain your power, or about 50
minutes, at max use.
This is completely blasted away the moment you put anything beyond a t1
cell inside of it, which is unfortunate but what can you do about tiered
parts being so poor.
The problem of no public PDA chargers are alleviated by
https://github.com/tgstation/tgstation/pull/78600
### Update
The PDA flashlight being on now also drains the battery 25% times
faster. PDA running out of charge now also turns the flashlight off.
## Why It's Good For The Game
You may or may not have to actually charge your PDA once in a round now,
maybe. I liked this part of tablets and would like to see it brought
back, managing your power to use your apps is important to ensure you're
not just using all apps 24/7
Because this also adds the functionality to add/remove power cells
again, it opens up to some minor little pranks/messing with people that
isn't completely destroying their tools, as well as some minor
upgradeability.
## Changelog
🆑
balance: You can now remove and replace power cells from PDAs (with
screwdriver).
balance: PDAs now drain their power cells harder, and also take into
account active programs & their flashlight being on.
balance: PDAs running out of charge now turn their flashlights off.
/🆑
## About The Pull Request
As described in #78467, if an Intellicard is inserted into a laptop or
stationary modular computer, and said computer is destroyed, then the
Intellicard (as well as any AI on it) is instantly deleted. This PR
makes the Intellicard get dropped instead. Closes#78467.
## Why It's Good For The Game
Bugs are bad.
## Changelog
🆑
fix: Intellicards in computers are no longer deleted when the computer
is destroyed.
fix: Modular consoles can now be deconstructed by right clicking with a
wrench.
/🆑
## About The Pull Request
makes `COMSIG_HIT_BY_SABOTEUR` return a bitflag in order to close#78297
(i am very sorry)
fixes#78298
extends flashlight disabling to modular computers incl. PDAs because
somehow i forgot that they had flashlights.
## Why It's Good For The Game
my code sucks and i should make it suck less, actually
## Changelog
i don't think i get to put a code improvement tag if it's not
playerfacing and it's my own fault
🆑
fix: Flares and candles no longer sound like flashlights when being
turned on.
fix: Getting shot by an SC/FISHER now disables PDA lights for
consistency's sake.
/🆑
---------
Co-authored-by: Hatterhat <Hatterhat@users.noreply.github.com>
## About The Pull Request
This PR lets pAIs inserted into a PDA to control the PDA of their owner.
They can see their own pAI configurations but cannot edit any of it.
They also can't eject themselves from it.
This means they can receive and send PDA messages as their owner, acting
like a personal secretary
This also adds support for multiple people using a PDA and its UI
updating for all of them and PDA messages being received and responded
to from multiple people under the same PDA
It also removes pAI camera in favor of using siliconcamera, which is the
same thing; this just cuts down on some copy paste.
I also reverted PDA's ringer being off preventing messages from being
sent to your chat, silent mode was meant to prevent only the ringing
sound.
## Why It's Good For The Game
pAIs can now do a little bit more to help their owners on a personal
level, and adds support for more stuff like this in the future (an idea
I had was being able to hack into PDAs in the same way the CE can hack
into APCs remotely)
This is a re-PR of https://github.com/tgstation/tgstation/pull/76445 but
it's a little better this time and does not remove the PDA Messenger app
from pAIs.
## Changelog
🆑
fix: PDAs being on silent no longer prevents PDAs from being sent to
your chat, again.
add: pAIs inserted into a PDA can now control the PDA, and will receive
PDA messages sent to it (and can respond under the PDA's name).
/🆑
## About The Pull Request
Fixes a bug where borgs effectively break IDs when removing them from
modular consoles. Previously when they did this it would cause the ID to
be unretrievable.
## Why It's Good For The Game
Fixes a stinky bug!!
## Changelog
:cl:Sapphoqueer
fix: fixes a bug where borgs and TK users could effectively break ID's
by removing them from modular computers.
/🆑
## About The Pull Request
When you say "sent from my PDA" in messenger, if it's through a clear
PDA, it will instead say "Sent from my Crystal PDA". This is so the
recipient knows they are in the presence of a crystal pda.
## Why It's Good For The Game
Bragging rights for having a crystal PDA. Minor interaction I think
would be funny.
## Changelog
🆑
add: The 'Sent from my PDA' message is different for Clear PDAs now
(specifying they are crystal).
/🆑
## About The Pull Request
Removes all of the duplicate global lists for specific machine types
where the only thing they do is store all machines of that type.
Adds machine tracking to SSmachines in the form of a list for all
machines, and then an associative list for machines by their type.
Previously we have machines in multiple global lists, such as airlocks
being in GLOB.doors, GLOB.airlocks, GLOB.machines.
This makes that not a thing, and also means that iterating through
GLOB.machines looking for a specific type is no longer as expensive.
## 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
Remove welder fuel usage from all actions except attacking and leaving
it on
most welder tasks require a minimum of 1u of fuel, some longer tasks
require a minimum of 2 or 3u welders now drain 1u every 5 seconds
they're active
## About The Pull Request
Prior to this PR welder fuel usage was random, a lot of tasks didn't use
any welder fuel and welders were basically near infinite so long as you
didn't use them for combat, it took 26 seconds of activity to drain 1u
of fuel, that means an emergency welder alone could run for 5 minutes
straight before needing a refuel
After this PR all welders will drain 1u every 5 seconds instead of every
26 seconds, but welding objects won't require extra fuel anymore, making
the fuel usage much more consistent.
resolves#55018
## Why It's Good For The Game
Actually makes fuel tanks useful and relevant without making it
obnoxious to do repetitive quick tasks like turn rods into plates,
there's actually a reason to upgrade off the emergency welder now since
it lasts 50 seconds rather than 5 minutes
## Changelog
🆑
qol: Welders now have a more consistent fuel usage
/🆑
## About The Pull Request
Apps now properly delete themselves when removed, so they don't exist in
nullspace anymore.
Chat client now actually updates the uid, because its New() didn't call
parent.
Deletes the 'console' subtype of modular computer
Updates how downloading and transferring files are handled
Fixes being able to infinitely upload apps to a disk
## Why It's Good For The Game
Fixes some more bugs I found with apps and prevents spamming apps in a
disk.
## Changelog
🆑
fix: Maintenance data disks now properly transfer from PC to disk
fix: Disks can no longer be flooded with the same app repeatedly.
/🆑
## About The Pull Request
- Fixes background apps not reloading the UI
- Standardizes opening/closing/backgrounding apps
- Simplifies the way apps are closed instead of having 2 procs, one on
the PC and one on the program, being named the same thing (wtf)
- Removes program states. They existed so computers can know to update
their UI every process tick, but since we now do this event based, this
is no longer needed, which is good.
- Replaces the 'forced' arg from kill_program as it was completely
unused, with ``reload_ui``, which is now used to open the UI on close,
and not to when we don't want it to.
- Closing background apps no longer reloads the entire UI
- Responding to an NT Message will no longer open the UI on your face.
## Why It's Good For The Game
Closes https://github.com/tgstation/tgstation/issues/75046
Closes https://github.com/tgstation/tgstation/issues/75108
Makes tablet UIs more responsive and lag less, not checking if a program
is closed every process to close it, and makes responding to messages
not a hassle every time.
Also makes the code easier to understand/read,
## Changelog
🆑
fix: Tablets' minimize apps feature works again.
/🆑
## About The Pull Request
Tablet UIs are now changed when opening/closing an app, instead of
constantly checking for a UI change every ui update.
Program UI acts no longer call parent, as it was unnecessary, Computers
are the ones that should be calling it.
Fixes a ton of problems with static data not updating, such as in
Messenger, ID management, Siliconnect, and Chat client
Chat Client's Admin mode also works again, which was broken when
accesses to check was turned into a list.
Turns a few lists in Robocontrol into static ones when we aren't
changing anything, and makes it actually scan your ID's access.
Fixes budget ordering being unable to show the cart/call the cargo
shuttle.
## Why It's Good For The Game
While I can't seem to find a single issue report on any of the above,
these are still problems that should be fixed.
## Changelog
🆑
fix: SiliConnect can download borg logs again.
fix: The RD can once again enable Admin mode on Wirecarp
fix: NT IRN can once again see the shopping cart and call the cargo
shuttle.
fix: Chat Client, ID Management and Messenger should now update their
UIs properly.
code: PDAs will hopefully not lag as much when clicking on buttons (such
as in ID management).
/🆑
## About The Pull Request
Removes network_id as it was completely unused now.
Also reworks the maints access secret buttons to work with how accesses
work now, taking into account req_one_access. This is theoretically a
problem when we moved to req_one_access more often in maints so
departments can access their own maint areas.
## Why It's Good For The Game
This is just minor changes I found while trying to edit other things,
and thought I should PR it.
## Changelog
🆑
admin: Secret buttons for Engineering/Brig maint accesses should now
work more consistently.
/🆑
This tracks the seconds per tick of a subsystem, however note that it is
not completely accurate, as subsystems can be delayed, however it's
useful to have this number as a multiplier or ratio, so that if in
future someone changes the subsystem wait time code correctly adjusts
how fast it applies effects
regexes used
git grep --files-with-matches --name-only 'DT_PROB' | xargs -l sed -i
's/DT_PROB/SPT_PROB/g'
git grep --files-with-matches --name-only 'delta_time' | xargs -l sed -i
's/delta_time/seconds_per_tick/g'
## About The Pull Request
This PR makes it so that the access modification program now updates the
crew manifest once the inserted ID is ejected. Additionally, when the ID
trim is changed, the manifest is updated.
## Why It's Good For The Game
Demoted heads would still show up on the manifest as their job
pre-demotion, this fixes that.
## Changelog
🆑
fix: The crew manifest now properly updates after ID modifications.
/🆑
