* Fixes bypassing integrated circuit cooldowns with module components. (#75581)
## About The Pull Request
See title.
In order for this change to work, these components will not work if
there is no shell, but this will change nothing user-facing because all
player-facing circuits require shells to function in the first place
anyways.
## Why It's Good For The Game
Fixes a cooldown bypass bug.
Closes#75580
## Changelog
🆑
fix: Fixed bypassing component cooldowns with module components.
/🆑
---------
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* Fixes bypassing integrated circuit cooldowns with module components.
---------
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* Makes the component menu in the integrated circuit interface more intuitive. (#75364)
## About The Pull Request
Added a notice box to the component menu in the integrated circuit
interface explaining how to link an integrated circuit to a component
printer to allow for integrated circuit programming away from the
component printer.
Last sentence in the above image has been removed. Integrated circuits
will now update their static data once linked so closing and re-opening
the UI is unnecessary.
## Why It's Good For The Game
It wasn't clear anywhere in game that you could link integrated circuits
to component printers. I've run into players being completely unaware of
this feature, so this should help to make it more clear that players
don't need to print out components manually from the component printer
and slap them into an integrated circuit each time.
## Changelog
🆑
qol: Added a message to the component menu in the integrated circuit
interface that explains how to link an integrated circuit to a component
printer.
/🆑
---------
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* Makes the component menu in the integrated circuit interface more intuitive.
---------
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
Co-authored-by: Watermelon914 <3052169-Watermelon914@ users.noreply.gitlab.com>
* Refactors sheet crafting to better support directional construction (#74572)
## 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>
* Refactors sheet crafting to better support directional construction
* fex
* https://github.com/Skyrat-SS13/Skyrat-tg/pull/20636
---------
Co-authored-by: Bloop <vinylspiders@gmail.com>
Co-authored-by: san7890 <the@ san7890.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
* Removes networks from the game (#74142)
## About The Pull Request
This is a continuation of
https://github.com/tgstation/tgstation/pull/74085 - I announced in the
comments there that this would be my next PR, and this is it.
Removes SSnetwork, ``/datum/ntnet``,
``/datum/component/ntnet_interface``, ``var/network_root_id``, the
network unit test, and a lot of other things related to networks.
- NTNet circuits now check for an Ntnet relay, and uses signals to
operate.
- Logs in Wirecarp is now only for PDA and Ntnet Relay things, so you
can no longer see what ruins exist using it (why should Wirecarp know
that Oldstation spawned? The flavor is that they dont know its there).
- Removed it from MULEbots entirely, I don't think it even did anything
for them? Botkeeper seems to work without it, so it's possibly there
from pre-tgui PDAs.
- Moves assigning random names to a base proc instead of being tied to
network, this is things like random-naming scrubbers/vents. The behavior
hasn't changed at all.
- Makes Ntos work for consoles when relays are down, as the comments
said they're supposed to (because they're wired). I think this was an
accidental change on my part, so this is a revert of that.
## Why It's Good For The Game
Ntnet is ancient code that hasn't given us much that we can't do with
already existing alternatives, we've been slowly moving away from it for
init times, and though a large portion of that was limited to airlocks,
I still don't think this is a system worth keeping around.
It's way too complex to expect feature coders to do anything with it,
and too old with better alternatives for anyone to want to improve any
of it.
## Changelog
🆑
fix: Computers are now properly connected to Ethernet, and can use Ntos
when Relays are down.
refactor: Removes Ntnet and Ntnet interfaces, which was only used by
Ntnet circuits (which now directly checks for a Relay to work) and
MULEbots, which did nothing with it.
balance: Wirecarp no longer tells you what ruins spawned in a round,
instead it's limited to PDA logs, and tells you the source too. This
means the RD can catch someone running illegal programs if they don't
make any attempt at hiding it.
qol: Wirecarp logs is now set to save 300 at once, instead of 100 and
being increased to 300 by the RD during the round. This is pretty
insignificant, since there's no reason to NOT want as many logs as
possible.
/🆑
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@ users.noreply.github.com>
* Removes networks from the game
---------
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
Co-authored-by: Zephyr <12817816+ZephyrTFA@ users.noreply.github.com>
* Machines can now be pried open multiple times and maintain their initial densities (#74163)
## 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>
* Machines can now be pried open multiple times and maintain their initial densities
* wew
---------
Co-authored-by: Antonio Tosti <5588048+atosti@users.noreply.github.com>
Co-authored-by: san7890 <the@ san7890.com>
Co-authored-by: Gandalf <9026500+Gandalf2k15@users.noreply.github.com>
* Fix: DNA Infuser & Unit Tests, Organs Bugfixes (#73003)
>_"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
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.
🆑 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>
* *shrug
* Uncommented the line Gandalf wanted uncommented
* Properly fixes CI on this one, hopefully.
---------
Co-authored-by: Dani Glore <fantasticdragons@gmail.com>
Co-authored-by: Time-Green <timkoster1@hotmail.com>
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* Fixes admins having access to admin functions within normal integrated circuits whilst spawned in as a player. (#73904)
## About The Pull Request
Admins can currently save circuits and spawn components in whilst
adminned in integrated circuits that are not considered admin only. This
has been changed so that they can only access these functions when in
admin AI mode or when the integrated circuit is admin only.
Closes#71173
## Why It's Good For The Game
Playmins shouldn't have access to admin functions when playing the game
normally.
## Changelog
🆑
fix: Fixed playmins having access to admin functions within normal
integrated circuits.
/🆑
* Fixes admins having access to admin functions within normal integrated circuits whilst spawned in as a player.
---------
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
* Adds clarity to the associative list data type in wiremod (#73536)
## About The Pull Request
Once pulled, these changes will adjust how the associative list data
type is shown like on circuits and the description of the index table
component.
## Why It's Good For The Game
Given the entry difficulty level of the circuits system, some players
may find themselves overwhelmed and frustrated seeing that their index
table component's output is not connecting to the index list component's
input, despite there being an index associative list component they may
not be aware of. These changes should hopefully lead players to learn
more about associative lists and how different they are from normal
lists. Just adding "assoc." to the descriptor should lead players to
search the term in the component printer and find the index associative
table.
## Changelog
🆑
qol: Made associative lists more apparent in circuits.
/🆑
* Adds clarity to the associative list data type in wiremod
---------
Co-authored-by: CesarBaylina <72105993+CesarBaylina@users.noreply.github.com>
Don't initialize stack components inside machines (#72863)
## About The Pull Request
An attempt at the
[Initiative](https://github.com/tgstation/dev-cycles-initiative/issues/29)
all types/subtypes of `obj/item/stack` no longer exist inside any
machine. Only during deconstruction is the stack created from the
circuit boards requested components.
Also moved the component printer & module duplicator circuitboards into
`machine_circuitboards.dm` so they all are in one place
I was unable to do this for circuitboards because that still needs to
exist so we can use `apply_default_parts()` on the machine. I tried to
do the whole datum circuitboard approach just like with stock parts but
i'm unsure about it so maybe next time
## Changelog
🆑
refactor: stack components no longer exist inside a machine's
component_parts
refactor: move component printer & module duplicator circuitboards into
machine_circuitboards.dm
/🆑
Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com>
Checks if a machine has no research before connecting techweb (#72944)
## About The Pull Request
Currently all machines, if the config to not have a techweb link is on,
will set their node to science even if they were meant to be connected
to another (like through subtypes). This fixes that by checking to
ensure they don't have a techweb connected already before giving them a
new one.
Also as a minor fix, RD consoles will now properly add themselves to the
list of accessing RD consoles if they aren't linking to the default.
This list currently does nothing but I can see good uses of it in the
future.
## Why It's Good For The Game
Fixes an error that was found on a downstream, it's a worthwhile fix
that thankfully was caught this early.
## Changelog
Nothing player-facing.
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
Adds the 2 new components to the techweb (#72910)
## About The Pull Request
Adds the 2 new components I made in my prior PR to the basic circuit
research
also fix an issue with associative pick list
## Why It's Good For The Game
Being able to print them would be usefull
Reason I didn't notice was properly since I ran on debug station and it
never crossed my mind that they where research thingy
## Changelog
🆑
fix: You can print the new list pick and associative list pick
components
fix: Associative list pick works as intended now
/🆑
Co-authored-by: Autisem <36102060+Autisem@users.noreply.github.com>
* Stock Part Datumization Complete (#72559)
So i accidently reverted all my commits in #72511 when resolving a merge
conflict So ummm yeah fuck my bad anyway
Finishes what was started in #71693 and completes the
[initiative](https://github.com/tgstation/dev-cycles-initiative/issues/1)
Except for `obj/item/stock_parts/cell` and its subtypes. All machines
now use `datum/stock_part` for its requested components & component
parts
Not sure if i caught every machine & stuff in the game so merge with
caution
🆑
code: datum stock part for every obj stock part
refactor: all machines & dependent experiments to use datum stock parts
/🆑
* Fixes a teeny tiny Funce mistake :)
Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* Completely Culls req_access_txt/req_one_access_txt (#72281)
Hey there,
Now that every instance of `req_access` and `req_one_access` is a list
of strings, there is absolutely no reason for
req_access_txt/req_access_one_txt to exist. In fact, any instance where
they were still used in the codebase was very convoluted and was very
broken! Don't worry, I fixed it all out, and life is good.
I also dmdoc the surviving access variables, because those were missing.
I went on the side of caution and made a more verbose documentation with
an example just to have people really grasp this (it took me a while to
actually get it)
I believe that we changed _everything_ over to the
req_access/req_one_access system earlier this year in VV, but the
problem is that _new mappers don't understand the difference between the
two systems_. In fact, the "txt" system is completely redundant since
all it does is transition stuff to the "base" system. So, let's just
completely cull the one that's all but deprecated and ensure this
confusion no longer arises. The whole purpose of "txt" seemed to be to
convert the access, but it's all pointless now that we can just read the
list directly.
I'm also 99% certain that the "access check" on vending machines broke
(and didn't seem to have correct logic in the first place? I
legitimately couldn't find a case where it could fail in testing, so I
changed that up), and that's fixed up now. Let me know if I was clueless
there. I know it's short-circuiting now as opposed to "all must be
true", but it just didn't work.
* Completely Culls req_access_txt/req_one_access_txt
* oh the misery
* makes them use the thing that actually works
* test to see if engineering access is breaking it
* Revert "test to see if engineering access is breaking it"
This reverts commit 3cc2c554ff18f435a51601782e64c76193298db7.
* Fix access checks when req_access is null (#72458)
## About The Pull Request
Fixes#72450 - This seems to be an oversight in some of the access
refactors we've been through recently. When there was an assumption in
`check_access_list()` that `req_access` would always be a list, and that
if it was not something terrible had gone wrong and the door should
default to public access.
With the cleanup of the _txt access vars and the introduction of mapping
access helpers, this assumption is no longer true. `req_access` will be
null when multiple helpers are painted onto the same door, so we need to
handle that properly. Thanks to @MrMelbert for spitting out the attached
fix in mapping general and letting me PR it after testing.
This really needs a suite of unit tests around it. San has helpfully
volunteered to work on that for three hours before getting frustrated.
## Why It's Good For The Game
No more public access to engineering lobby, lathe, etc.
## Changelog
🆑 Vire, MrMelbert
fix: The engineering lobby and lathe are no longer public access
fix: Doors will no longer be treated as public access when they have
multiple accesses set on them
/🆑
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Paxilmaniac <paxilmaniac@gmail.com>
Co-authored-by: Vire <66576896+Maurukas@users.noreply.github.com>
Co-authored-by: Tastyfish <crazychris32@gmail.com>
Add lints for idiomatic balloon alert usage (#72280)
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>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
* Crafting/Cooking menu update
* Yeeted away all of the merge conflicts, time to fix the code
* Okay, now it compiles, and after testing, it seems to work just fine
* Actually, early addition of an upstream fix, so those that don't have hunger can still open the cooking menu
* Fixes the units tests by removing the extra comma in the Stuffed Muli Pod recipe
Co-authored-by: Andrew <mt.forspam@gmail.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com>
* Admin Subtype of Integrated Circuits (#72303)
## About The Pull Request
Simply adds an admin only subtype of the integrated circuit because I
spawn a lot and this'll save me 30 or so seconds each time I do.
## Why It's Good For The Game
When creating a new admin circuit from scratch being able to skip VVing
it to change the admin_only var would save a bit of time.
## Changelog
🆑
admin: Integrated Circuits now have an admin only subtype, functionally
the same as VVed regular circuits.
/🆑
* Admin Subtype of Integrated Circuits
Co-authored-by: NamelessFairy <40036527+NamelessFairy@users.noreply.github.com>
* View Sensor circuits now have a range modifier (#72123)
## About The Pull Request
Adds the ability to use ranges between 0 and 5 for View Sensor circuits.
Currently these nodes are locked to 5 tiles and it is rather difficult
to limit the area this circuit effects either for speed reasons or
otherwise. This PR makes it a simple variable that remains capped at 5,
admins can raise the cap by modifying a variable.
## Why It's Good For The Game
I mostly use circuits as an admin, I can't for the life of me figure out
how to make a shorter range AOE circuit although I imagine its possible
by comparing x and y coordinates of things in the list and yourself this
is far to finicky. Players can also utilize this to, for example check
all objects on the tile the view sensor is on, "possible" at the moment
but way to finicky compared to a 5 tiles.
## Changelog
🆑
qol: You can now reduce the range of View Sensor circuits.
/🆑
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* View Sensor circuits now have a range modifier
Co-authored-by: NamelessFairy <40036527+NamelessFairy@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
* Saycode refactor, unit tests, and fixes
* parrot
* SR tweaks
* say tests from pstream/71873
Co-authored-by: Tim <timothymtorres@gmail.com>
Co-authored-by: tastyfish <crazychris32@gmail.com>
* ModuleDuplicator & ComponentPrinter now benefit from upgraded parts (#71183)
**About the pull request**
Module Duplicator & Component Printer now provide more local storage and
cheaper production costs when upgraded with better matter bins &
manipulators respectively. Previously this wasn't the case
**Why its good for the game**
Better parts mean lower costs and more storage. Thats always a good
thing
**Change Log**
🆑
add: Module Duplicator & Component Printer now get extra storage &
reduced costs from more efficient parts
/🆑
Co-authored-by: Time-Green <timkoster1@ hotmail.com>
* ModuleDuplicator & ComponentPrinter now benefit from upgraded parts
Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com>
Co-authored-by: Time-Green <timkoster1@ hotmail.com>
* Save 0.6-0.7s of init time by splitting registering lists of signals into its own proc, and optimizing QDELETED
* modular RegisterSignals
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: tastyfish <crazychris32@gmail.com>
* Fixes an exploit with stacking igniters. Refactors some assembly flag oddities. Limits assembly holders at 12 assemblies. (#71264)
## 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.
/🆑
* Fixes an exploit with stacking igniters. Refactors some assembly flag oddities. Limits assembly holders at 12 assemblies.
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Adds a reagent injector component and BCI manipulators to all circuit labs (#71236)
<!-- 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>
* Adds a reagent injector component and BCI manipulators to all circuit labs
Co-authored-by: RikuTheKiller <88713943+RikuTheKiller@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@ users.noreply.github.com>
Co-authored-by: Paxilmaniac <paxilmaniac@gmail.com>
* Adds support for non-science techwebs (+Config) (#71070)
## About The Pull Request
This is an expanding of
https://github.com/tgstation/tgstation/pull/69708
Adds a config to not connect machines to a techweb at the start of a
round
Adds the ability to multitool a server to get its techweb in its buffer,
which can then be used on machines to sync them.
Adds support for some machines to not cry when they don't have a techweb
linked to it, in case they actually don't.
If the config to not have machines connected to the science server is
enabled, research servers will make their own techwebs instead. This is
barebones though and would need more work if this option is used.
For misc stuff:
- I replaced checking ``GLOB.machines`` for research servers, to instead
check ``SSresearch.servers``, where we can use ``as anything``.
- Removed unused vars on the RD server control
- I renamed the operating computer's .dm file to remove the capitalized
letter from it. It's now operating_computer instead of Operations.
## Why It's Good For The Game
This is adding support for 2 different cases that can be used in the
future:
1. Off-station roles, we can make roles like Oldstation have their own
techweb so they don't ruin science's efforts, or use their advanced
research to get things we don't want, or even possibly have some
blacklist webs for ghost roles (like teleporters) so that way we don't
need to have this dance where we have to give them a very specific
amount of materials for them to do things while not being able to get a
teleporter and leaving. I heard discussions that people wanted this a
while back, and one of the main things preventing this from happening is
the lack of support. Hopefully this is encouragement to make it a
reality, because I think it would be a really cool expansion of ghost
roles and a good way to prevent them from messing with the round in
progress.
2. Downstreams who want to do different things with Science. Personally
I made this PR with voidcrew(shiptest) in mind and think this would make
their lives easier. I didn't expand too much on this because I'm leaving
up mostly to the downstreams to figure out what they want to do with
these systems.
## Changelog
This generally isn't really player facing, since most of the changes
would only come into effect if the config is enabled??
🆑
fix: Research servers now only show servers connected to their techweb.
/🆑
* Adds support for non-science techwebs (+Config)
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
* [s] Dead people can no longer communicate with the living (#70446)
* [s] Dead people can no longer communicate with the living
Thought listener, through chicanery, could let you still pass through valid strings (and not fail) if you were a mob/dead/observer occupying your mob/living body. god dammit. check to make sure the fucker is dead.
* [s] Dead people can no longer communicate with the living
Co-authored-by: san7890 <the@san7890.com>
* BCIs are now stored in the manipulation chamber's contents, instead of nullspace (#70350)
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
* BCIs are now stored in the manipulation chamber's contents, instead of nullspace
Co-authored-by: RikuTheKiller <88713943+RikuTheKiller@users.noreply.github.com>
* TGUI for Techfabs II: The Great Recategorizing (AND ICONS) (AND MECHFABS) (AND AUTOLATHES)
* Still doesn't compile but there's no more conflicts
* [PR PR] Makes #16616 Compile And Work (#16656)
Oh hey, it compiles!
Co-authored-by: scriptis <scriptif@gmail.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
Co-authored-by: RimiNosha <106692773+RimiNosha@users.noreply.github.com>
* Upgrades the Modsuit Adapter Shell (#70286)
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.
* Upgrades the Modsuit Adapter Shell
Co-authored-by: RikuTheKiller <88713943+RikuTheKiller@users.noreply.github.com>
* Fix xeno hivemind talk causing hissing sound (#69844)
* 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
* Fix xeno hivemind talk causing hissing sound
* Updates the arguments of the say and whisper procs for the borers
Co-authored-by: Tim <timothymtorres@gmail.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* Fixed airlock shells made from airlock electronics not triggering AAE circuit component (#69992)
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.
* Fixed airlock shells made from airlock electronics not triggering AAE circuit component
Co-authored-by: Watermelon914 <37270891+Watermelon914@users.noreply.github.com>
* Changes reagentscanner circuit component to use Table (#69745)
Changes components\atom\reagentscanner to use table list from Assoc list.
Added purity output to components\atom\reagentscanner.
At time of making this its impossible to iterate through the output of reagentscanner via loops or numerical index and to determine the amount or the reagent scanned you needed to know its associated value which is less than idea.
Queried this issue on coderbus meeting 3 then asked Watermelon and he agreed that a change would be good.
Added a "purity" to the table outputs to make shells of this component "desirable" to chemistry who need to use Ph_meter to check exact purity. If this not allowed I’m willing to make an \atom\reagentscanner\adv variant that will comparable to Ph_meter.
I intend to give the same treatment to materialscanner.
* Changes reagentscanner circuit component to use Table
Co-authored-by: Dmeto <75919495+Dmeto@users.noreply.github.com>
