* Module duplicator has cheaper costs for circuit duplication (#77180)
## About The Pull Request
Fixes#77158
> this is pretty clearly a relic of the resource cost rebalance.
Yes it is. `cost_per_component` var had a fixed value of 1000. Now it's
value is 1 /10th of `SHEET_MATERIAL_AMOUNT `
* Module duplicator has cheaper costs for circuit duplication
---------
Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com>
* [NO GBP]Mat container Final clean-up & patches (#77092)
## About The Pull Request
1. Fixes#77177
Some things were not connecting to the ore silo round start because the
silo was not initialized yet so it went to local storage. Now it
connects with the ore silo again
3. Removed some unused code in remote materials
4. Protolathe uses `eject_sheets()` defined in remote materials and not
it's own version because that's redundant
5. Don't put the item back in the players hand when inserting it in the
material container cause we haven't even removed it yet
6. `fast_split()` is now even faster & robust and is a global proc
7. Some code cleanup for RHD silo link
## Changelog
🆑
fix: some things not connecting to the ore silo round start
/🆑
* [NO GBP]Mat container Final clean-up & patches
---------
Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com>
* Material container & related stuff ui refactors & clean-up (#76220)
## About The Pull Request
**1. Material container clean-up & refactor**
- Replaced `total_amount` var with `total_amount()` proc, this var can
be easily computed by summing up all material amounts rather than
storing it as a var which is tedious to update & keep track of when
materials are added/removed
- Removed unused procs `transer_amt_to()`, `can_insert_amount_mat()`,
and `get_categories()`. These procs are not used anywhere in the
codebase so let's remove them & make some space.
- Callbacks are replaced with signals, the callbacks don't need to be
explicitly garbage collected & having macros & procs marked with
`SIGNAL_HANDLER` makes your intentions more readable & explicit.
- Fixes#76151
All material adding, removal, checking operations are "Integer"
operations, i.e. the final value is rounded & them made 1 if the final
value is 0 using the macro `OPTIMIZE_COST`[coudn't come up with a better
name]. No more dealing with decimal value materials
The problem was after the protolathe was upgraded with better parts all
the design costs were multiplied with a decimal `efficiency_coeff`
value, this means even though in the UI the cost was displayed as 60
bluespace crystals its actual cost was `60.0001` something in the
backend causing this check for materials to fail & print the error
message.
- Replaced `GetComponent(/datum/component_material_container)` with just
a simple ref to the material container when adding the component, so we
can save some overhead from calling this proc
- Gave all procs a ton of documentation with documentation having
documentation
- Fixes#76506 RCD and other devices that uses the silo link upgrade now
have the correct material usages
- Fixes#72096. It wasn't just a problem with ancient protolathe but
with all machines that used `datum/component/remote_materials` the
problem was remote materials would add an instance of
`datum/remote/material_container` if it wanted to use local storage but
this component would get added before `datum/component/remote_materials`
could be registered i.e. it comes before remote_materials in the
component list. So when the machine is destroyed it will first destroy
`material_container` & then `remote_materials` therefore destroying the
materials before they could get ejected
- Silo link is established when parent is registered with remote
materials raher than adding an external timer which is faster
- Everything that uses a material container will auto eject their sheets
when destroyed
- Moved this & remote materials into its own folder for better
organization
**2. Material UI Changes**
- Removed the x25 & x50 print buttons from the autolathe, now they just
have x5 & x10 buttons like the protolathe, These buttons were of no use
since you could just type the exact amount you want to print in the
`[Max: <some amount>]` side bar. The code to compute these buttons was
just plain right nasty & some of it unused in the UI.
- The material eject button in the material bar does not gray out when
you can eject exactly one sheet
- All material cost are integer values rounded
- Fixes#76253 Exosuit Fabricator sends the material container static
data to the UI so its material bar is not greyed out when there are
sufficient materials to eject
- Component printer material bar sends the material container static
data to the UI so its material bar is not greyed out when there are
sufficient materials to eject
- Autolathe Material bars now display number of sheets available
- Max printable amount of items are now computed & updated correctly in
the UI. They were displaying wrong values & now get updated when items
are printed, materials are removed
- Silo hold actually works now. When a machine is put on hold it calls
this proc
e929cf39cd/code/datums/components/remote_materials.dm (L78-L87)
Notice how the key is `src` so we should be consistent during checking
if a machine is on hold using the same `src` var. But for some reason we
did dumb shit like this
e929cf39cd/code/datums/components/remote_materials.dm (L150-L153)
What is category? Why do we care for the area the machine is in? None of
it made sense so i removed all that junk and just made it check for
`src` like it should
- Removed redundant `removable` & `sheets` var from the material
container ui_data. These vars are unused in the UI
- If an item does not have the required materials then upon clicking
that item you will not get any error message but instead nothing happens
## Changelog
🆑
fix: items can be printed from autolathe & protolathe when the exact
material amounts are present in them after upgrading
fix: max printable amount now shows the correct value & updates when
items are printed, materials are removed in the autolathe & protolathe
fix: component printer material bar is not greyed out when there are
sufficient materials to eject
fix: rcd and other devices that uses the silo link upgrade now have the
correct material usages
fix: silo hold actually works
fix: machines using local storage to hold materials will eject it's
materials as sheets when deconstructed/destroyed
refactor: Autolathe Material bars now display number of sheets available
refactor: printing an item that does not have enough materials will fail
silently with no error messages
refactor: Drone dispenser will eject sheets upon deconstruction
refactor: all things that store materials will auto ejects its sheets(if
there is sufficient material) when destroyed
refactor: inserting an item into the material container will display the
units consumed as sheets not absolute units
refactor: removed x25 & x50 print buttons from the autolathe
* Material container & related stuff ui refactors & clean-up
* Update ammo_workbench.dm
---------
Co-authored-by: SyncIt21 <110812394+SyncIt21@users.noreply.github.com>
Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com>
* No roundstart playable MULEs / Trampling requires hacking (#76837)
## 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)
/🆑
* No roundstart playable MULEs / Trampling requires hacking
* add missing arg
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
Co-authored-by: Pinta <68373373+softcerv@users.noreply.github.com>
Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com>
* Adds Radio Circuit Component Signaler to list-signalers (#76613)
## About The Pull Request
Fixes#76503
Probably important for this stuff to be logged.
## Why It's Good For The Game
Helps admins figure out the signallers that are signalling, and who
triggered the signaller.
## Changelog
🆑
admin: If a circuit component outputs a radio signal, it should now be
logged in list-signalers.
/🆑
* Adds Radio Circuit Component Signaler to list-signalers
---------
Co-authored-by: san7890 <the@san7890.com>
* MOD Complexity rebalance (#76077)
## 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.
/🆑
* MOD Complexity rebalance
---------
Co-authored-by: carlarctg <53100513+carlarctg@users.noreply.github.com>
* Fixes some stupid airlock sleeps
* Fixes the conflicts before checking the merge conflicts
* Converts another wires = to set_wires() and removes another issue
---------
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* Autolathe, protolathe, mech fab and comp printer now use defines for matter bins values. Also some production ui do. (#76020)
Changed hardcoded matter bins values to use defined
`SHEET_MATERIAL_AMOUNT` for following stuff: autolathe, protolathe, mech
fabricator and component printer.
`Material Access Bar` and `MaterialIcon` used for protolathes, circuit
printers and etc. now also use defined `SHEET_MATERIAL_AMOUNT`, via
static ui data, to prevent same issues in future.
Also changed some notes in /// parts just because why not.
* Autolathe, protolathe, mech fab and comp printer now use defines for matter bins values. Also some production ui do.
---------
Co-authored-by: Helg2 <93882977+Helg2@users.noreply.github.com>
* 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>
