## About The Pull Request
I was looking at sounds (as you do) and I noticed this
These sounds don't exist
We have `portal_open_1`, not `portal_open1`.
This wasn't caught on compile because they used `""` and not `''`.
So I went through and audited a bunch of playsound uses that don't use
`''`. Only one error, fortunately
Likewise there was a ton of places running `get_sfx` pointlessly
(because `playsound` does it for you) so I clened that up.
However while auditing the portal stuff I noticed a few oddities, so I
cleaned it up a bit.
Also also I added the portal sounds to the wormholes event and gave it a
free ™️ optimization because it was an in-world loop
## Changelog
🆑 Melbert
sound: Portals made by portal guns now make sounds as expected
sound: Wormholes from the wormhole event now make sounds when formed
/🆑
## About The Pull Request
- Afterattack is a very simple proc now: All it does is this, and all
it's used for is for having a convenient place to put effects an item
does after a successful attack (IE, the attack was not blocked)
- An overwhelming majority of afterattack implementations have been
moved to `interact_with_atom` or the new `ranged_interact_with_atom`
I have manually tested many of the refactored procs but there was 200+
so it's kinda hard
## Why It's Good For The Game
Afterattack is one of the worst parts of the attack chain, as it
simultaneously serves as a way of doing random interactions NOT AT ALL
related to attacks (despite the name) while ALSO serving as the defacto
way to do a ranged interaction with an item
This means careless coders (most of them) may throw stuff in afterattack
without realizing how wide reaching it is, which causes bugs. By making
two well defined, separate procs for handing adjacent vs ranged
interactions, it becomes WAY WAY WAY more easy to develop for.
If you want to do something when you click on something else and you're
adjacent, use `interact_with_atom`
If you want to do something when you click on something else and you're
not adjacent, use 'ranged_interact_with_atom`
This does result in some instances of boilerplate as shown here:
But I think it's acceptable, feel free to oppose if you don't I'm sure
we can think of another solution
~~Additionally it makes it easier to implement swing combat. That's a
bonus I guess~~
## Changelog
🆑 Melbert
refactor: Over 200 item interactions have been refactored to use a
newer, easier-to-use system. Report any oddities with using items on
other objects you may see (such as surgery, reagent containers like cups
and spray bottles, or construction devices), especially using something
at range (such as guns or chisels)
refactor: Item-On-Modsuit interactions have changed slightly. While on
combat mode, you will attempt to "use" the item on the suit instead of
inserting it into the suit's storage. This means being on combat mode
while the suit's panel is open will block you from inserting items
entirely via click (but other methods such as hotkey, clicking on the
storage boxes, and mousedrop will still work).
refactor: The detective's scanner will now be inserted into storage
items if clicked normally, and will scan the storage item if on combat
mode
/🆑
## About The Pull Request
This PR introduces a limited set of camera components that can be used
by surveillance security consoles and the PDA/laptop camera app.
<img width="366" alt="components"
src="https://github.com/tgstation/tgstation/assets/80724828/0e628863-9998-46d6-8822-e0a44543b4c2">
There is four camera components, each limited to a specified shell
circuit type.
Additionally, drone circuit shells can now use the recharge stations
too, much like how mobs with BCIs can recharge.
### New Components
<img width="136" alt="drone camera"
src="https://github.com/tgstation/tgstation/assets/80724828/fd045871-56bf-44a6-bb4f-ebe895d56d3d">
* Drone Camera
This camera component captures the surrounding area. It has an option to
set the camera range (near 5x5/far 14x14).
<img width="136" alt="bci camera"
src="https://github.com/tgstation/tgstation/assets/80724828/16bf2dd1-823b-4d66-8249-5d0f1bb1b779">
* BCI Camera
This camera component uses the active user's eyes as a camera function.
If the user's sights are damaged, the range will be forced to the near
setting. If the user is unconscious/dead/blinded or has no eyes, the
stream will be cut off.
It has an option to set the camera range (near 5x5/far 14x14).
<img width="136" alt="polaroid camera"
src="https://github.com/tgstation/tgstation/assets/80724828/7c4d53df-b4af-4f7c-8942-a63842510720">
* Polaroid Camera Add-On
This camera component streams to a camera network. The camera range is
hardcoded to the near setting (5x5).
<img width="136" alt="airlock camera"
src="https://github.com/tgstation/tgstation/assets/80724828/5d9e9d55-49fc-45a7-99c8-aaf1ae08f6d1">
* Airlock Camera
This camera component streams to a camera network. The camera range is
hardcoded to the near setting (5x5).
### Features
* The cameras can be EMP'd and will be disabled for 90 seconds if
successful
* When the cameras are active, they will actively drain the cell's power
per second (near range uses 3kJ & far range uses 8kJ)
* Advance camera console/AIs can use these cameras, however the camera
light is disabled (they will be useless in dark areas)
### Screenshots In Action
<details>
This is the drone camera viewed on a security camera console<br>
<img width="425" alt="near"
src="https://github.com/tgstation/tgstation/assets/80724828/e5247828-0fee-4552-9e70-5e5ee897c117"><br>
This is the same drone, now set to the far range setting<br>
<img width="425" alt="far"
src="https://github.com/tgstation/tgstation/assets/80724828/e58e3e85-aa90-4f1a-9dff-957c65764b77"><br>
</details>
## Why It's Good For The Game
This promotes emergent gameplay and improves the overall usefulness for
drones as they can be 100% used remotely.
## Changelog
🆑
add: Added new circuit camera components
qol: Circuit drones can now recharge at recharge stations
/🆑
---------
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
## About The Pull Request
Patches up some things that were lacking post #82905
- Some missing (un)seal messages
- a missed direct use of the mod_parts list
EDIT: Also fixes the modsuit painter, and makes sure modsuits can still
be set to use custom dmi files via
`MOD_ICON_OVERRIDE`/`MOD_WORN_ICON_OVERRIDE`
Fixes#83442
## Changelog
🆑
fix: some missing modsuit (un)sealing messages should no longer be
missing
fix: MOD circuit adapter core deployed parts output should work again
fix: Modsuit painter works again
/🆑
Scales the hypercharged slime core and wiremod gun cell maximum charge
and charge rate by the STANDARD_CELL_CHARGE and STANDARD_CELL_RATE
defines. Fixes their scale.
Closes#82907
## Changelog
🆑
fix: Fixes hypercharged slime core cells and circuit guns having 1,000
times less energy than intended.
/🆑
## About The Pull Request
This re writes most cell power usage cases with 2 defines
`STANDARD_CELL_CHARGE`(Joules) & `STANDARD_CELL_RATE`(Watts) so changing
cell capacity values in the future won't cause discrepancies.
## Changelog
🆑
code: most cell power usages are scaled with defined constants to help
adapt to future changes
/🆑
## About The Pull Request
Rewrites how alt click works.
Based heavily on #82625. What a cool concept, it flows nicely with
#82533.
Fixes#81242
(tm bugs fixed)
Fixes#82668
<details><summary>More info for devs</summary>
Handy regex used for alt click s&r:
`AltClick\((.*).*\)(\n\t.*\.\.\(\))?`
`click_alt($1)` (yes I am aware this only copies the first arg. there
are no other args!)
### Obj reskins
No reason for obj reskin to check on every single alt click for every
object. It applies to only a few items.
- Moved to obj/item
- Made into signal
- Added screentips
### Ventcrawling
Every single atmospherics machine checked for ventcrawling capability on
alt click despite only 3 objects needing that functionality. This has
been moved down to those individual items.
</details>
## Why It's Good For The Game
For players:
- Alt clicking should work more logically, not causing double actions
like eject disk and open item window
- Added context menus for reskinnable items
- Removed adjacency restriction on loot panel
For devs:
- Makes alt click interactions easier to work with, no more click chain
nonsense and redundant guard clauses.
- OOP hell reduced
- Pascal Case reduced
- Glorious snake case
## Changelog
🆑
add: The lootpanel now works at range.
add: Screentips for reskinnable items.
fix: Alt click interactions have been refactored, which may lead to
unintentional changes to gameplay. Report any issues, please.
/🆑
## About The Pull Request
Fixes#82440
This PR just creates a new macro, `LOWER_TEXT()` (yes the irony is not
lost on me) to wrap around all calls of `lowertext()` and ensure that
whatever we input into that proc will be stringified using the `"[]"`
(or `tostring()` for the nerds) operator. very simple.
I also added a linter to enforce this (and prevent all forms of
regression) because I think that machines should do the menial work and
we shouldn't expect maintainers to remember this, let me know if you
disagree. if there is a time when it should be opted out for some
reason, the linter does respect it if you wrap your input with the
`UNLINT()` function.
## About The Pull Request
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
- Fixes#82190
Have to now use the assigned constants and not magic number `10000`.
Also stuff will take the exact charge needed without any wastage.
## Changelog
🆑
fix: recharge stations draw the same amount of power as before but
directly from grid(without using apc cell power) and won't waste any
excess power
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
Removes all arbitrary energy and power units in the codebase. Everything
is replaced with the joule and watt, with 1 = 1 joule, or 1 watt if you
are going to multiply by time. This is a visible change, where all
arbitrary energy units you see in the game will get proper prefixed
units of energy.
With power cells being converted to the joule, charging one joule of a
power cell will require one joule of energy.
The grid will now store energy, instead of power. When an energy usage
is described as using the watt, a power to energy conversion based on
the relevant subsystem's timing (usually multiplying by seconds_per_tick
or applying power_to_energy()) is needed before adding or removing from
the grid. Power usages that are described as the watt is really anything
you would scale by time before applying the load. If it's described as a
joule, no time conversion is needed. Players will still read the grid as
power, having no visible change.
Machines that dynamically use power with the use_power() proc will
directly drain from the grid (and apc cell if there isn't enough)
instead of just tallying it up on the dynamic power usages for the area.
This should be more robust at conserving energy as the surplus is
updated on the go, preventing charging cells from nothing.
APCs no longer consume power for the dynamic power usage channels. APCs
will consume power for static power usages. Because static power usages
are added up without checking surplus, static power consumption will be
applied before any machine processes. This will give a more truthful
surplus for dynamic power consumers.
APCs will display how much power it is using for charging the cell. APC
cell charging applies power in its own channel, which gets added up to
the total. This will prevent invisible power usage you see when looking
at the power monitoring console.
After testing in MetaStation, I found roundstart power consumption to be
around 406kW after all APCs get fully charged. During the roundstart APC
charge rush, the power consumption can get as high as over 2MW (up to
25kW per roundstart APC charging) as long as there's that much
available.
Because of the absurd potential power consumption of charging APCs near
roundstart, I have changed how APCs decide to charge. APCs will now
charge only after all other machines have processed in the machines
processing subsystem. This will make sure APC charging won't disrupt
machines taking from the grid, and should stop APCs getting their power
drained due to others demanding too much power while charging. I have
removed the delays for APC charging too, so they start charging
immediately whenever there's excess power. It also stops them turning
red when a small amount of cell gets drained (airlocks opening and shit
during APC charge rush), as they immediately become fully charged
(unless too much energy got drained somehow) before changing icon.
Engineering SMES now start at 100% charge instead of 75%. I noticed
cells were draining earlier than usual after these changes, so I am
making them start maxed to try and combat that.
These changes will fix all conservation of energy issues relating to
charging powercells.
## Why It's Good For The Game
Closes#73438Closes#75789Closes#80634Closes#82031
Makes it much easier to interface with the power system in the codebase.
It's more intuitive. Removes a bunch of conservation of energy issues,
making energy and power much more meaningful. It will help the
simulation remain immersive as players won't encounter energy
duplication so easily. Arbitrary energy units getting replaced with the
joule will also tell people more meaningful information when reading it.
APC charging will feel more snappy.
## Changelog
🆑
fix: Fixes conservation of energy issues relating to charging
powercells.
qol: APCs will display how much power they are using to charge their
cell. This is accounted for in the power monitoring console.
qol: All arbitrary power cell energy units you see are replaced with
prefixed joules.
balance: As a consequence of the conservation of energy issues getting
fixed, the power consumption for charging cells is now very significant.
balance: APCs only use surplus power from the grid after every machine
processes when charging, preventing APCs from causing others to
discharge while charging.
balance: Engineering SMES start at max charge to combat the increased
energy loss due to conservation of energy fixes.
/🆑
---------
Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com>
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
## About The Pull Request
That's it really.
It's supposed to have a `shock_source` arg, but 2/3 of the procs that
are registered to this signal don't include that in their args list.
## Why It's Good For The Game
Out of order positional args = bad.
## Changelog
Nothing player facing (probably)
## 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
This refactors how machines are deconstructed in the following ways
- You can no longer override `obj/machinery/deconstruct()`. If you want
customized behaviour then override `on_deconstruction()` instead.
This comes with the added benifit of no longer needing to check for the
`NO_DECONSTRUCTION` flag because the machine base proc does that for us
& if it finds that flag it won't proceed to call `on_deconstruction()`
meaning no machine will have a chance to spawn anything which is the
current behaviour.
This is required to make #81290 work for all machines at least so that
machine can send the `COMSIG_OBJ_DECONSTRUCT` signal without subtypes
overriding & forgetting to call the parent proc
- `dump_contents()` only gets called when the machine is deconstructed
not destroyed thus not leaving behind any of its contents inside. Fixes
https://github.com/tgstation/tgstation/pull/81290#issuecomment-1925752583
## Changelog
🆑
fix: machines that should not drop contents when deleted no longer do.
refactor: refactors how machines are deconstructed. report bugs on
github.
/🆑
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
## About The Pull Request
This PR makes several changes to how circuit action buttons work:
- The MOD action and BCI action components have been merged into a
single component.
- MOD circuit actions can be pinned from the configuration menu. This
works the same way as pinning individual modules, and can be done both
by the wearer and a suit AI.
- Action components have an output pin for the user of the action. This
allows MOD module circuits to distinguish between the wearer and an AI.
- Creates a supertype for `/datum/action/item_action/mod/pinned_module`
named `/datum/action/item_action/mod/pinnable`, which implements common
functionality for pinned modules and pinned circuit module actions.
## Why It's Good For The Game
The prior functionality of circuit MOD actions was somewhat unintuitive,
requiring the user to select an action from a radial menu *after*
activating the module, whether from a pinned action or from the module
radial. Providing similar pinning functionality to modules themselves
makes MOD actions more readily usable.
Merging the two different types of circuit components into one was made
with the idea that adding new types of shells with equipment actions
would inflate the number of subtypes of
`/obj/item/circuit_component/equipment_action` without adding much
meaningful functionality.
## Changelog
🆑
qol: MOD wearers and internal AIs can pin the individual actions in a
MOD circuit module in a similar way to how they can pin modules. Circuit
module actions can be pinned from the configuration menu of the circuit
refactor: The MOD action and BCI action components have been merged into
one component - the Equipment Action component.
/🆑
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
closes#53931, #70916, #53931
## About The Pull Request
Organs were previously stored in nullspace. Now they are stored in their
prospective bodyparts. Bodyparts are now stored in the mob.
I've also had to refactor a lot of code concerning organ movement.
Previously, organs were only moved into bodyparts once the bodyparts
were removed. To accomodate this change, two major distinctions have
been made:
**Bodypart removal/insertion**
Called only when an organ is taken out of a bodypart. Bodypart overlays,
damage modifiers or other changes that should affect a bodypart itself
goes here.
**Mob insertion/removal**
Called when an organ is removed from a mob. This can either be directly,
by taking the organ out of a mob, or by removing the bodypart that
contains the organ. This lets you add and remove organ effects safely
without having to worry about the bodypart.
Now that we controle the movement of bodyparts and organs, we can fuck
around with them more. Summoning someones head or chest or heart will
actually kill them now (and quite violently I must say (chest summoning
gibs lol)).
https://github.com/tgstation/tgstation/assets/7501474/5efc9dd3-cfd5-4ce4-b70f-d0d74894626e
I´ve also added a unit test that violently tears apart and reconstructs
a person in different ways to see if they get put toghether the right
way
This will definitely need a testmerge. I've done a lot of testing to
make sure interactions work, but more niche stuff or my own incompetence
can always slip through.
## Why It's Good For The Game
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
A lot of organ work is quite restricted. You can't C4 someones heart,
you cant summon their organs and a lot of exceptions have to be made to
keep organs in nullspace. This lets organs (and bodyparts) play more
nicely with the rest of the game. This also makes it a lot easier to
move away from extorgans since a lot of their unique movement code has
been removed and or generalized.
I don't like making PRs of this size (I'm so sorry reviewers), but I was
in a unique position to replace the entire system in a way I couldn't
have done conveniently in multiple PRs
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and it's effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
refactor: Your organs are now inside your body. Please report any issues
with bodypart and organ movement, including exotic organ, on github and
scream at me
fix: Cases of unexpected organ movement, such as teleporting bodyparts
and organs with spells, now invokes a proper reaction (usually violent
death)
runtime: Fixes HARS runtiming on activation/deactivation
fix: Fixes lag when species swapping
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
## About The Pull Request
Added a user type to integrated circuits that can't be stored as a user
type but can be typecasted to entity. Useful for components that
directly ask for an input from the user, like the list pick component.
Refactored the list pick component to use this user port and to also
send failure signals whenever a success signal is not sent.
Removed the triggered port for the list pick component.
Also fixes a runtime that occurs with the list pick component if the
list passed in only contains null values.
## Why It's Good For The Game
Can't force a prompt onto people who haven't interacted with your
circuit.
## Changelog
🆑
add: Added a user type to integrated circuits
/🆑
---------
Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.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
Prevailing feedback has been:
- The player base cannot be trusted to control MULEbots.
- It should be clearer what bots can and can't do.
The former is easy to fix.
The latter is sort of a matter for policy but I'm going to investigate
giving bots a rudimentary laws system. Plus that sounds much more
controversial than this so I am going to atomise this outside of that
PR.
MULEbots can still be set to allow sentience by cargo technicians, but
don't start that way.
ADDITIONALLY this PR just changes it so that MULEbots do not crush
people unless:
- They have been emagged.
- Their safety wire has been cut.
Either means works, so it's not too hard to access for nefarious
purposes, but hard to do to yourself.
Otherwise they just slow down for a few seconds instead.
Also fixed an unrelated name bug while I was there.
Closes#76926
## Why It's Good For The Game
Players would take them, not deliver any cargo, and repeatedly ask
people to lie down in front of them.
Plus Tram has 5 of the things which is frankly too many to be wandering
around the bar.
## Changelog
🆑
balance: You can't possess a MULE as soon as the round starts, someone
will have to give you permission.
balance: MULEbots no longer crush prone characters unless they have been
hacked (or emagged).
fix: Bots can put numbers in their names, what with being robots.
admin: Adds attack logging when certain wires are cut (for instance:
MULEbot safeties)
/🆑
## 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
Reduced the cost of a lot of MODules.
Pathfinder 2 -> 1
Tether 3 -> 1
Temperature Regulator 2 -> 1
DNA lock 2 -> 1
Health analyzer 2 -> 1
Sonar 2 -> 1
Microwave beam 2 -> 1
Drill 2 -> 1
All visors (including NV and thermals) 2 -> 1
Circuit Adapter 2 -> 1
The Mining MODsuit has had its complexity increased to 15 and now starts
with the eating apparatus module, with a total base complexity of 10/15
now.
The Prototype MODsuit's active slowdown has been decreased from 1.5 (!)
to 1.
## Why It's Good For The Game
> Reduced the cost of a lot of MODules.
There's lots of cute little MODules here, and they are all despite their
'small' cost far too expensive for them to ever be used. The small
little cost adds up, when you consider that two 2-complexity modules
cost FOUR, which is more than most good modules (that are 3), especially
when storage modules take up 3 complexity already. Think about it like
genetics, imagine if geladikinesis cost 40 instability. It'd be
pointless and just make it not used.
> Pathfinder 2 -> 1
Pathfinder is a little buggy, a bit janky, and still just a commodity,
so this might let captains keep it for themselves more often when
they're kitting out their MOD.
> Tether 3 -> 1
Tether costing 3 complexity is ABSURD. That's as much as the actual ion
jetpacks, and that's for something which you can replace completely with
a fire extinguisher, not even including the tiny 4 tiles tethering
range.
> Temperature Regulator 2 -> 1
This is vital for spacewalking, I really don't know why it's this
expensive. Hell it should be the norm, but whatevs.
> DNA lock 2 -> 1
Nobody's ever going to use this if it can just be EMPed and broken...
especially when it costs 2 complexity, which is the same cost as defibs,
surgical processor, holster, criminal capture..
> Health analyzer 2 -> 1
This is just a health analyzer. A small item that you're paying for the
privilege of being able to have it in your janksuit. It really shouldn't
cost 2 complexity, nobody ever takes this.
> Sonar 2 -> 1
I don't think there's much of a reason for sonar to be 2 complexity. You
might think it's nuts, but sonar really isn't that useful as it's a
windup with a screen-only range. Making it 1 might let it be seen ingame
at some point.
> Microwave beam 2 -> 1
Despite the cool name this just fries food. I don't think that should be
expensive!
> Drill 2 -> 1
The drill module is mostly redundant when by the time you get it,
chances are you have a plasma cutter already which is usually better, if
not as space-efficient. There's also the dumb issue with drilling into
gibtonite which instantly blows it up.
> All visors (including NV and thermals) 2 -> 1
Similarly to the health analyzer, chances are if you HAVE the module you
don't actually *need* it as you're already.. that job.
Additionally, and this is also part of the reason for the NV, thermal,
and even the health analyzer modules, is that traitors/nukies now have
to balance MOD economy alongside TC count, and I can't tell you just how
frustrating it is to buy something and be told I don't have enough
complexity to put it into the MODsuit. I already spent the damn TC!
> Circuit Adapter 2 -> 1
This thing seems pretty useless. All it can really do is open and close
your modsuit, which like, wow okay. No need for it to be expensive.
> The Mining MODsuit has had its complexity increased to 15 and now
starts with the eating apparatus module, with a total base complexity of
10/13 now.
The complexity increase is because for some reason the MODsuit is
already filled to the brim by default, which means that actually
interacting with robotics in any way is thoroughly disincentivized as
you'd need to take so many modules out to do so that it makes the
purchase and interaction pointless. Now you CAN go and ask robotics for
anything you need, though there isn't much a miner would want and value
enough to trek across the station, for now.
Also, it starts with the eating apparatus because it really looked like
it should! The flavor text even talks about miners, it's strange for
that to be there if miners won't use it. It'll also encourage it to
actually be bought more by allowing you to eat through it.
> The Prototype MODsuit's active slowdown has been decreased from 1.5
(!) to 1.
1.5 is a lot, A LOT, of slowdown. For such an incredibly rare mod, it
completely kills the damn thing, even for the charlie station crew! You
can't fight xenos with 1.5 slowdown! Having Kinesis isn't enough of a
reason to cripple it so thoroughly and pointlessly. It's 0.4 now, which
is a nice middleground between 'fast' suits like the medical and
security ones, and the 'slow' ones like civilian, engineering, science.
## Changelog
🆑
balance: Reduced the complexity cost of a lot of MODules.
balance: Pathfinder 2 -> 1
balance: Tether 3 -> 2
balance: Temperature Regulator 2 -> 1
balance: DNA lock 2 -> 1
balance: Health analyzer 2 -> 1
balance: Sonar 2 -> 1
balance: Microwave beam 2 -> 1
balance: Drill 2 -> 1
balance: All visors (including NV and thermals) 2 -> 1
balance: Circuit Adapter 2 -> 1
balance: The Mining MODsuit has had its complexity increased to 13 and
now starts with the eating apparatus module, with a total base
complexity of 10/13 now.
balance: The Prototype MODsuit's active slowdown has been decreased from
1.5 (!) to 1.
spellcheck: Fixed a type on the energy net module.
/🆑
## About The Pull Request
[A common problem with explosions is an overabundance of
sleeping](6499077a09)
In an attempt to solve this issue, let's not continue to sleep and do
work in door closing if the door is already deleted
(This is caused by firelocks activating due to other adjacent objects
deleting, triggering an atmos update, and closing the firelocks before
they get bombed. I don't have a elegant way of resolving that core
problem, so let's just minimize the impact)
[Nukes a stupid sleep loop in airlock
code](5b16360520)
When an airlock was depowered, it would enter a sleep loop, decrementing
its delay by 1 second every well, one second, so long as it had the
right wires flipped
This is very stupid
Instead, let's use signals off wire changes and a combo of timer and
remaining time var to do this with JUST a timer
Most of the changes here are just swapping over wires to a setter to
make signal registration work\
## Why It's Good For The Game
Less sleeping around explosions means less dropped ticks after a bomb
goes off. Good just in general
Also this excises dumb boomer code and adds some hooks for other devs to
use (we should use wires more man)
## About The Pull Request
Signals were initially only usable with component listeners, which while
no longer the case has lead to outdated documentation, names, and a
similar location in code.
This pr pulls the two apart. Partially because mso thinks we should, but
also because they really aren't directly linked anymore, and having them
in this midstate just confuses people.
[Renames comp_lookup to listen_lookup, since that's what it
does](102b79694f)
[Moves signal procs over to their own
file](33d07d01fd)
[Renames the PREQDELETING and QDELETING comsigs to drop the parent bit
since they can hook to more then just comps
now](335ea4ad08)
[Does something similar to the attackby comsigs (PARENT ->
ATOM)](210e57051d)
[And finally passes over the examine
signals](65917658fb)
## Why It's Good For The Game
Code makes more sense, things are better teased apart, s just good imo
## Changelog
🆑
refactor: Pulled apart the last vestiges of names/docs directly linking
signals to components
/🆑
## About The Pull Request
Resprites stock parts to bring them up to date, changes manipulators to
servo motors as I couldn't make manipulators work well at this scale.
(Power cells sold separately)
## Why It's Good For The Game
The old stock parts are dated, in some cased quite ugly, and in the case
of manipulators a ball of assorted pixels. Incidentally removed a couple
of single letter var names.
## Changelog
🆑
image: Stock parts have been resprited.
code: Manipulators have been renamed to servo motors, all related types
have been repathed to match.
/🆑
## About The Pull Request
0426f7ddba/code/game/objects/items/stacks/stack.dm (L449)
Ok, but can we not?
This PR refactors sheet crafting to generalize all the cases that were
previously locked behind grille/window type checks and such. In their
stead there are bitflags that can be set to achieve certain behaviors.
All the behavior from before should be preserved, but now it can be
extended to other items. E.g. if you want a railing that can be crafted
underneath directional windows, or an item that behaves like a grille
does--it's just a matter of setting the right obj_flags for it now.
This makes it very simple and painless to add new recipes that use
directional crafting! It's all modular now.
<details><summary>Details</summary>
---
### What I've done:
-Eliminated all the type checks, instead it will now be handled by
object flags and recipe vars, making for a much more configurable
system.
-Added two new obj_flags: `BLOCKS_CONSTRUCTION_DIR` and
`IGNORE_DENSITY`.
-Additionally, I renamed the existing flag `NO_BUILD` to
`BLOCKS_CONSTRUCTION`.
-Changes the proc `valid_window_location` to `valid_build_direction`,
and makes it work for things other than windows.
-Removed a deprecated `window_checks` var from the stack_recipe datum.
-Added three more vars to the stack_recipe datum: `check_direction` and
`check_density`, `is_fulltile`
-Decoupled `on_solid_ground` from the object density check. Now you can
set those separately, allowing you to make recipes that forbid/allow
building things over other things while in space.
---
### What the new flags do:
`BLOCKS_CONSTRUCTION` works as before---prevents objects from being
built on the object. I felt that the previous name was not descriptive
enough, you should know exactly what it does just from looking at the
name.
_example: dna scanner_
`BLOCKS_CONSTRUCTION_DIR` -- setting this on an object will prevent
objects from being built on it when their directions are the same.
_example: directional windows, windoors, railings_
`IGNORE_DENSITY` -- setting this on an object will cause its density to
be ignored when performing the construction density check. This could
have other potential uses as well in the future.
_example: grilles, directional windows, tables_
These three flags cover all the bases for the types of items that are
currently craftable, so there is no more need for any type checking or
weird snowflake window checks. Simply set the appropriate flag and it'll
work as you would expect.
---
### What the recipe vars do:
`check_direction` tells the recipe to check if there's something in that
direction with the `BLOCKS_CONSTRUCTION_DIR` flag set.
`check_density` tells the recipe to run the density check when set. This
is true by default. There are very few items in the game that currently
have this set to false--namely grilles. Setting this to false will make
it so that the object can be constructed regardless of what is in that
tile (unless `one_per_turf` is also set, which will make it so that you
can't craft the same thing twice in the same turf).
`is_fulltile` is used for fulltile windows, but it doesn't necessarily
have to be--you can give this to any recipe and it will adopt the same
properties as that of the fulltile window. Basically they have a special
case where they shouldn't be able to be built over directional
constructions, where normally things would be able to be. Setting this
makes check_direction true as well.
---
### In summary:
Sheet crafting still works just as it did before. But the backend of it
has gotten a glow up and will be able to more easily support new
behaviors.
</details>
## Why It's Good For The Game
This makes the crafting system much more flexible to add recipes to, and
will prevent bad code practices of stacking more conditionals down the
line whenever someone wants to add an item that behaves like grilles or
directional windows in how they are constructed.
It had to be done. Those window checks were a mess.
## Changelog
🆑
qol: added fifty stack versions of remaining glass sheet stacks for ease
of debugging
refactor: refactored sheet crafting to better support directional
constructions that aren't windows
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
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
Refactors regenerate organs to be slightly more intelligent in handling
organ changes and replacements.
Noteably:
- We don't remove organs that were modified by the owner; such as
changing out your heart for a cybernetic
- We early break out of the for loop if they aren't supposed to have an
organ there and remove it
- We check for the organ already being correct, and just healing it and
continuing if it is
Also changes the names of some of the organ helpers into snake_case
### Mapping March
Ckey to receive rewards: N/A
## Why It's Good For The Game
## Changelog
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
## About The Pull Request
These changes fix how machines are pried open with crowbars. Currently,
most machines can be pried open, but many of them have no method for
being closed again. This means they can be pried once, and then never
again (as their internal logic has them stuck in an "open" state).
Additionally, the densities of these machines is also inconsistent, as
density is tied to the procs for opening/closing machines (open =
non-dense, closed = dense). Thus, these new changes allow desired
densities to be passed to `open_machine()` and `close_machine()`, as
well as `default_pry_open()`, meaning that atypical machine densities
can be maintained (e.g. machines that should remain dense when open, or
non-dense when closed).
I've also added a `close_after_pry` boolean parameter to the
`default_pry_open()` proc, which determines whether to immediately close
a machine after opening it. This is useful for machines that don't
really have a use case for remaining open, often lacking a sprite to
represent this state as well.
* Note: Opening and immediately closing machines with this boolean will
still drop their contents onto the floor, but will now immediately
"close" in their logic, allowing for further prying attempts in the
future.
It's worth noting that this implements default density values for these
procs, which match the existing behavior for machines, so as to
(hopefully) not disrupt existing or expected machine behavior.
Two caveats to these changes currently exist:
1. On machines that immediately close after prying, the prying action
can now be spammed to the chat with repeated clicking. I'm uncertain if
this needs some sort of spam protection or if it's fine as is.
2. I've only been able to manually test this code. I'd love to write
unit tests for it, as it affects a lot of different machines, but don't
know where to begin with DM Unit Testing (or which files would be good
examples to reference in the code base).
* Note: I did manually test each and every machine that calls
`default_pry_open()` and they all seem to be working correctly. (Except
for `obj/machinery/plumbing/sender`, but that doesn't seem to need
prying, as it has no contents to drop, only reagents.)
As always, let me know if any improvements/changes should be made.
This closes#26833.
## Why It's Good For The Game
These changes allow crowbar prying to correctly occur multiple times on
any machine, which is intended behavior. It prevents player confusion
that could occur when a machine couldn't be pried open a second time
during a shift, even though it had previously been pried before, forcing
players to question themselves. (Are they missing something? Did they
perform the action a different way last time? Is the machine actually
still powered on instead of off? Etc.)
These changes also maintain the correct density for machines after
prying, preventing scenarios where a machine might behave differently
once it had been pried open. (An example of this was being able to walk
through a smartfridge after prying it open.) Additionally, players are
no longer required to know/use workarounds (such as machine disassembly)
to retrieve a powered-off machine's contents.
Overall, these changes improve consistency around machines, creating
more scenarios where they behave as players would expect.
## Changelog
🆑
fix: machines can now be pried open more than once.
fix: machines now have the correct density when pried open.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
This PR adds a new unit test for all organs, a new unit test for lungs,
and includes improvements for the existing breath and organ_set_bonus
tests. Using the tests, I was able to root out bugs in the organs. This
PR includes an advanced refactor of several developer-facing functions.
This PR certainly represents a "quality pass" for organs which will make
them easier to develop from now on.
### Synopsis of changes:
1. Fixed many fundamental bugs in organ code, especially in
`Insert()`/`Remove()` and their overrides.
2. Added two new procs to `/obj/item/organ` named `on_insert` and
`on_remove`, each being called after `Insert()`/`Remove()`.
3. Added `organ_effects` lazylist to `/obj/item/organ`. Converted
`organ_traits` to lazylist. 2x less empty lists per organ.
4. Adding `SHOULD_CALL_PARENT(TRUE)` to `Insert()`/`Remove()` was very
beneficial to stability and overall code health.
5. Created unit test `organ_sanity` for all usable organs in the game.
Tests insertion and removal.
6. Created unit test `lungs_sanity` for
`/obj/item/organ/internal/lungs`.
7. Improved `breath_sanity` unit tests with additional tests and
conditions.
8. Improved `organ_set_bonus_sanity` unit tests with better
documentation and maintainable code.
---
### Granular bug/fix list:
- A lot of organs are overriding `Insert()` to apply unique
side-effects, but aren't checking the return value of the parent proc
which causes the activation of side-effects even if the insertion
technically fails. I noticed the use-case of applying "unique
side-effects" is repeated across a lot of organs in the game, and by
overriding `Insert()` the potential for bugs is very high; I solved this
problem with inversion-of-control by adding two new procs to
`/obj/item/organ` named `on_insert` and `on_remove`, each being called
after `Insert()` and `Remove()` succeed.
- Many organs, such as abductor "glands", cursed heart, demon heart,
alien hive-node, alien plasma-vessel, etc, were not returning their
parent's `Insert()` proc return value at all, and as a result those
organs `Insert()`s were always returning `null`. I have been mopping
those bugs up in my last few PRs, and now the unit test reveals it all.
Functions such as those in surgery expect a truthy value to be returned
from `Insert()` to represent insertion success, and otherwise it
force-moves the organ out of the mob.
- Fixed abductor "glands" which had a hard-del bug due to their
`Remove()` not calling the parent proc.
- Fixed cybernetic arm implants which had a hard-del bug due to
`Remove()` not resetting their `hand` variable to `null`.
- Fixed lungs gas exchange implementation, which was allowing exhaled
gases to feedback into the inhaled gases, which caused Humans to inhale
much more gas than intended and not exhale expected gases.
### Overview of the `organ_sanity` unit test:
- The new `organ_sanity` unit test gathers all "usable" organs in the
game and tests to see if their `Insert()` and `Remove()` functions
behave as we expect them to.
- Some organs, such as the Nightmare Brain, cause the mob's species to
change which subsequently swaps out all of their organs; the unit test
accounts for these organs via the typecache `species_changing_organs`.
- Some organs are not usable in-game and can't be unit tested, so the
unit test accounts for them via the typecache `test_organ_blacklist`.
### Overview of the `lungs_sanity` unit test:
- This unit test focuses on `/obj/item/organ/internal/lungs` including
Plasmaman and Ashwalker lungs. The test focuses on testing the lungs'
`check_breath()` proc.
- The tests are composed of calling `check_breath` with different gas
mixes to test breathing and suffocation.
- Includes gas exchange test for inhaled/exhaled gases, such as O2 to
CO2.
### Improvements to the `breath_sanity` unit tests:
- Added additional tests for suffocation with empty internals, pure
Nitrogen internals, and a gas-less turf.
- Includes slightly more reliable tests for internals tanks.
## Why It's Good For The Game
**Organs and Lungs were mostly untested. Too many refactors have been
submitted without the addition of unit tests to prove the code works at
all.** Time to stop. _Time to get some help_. Due to how bad the code
health is in organs, any time we've tried to work with them some sort of
bug caused them to blow up in our faces. I am trying to fix some of that
by establishing some standard testing for organs. These tests have
revealed and allowed me to fix lot of basic developer errors/oversights,
as well as a few severe bugs.
## Changelog
🆑 A.C.M.O.
fix: Fixed lungs gas exchange implementation, so you always inhale and
exhale the correct gases.
fix: Fixed a large quantity of hard-deletes which were being caused by
organs and cybernetic organs.
fix: Fixed many organs which were applying side-effects regardless of
whether or not the insertion failed.
code: Added unit tests for Organs.
code: Added unit tests for Lungs.
code: Improved unit tests for breathing.
code: Improved unit tests for DNA Infuser organs.
/🆑
## About The Pull Request
- Juggernaut and Rust Walker projectiles were subtyped off of magic,
which is `nodamage`.
- The juggernaut actually had a copy+paste error with their type
`on_hit` which caused none of their special effects on hit ("relative
patching catches this")
- Then I realized projectiles have this var `nodamage` which is, for all
intents and purposes, just `damage > 0`. it's not checked for pacifism,
it's just that. This is dumb. So very dumb, so I removed it.
- There are, however, a few situations which used it in a unique way,
such as the blast wave cannon. This is why I replaced it with a proc,
`is_hostile_projectile`, for certain situations to actually find out if
the projectile is damaging. Projectiles can override this on a per type
basis by default, damaging projectiles = hostile.
- This has a chance to break some things, but I ... kinda doubt it will.
Fixes#73756
## Why It's Good For The Game
Projectiles that act as they should, less dumb vars
## Changelog
🆑 Melbert
fix: Fixes Juggernaut / Rust Walker projectiles doing zero damage
fix: Fixes Juggernaut projectiles not doing bonus damage to nearby
structures
code: Removed projectile nodamage var, replaces it with just checking
for damage
/🆑
## About The Pull Request
>_"I don't remember buying tickets to Mutants on Ice."_
>-Duke Nukem
This PR is (hopefully the final) part of a series of my continuing
refactors of the DNA Infuser. This PR represents a "quality pass" which
should also iron-out the rest of the most impactful bugs.
Granular list of changes:
- This PR adds unit tests for the DNA Infuser organs and
`/datum/status_effect/organ_set_bonus` as recommended by @AnturK
- I noticed that the base `/datum/infuser_entry` was being used in the
machine for the Fly and "rejected" infusions, whereas usually we would
expect it to be a base type used only as a development template. I
corrected this issue and created `/datum/infuser_entry/fly` to be used
for that use-case instead.
- Added `/mob/proc/can_mutate()` and `/mob/living/carbon/can_mutate()`
to replace a few copied lines across several files. The proc is normally
used in the context of mutating a Human via their DNA.
- I fixed a ton of typos in organ-related code, specifically where
"receiver" was typo'd as "reciever". There are far more of those typos,
but I limited the scope of my changes to organs.
- I noticed a bug in `/datum/species/proc/regenerate_organs` wherein a
race condition caused an organ to remove itself before it's done
inserting itself. This happens because the Fly organ set bonus runs
`regenerate_organs` which calls `Remove` on the organ while `Insert` is
still in the call-stack. I added `INVOKE_ASYNC` as a workaround, and
also changed the order the signals are emitted to prevent future bugs.
This bug primarily only impacted the flyperson species transformation,
which was part of the DNA Infuser's flyperson infusion organ set bonus.
- In my last refactor PR #72745 I also introduced a bug in
`/obj/machinery/dna_infuser/proc/infuse_organ` wherein I forgot to add
the usage of `new` when attempting to implant new organs, and this PR
fixes the erroneous code.
- Fxed a bug which causes the organ set bonus to activate when mixing
organs from different sources, which is caused by a developer oversight
wherein all `/datum/status_effect/organ_set_bonus` had identical IDs.
- Added a cleaner `replacetext`-based way of handling pronouns in
`/datum/element/noticable_organ/proc/on_receiver_examine`, using custom
macros `%PRONOUN_S` and `%PRONOUN_ES` as advised by @MrMelbert
- This PR also fixes#72767
## Why It's Good For The Game
With the changes in this PR the machine will finally work as we expect
it to. By adding unit tests we will also be able to ensure that it works
as expected from now on. I feel confident saying that the completeness,
algorithmic correctness, and code health of the DNA Infuser is much
better than it was before.
## Changelog
🆑 A.C.M.O.
fix: Fully fixed the DNA Infuser, which will now infuse organs as
expected.
fix: Fixed flyperson species transformation and organ set bonus, which
was throwing a runtime.
fix: Fixed many typos in organ-related source code.
/🆑
---------
Co-authored-by: Time-Green <timkoster1@hotmail.com>
Necessary for #72292 to work effectively, and probably not very useful
out of that context. Split out of its own PR because this is long and
boring.
I want to make sure that we're catching actual mistakes there, and not
just experiencing side effects of how shitty the attack chain is.
Adds lints for `balloon_alert(span_xxx(...))` (which is always wrong),
and balloon alert where the first letter is a capital (which is usually
wrong). Fixes everything that failed them. As a reminder, abbreviations
like "AI" and "GPS" shouldn't be capitalized in a balloon alert.
In cases where this is intentional for flavor (there was one case), you
can `UNLINT` like so:
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
## About The Pull Request
Updated crafting menu, adding a lot of new functions and recipes that
were not in the crafting menu before.
<img alt="cult"
src="https://user-images.githubusercontent.com/3625094/206009533-aec3a1dd-cbe5-45eb-8515-1b75fabb65c5.PNG">
<img alt="nH77dLyyGx"
src="https://user-images.githubusercontent.com/3625094/206009786-b6706f70-0599-40bf-b051-8f499de43abd.png">
https://user-images.githubusercontent.com/3625094/206009841-738e4a03-0660-45b7-8d83-15eeb6501967.mp4
## Why It's Good For The Game
It is easier to use, and it has a lot of recipes that were spread
throughout the game, some of which weren't even on the wiki.
Crafting and cooking now count about 1200 recipes in total, including
conditionally available ones.
## Changelog
🆑
qol: Rewrote the crafting/cooking menu UI
qol: Split crafting and cooking menus in two different menus
qol: Crafting is no longer blocking the entire UI, only the "Make"
buttons are disabled
qol: Added stack crafting recipes to the crafting menu
qol: Added cooking recipes that were absent in the crafting menu before
(tool recipes, machine recipes, reactions)
qol: Added option to search recipes by title
qol: Added option to filter recipes by required materials/ingredients
qol: Added food types to the cooking menu, highlighting diet of your
species (liked, disliked foods)
qol: Added total nutrition value of the result to the cooking menu
qol: Added option to filter cooking recipes by the food type of the
resulting food
qol: Added "Can make" category that lists all currently craftable
recipes throughout all categories
refactor: changed categories and reshuffled some items in them
code: Reagents now have default container to get an icon from the
reagent datum
code: Objects now have `desc_controls` var for OOC information about
mouse controls that are visible on examine, but not in the description
fix: Fixed alignment on many food icons
fix: Fixed missing icon for beef stroganoff
/🆑
Co-authored-by: tattle <66640614+dragomagol@users.noreply.github.com>
## About The Pull Request
- Rewrites how action button icons are generated.
- Prior, generated an action button icon was fairly simplistic and
didn't allow for many changes. Someone recently added the option for
overlays to be generated over action buttons, but the framework was very
weak.
- Now, action button icon generation is split across multiple procs,
like atom icon updates.
- The background of action buttons are underlays
- The actual icon of the action button is the icon and icon state of the
action button movable
- The rim / border of the button is an overlay, layered overtop the
button.
- Allows observers to see what action buttons a mob has. They even
update in real time! And no, the observers cannot click on them.
## Why It's Good For The Game
- Runechat text of action buttons are no longer hidden behind the actual
icon. This was very ugly with cooldown actions, as the cooldown text was
hidden behind a lot of spell icons.
- Cuts down on a lot of icon duplication.
- Gives much finer control over action button icons
- Saves a bit of processing from generating full action button icons
when not necessary. Not implemented in many places, but is in some.
## Changelog
🆑 Melbert
add: Observers can now see what action buttons an observed mob has. No,
you can't click them. And no it doesn't show EVERY action.
refactor: Refactored how action button icons are generated. Some actions
will now use a colored border when active instead of just turning green.
Cooldown text will also appear on the top layer of actions too. If you
see any funky lookin' icons (namely their borders), let me know.
refactor: Bluespace Golem's teleport action is now a cooldown action.
fix: Construct actions go to the middle of the screen like expected.
/🆑
## About The Pull Request
Soft revert of #71224 , Fixes#71222
Fixes an exploit involving attachment of multiple igniters to one
assembly.
- Multiple igniters or condensers can no longer be attached to the same
assembly holder
- Assembly holders have a limit of 12 assemblies maximum
- I'm not sure if this is too low or limited, I picked it arbitrarily.
Please inform me if it could be upped a smidge.
- This lag exploit was born because of limitless assembly holders, which
is a little silly even with the exploit aside. All that uncapped holders
can bring are exploits or bugs, which I feel confident limited can
prevent. What use is there even for having so many?
- Cleans up / refactors some aspects of assemblies and assembly holders.
- Assemblies had a weird wire type flag that was only ever used by
signallers, but also used wrong by signallers. I did some scanning of
the code and realized that ... a lot of this was just straight up
unused, and not even assigned anywhere.
- Now, there is a flag assembly flag var, which everything is read off
of. Tested it and still seemed to all work fine.
## Why It's Good For The Game
Lag exploits are bad.
## Changelog
🆑 Melbert
fix: Fixed an exploit involving igniters attached to themselves.
Assembly holders are now limited to 12 assemblies maximum, and you
cannot attach multiple igniters to the same assembly.
refactor: Refactored some assembly jank, namely in how they pulse and
are pulsed.
/🆑
- Makes QDELETED use isnull(x) instead of !x, giving about 0.2 to 0.25s
of speed.
- Make disposal constructs only update icon state rather than go through
expensive overlay code. Unfortunately did not have much effect, but is
something they should've been doing nonetheless.
- Makes RegisterSignal only take signals directly as opposed to
allocating a fresh list of signals. Very few consumers actually used
this and it costs about 0.4s. Also I think this is just a bad API anyway
and that separate procs are important
`\bRegisterSignal\((.*)list\(` replaced with `RegisterSignals($1list(`
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
## About The Pull Request
This PR adds a reagent injector component that's exclusive to BCIs.
(Requested to be integrated into BCIs by Mothblocks.)
When outside of a circuit, the component itself stores the reagents.
However, if it's inside of a BCI, the storage is moved to the BCI. The
storage can contain up to 15u of reagents and acts like an open
container. (However, it won't spill even if you throw it, it just acts
like an open container code-wise, don't worry about it.)
You can only have one reagent injector in a circuit. Trying to insert
multiple will give you an error message.
The entire dose is administered at once. (Requirement set by
Mothblocks.)
Please don't try to dispute any of the specific limitations in the
comments as they're out of my control. They're reasonable anyways.
Reagent Injector Input/Output:
Inject (Input Signal) - Administers all reagents currently stored inside
of the BCI into the user.
Injected (Output Signal) - Triggered when reagents are injected. Not
triggered if the reagent storage is empty.
New BCI Input:
Show Charge Meter (Number) - Toggles showing the charge meter action.
(Adds some capacity for stealth.)
Install Detector Outputs: (Added following a comment about having to use
weird workarounds for proper loops.)
Current State (Number) - Outputs 1 if the BCI is implanted and 0 if it's
not.
Installed (Signal) - Triggered when the BCI is implanted into it's user.
Removed (Signal) - Triggered when the BCI is removed from it's user.
This PR also adds BCI manipulation chambers to all currently present
circuit labs. (Solution proposed by Mothblocks.)
Yes I had to do some other mapping changes to allow for this. No I don't
have any mapping experience, why do you ask?
<!-- Describe The Pull Request. Please be sure every change is
documented or this can delay review and even discourage maintainers from
merging your PR! -->
## Why It's Good For The Game
One small step for BCIs, one giant leap for circuit kind. (First
"proper" circuit to human interaction in the entire game!)
This allows for some funky stuff and also makes it less of a pain in the
ass to use BCIs. What's not to love?
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and it's effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
add: Added a reagent injector component and BCI manipulators to all
circuit labs. (+ install detector component)
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Makes the code compatible with 515.1594+
Few simple changes and one very painful one.
Let's start with the easy:
* puts call behind `LIBCALL` define, so call_ext is properly used in 515
* Adds `NAMEOF_STATIC(_,X)` macro for nameof in static definitions since
src is now invalid there.
* Fixes tgui and devserver. From 515 onward the tmp3333{procid} cache
directory is not appened to base path in browser controls so we don't
check for it in base js and put the dev server dummy window file in
actual directory not the byond root.
* Renames the few things that had /final/ in typepath to ultimate since
final is a new keyword
And the very painful change:
`.proc/whatever` format is no longer valid, so we're replacing it with
new nameof() function. All this wrapped in three new macros.
`PROC_REF(X)`,`TYPE_PROC_REF(TYPE,X)`,`GLOBAL_PROC_REF(X)`. Global is
not actually necessary but if we get nameof that does not allow globals
it would be nice validation.
This is pretty unwieldy but there's no real alternative.
If you notice anything weird in the commits let me know because majority
was done with regex replace.
@tgstation/commit-access Since the .proc/stuff is pretty big change.
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Fixes a bug where MMIs would be sent into the nullspace room when in an MMI component inside of a BCI that is inserted into a BCI manipulation chamber.
Stores the BCI in the chamber's contents, instead of nullspace, allowing the MMI to talk, the BCI to still act as it would normally and overall just solves the issue and maybe some others alongside it.
Fixes#70349
Code improvements are much appreciated as some things may be rather hacky.
Adds more options to the currently very limited modsuit adapter shell. Right now you can only select a module and activate (not deploy) the suit.
This has some major problems as you literally can't even deploy the suit to activate it so that's rendered useless and selecting a module is like... kind of a weird input anyways but I won't judge so I left it in. Please comment down below if you'd like for me to add an "Activate Selected Module" input and "On Module Activated" output as those are certainly possible to do. I was just a little torn on how balanced that would be.
Changes:
"Module to Select" input is now an option. You can still use a string input, but simply inserting it into the suit and activating it, then accessing the circuit that way will give you a list of all modules that the modsuit has.
Modsuit quick deploy (RMB) no longer tries to deploy the rest of the pieces when used while the suit is only partially deployed. It will now instead retract the extended pieces. This makes the "Toggle Deployment" input less prone to errors. (Why was it like this in the first place? Having to manually retract the already extended pieces sucks ass.)
Added Inputs:
"Toggle Deployment" is a new signal input that does exactly what it says it does. It simply tries to extend or retract all pieces of the modsuit depending on it's current state.
Added Outputs:
"Activated" is a new number output that outputs 1 if the suit is activated and 0 if it's not.
"Deployed" is a new number output that outputs 1 if all parts of the suit are extended and 0 if they aren't.
"Deployed Parts" is a new string list output that outputs a list of the names of all currently deployed parts.
"On Deploy" is a new signal output that outputs a signal whenever all parts of the suit are deployed or retracted, regardless of the method used.
"Finished Toggling" is a new signal output that outputs a signal whenever the suit has finished activating or deactivating, regardless of the method used.
* Fix xeno hivemind talk causing hissing sound
* Fix dullahan speech arg
Add message_range and saymode to say arguments
Add new say args to other say procs
Add new say args to other say procs
* Revert "Fix dullahan speech arg"
This reverts commit abff2bec1a03c1270b2896faa547c465e046ad78.
* Fix speech_args to be list
* Refactor hulk speech signal handler
* Revert "Revert "Fix dullahan speech arg""
This reverts commit 58997930096ef6b7fa8a1c79395595e61db954c6.
* Change filterproof to be null like other say procs
* Remove unused COMSIG_MOB_SAY defines
* Readd defines for COMSIGH_MOB_SAY
Airlock shells made from airlock electronic and door assemblies would not trigger the 'Airlock Access Event' circuit component because the registered signals did not include the signals called by regular airlocks. This fixes that.
Adds keyboard shell.
Works very similar to the thought listener component for BCIs
It opens up an input panel when you use it (tgui_input_text)
Players with the illiterate quirk cannot use this shell. When they try to use it they get a warning message.
It's printed out as assembled (like compact remote or controller)
It can fit in a bag but not in a box
Has small capacity (SHELL_CAPACITY_SMALL)
Available after researching the Advanced Shells tech node
Can be printed from the component printer or the protolathe
Costs 2000 glass and 10000 iron sheets to print (slightly more than the controller shell)
Has 3 outputs. First one returns the entity who used the shell, second is the text that entity wrote and submitted, third one is triggered after the input window is closed. (by submitting, cancelling or just hitting the X button)
Icons (screenhots from the dream maker)
* Elevators are a bit more friendly part 1
- Emaggable elevator buttons / support for emaggable device assemblies
- Delayed travel between floors
- Elevators can now show a warning sign to areas below while travelling
- Elevators can now optionally wound heavily instead of gibbing
* Adds supoprt for "lift doors"
* Comment tweak
* Splitting these variables
* Functional prototype
* multiz debug
* Elevator button framework
* Unifies these behaviors
* Emergency doors
* Lift button framework
* UI closes on floor change
* Testing changes
* Fix
* UI Tweaks
* Panel works pretty swell
* Minor tweaks
* Move to static
* Bonus tram change
* User experience
* Slight tweak to mapload stuff
* This is silly
* Some UI tweaks, need to update css
* CSS and ui overhaul
* Documentation updates.
* Multi-z lift support
* Multitile lift fix
