## About The Pull Request
1. Removes material breakdown flags i.e. all flags with the format
`BREAKDOWN_XXX`. These flags do nothing, there are no special checks to
transform materials based on these flags, they are passed around just
because certain procs require them for syntax purposes only.
Apparently there were plans to make these flags do something special
from the comment
302247c0d1/code/__DEFINES/construction/material.dm (L43)
But nobody got any ideas for years now. The only special thing we can do
with them now is remove them and reduce code clutter, so let's do that
The only flag that ever did something was the
`BREAKDOWN_INCLUDE_ALCHEMY` flag. This only worked when coupled together
with `TRAIT_MAT_TRANSMUTED` trait(which is only used by the reagent
metalgen) and when both this trait & flag are combined together... they
still do nothing
302247c0d1/code/game/atom/atom_materials.dm (L41-L42)
Yup they cancel out each other to prevent returning an empty list, the
traits only job was to prevent materials from being recycled (like why?
what's the benefit of that? nothing) and the flag was meant to bypass
this restriction so both the trait & the flag cancel out each other
therefore doing nothing meaningful. Best remove them both and call it a
day.
2. Fixes an error in displaying number of sheets inserted into a mat
container when that sheet is made up of alloy materials. it would count
as 2 or more because it would take the sum of total material amount
inserted and not the actual sheets. That's fixed now.
3. Remote materials now properly respect the `MATCONTAINER_NO_INSERT`
flag
4. Adds helper proc to insert materials via the remote material
component with proper context
## Changelog
🆑
fix: mat container displays correct number of sheets inserted for alloy
materials.
fix: remote materials now properly respect the `MATCONTAINER_NO_INSERT`
flag.
code: removes material breakdown flags and related traits.
code: adds helper proc to insert materials via the remote material
component with proper context.
/🆑
## About The Pull Request
This PR makes several changes to how circuit action buttons work:
- The MOD action and BCI action components have been merged into a
single component.
- MOD circuit actions can be pinned from the configuration menu. This
works the same way as pinning individual modules, and can be done both
by the wearer and a suit AI.
- Action components have an output pin for the user of the action. This
allows MOD module circuits to distinguish between the wearer and an AI.
- Creates a supertype for `/datum/action/item_action/mod/pinned_module`
named `/datum/action/item_action/mod/pinnable`, which implements common
functionality for pinned modules and pinned circuit module actions.
## Why It's Good For The Game
The prior functionality of circuit MOD actions was somewhat unintuitive,
requiring the user to select an action from a radial menu *after*
activating the module, whether from a pinned action or from the module
radial. Providing similar pinning functionality to modules themselves
makes MOD actions more readily usable.
Merging the two different types of circuit components into one was made
with the idea that adding new types of shells with equipment actions
would inflate the number of subtypes of
`/obj/item/circuit_component/equipment_action` without adding much
meaningful functionality.
## Changelog
🆑
qol: MOD wearers and internal AIs can pin the individual actions in a
MOD circuit module in a similar way to how they can pin modules. Circuit
module actions can be pinned from the configuration menu of the circuit
refactor: The MOD action and BCI action components have been merged into
one component - the Equipment Action component.
/🆑
<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may
not be viewable. -->
<!-- You can view Contributing.MD for a detailed description of the pull
request process. -->
closes#53931, #70916, #53931
## About The Pull Request
Organs were previously stored in nullspace. Now they are stored in their
prospective bodyparts. Bodyparts are now stored in the mob.
I've also had to refactor a lot of code concerning organ movement.
Previously, organs were only moved into bodyparts once the bodyparts
were removed. To accomodate this change, two major distinctions have
been made:
**Bodypart removal/insertion**
Called only when an organ is taken out of a bodypart. Bodypart overlays,
damage modifiers or other changes that should affect a bodypart itself
goes here.
**Mob insertion/removal**
Called when an organ is removed from a mob. This can either be directly,
by taking the organ out of a mob, or by removing the bodypart that
contains the organ. This lets you add and remove organ effects safely
without having to worry about the bodypart.
Now that we controle the movement of bodyparts and organs, we can fuck
around with them more. Summoning someones head or chest or heart will
actually kill them now (and quite violently I must say (chest summoning
gibs lol)).
https://github.com/tgstation/tgstation/assets/7501474/5efc9dd3-cfd5-4ce4-b70f-d0d74894626e
I´ve also added a unit test that violently tears apart and reconstructs
a person in different ways to see if they get put toghether the right
way
This will definitely need a testmerge. I've done a lot of testing to
make sure interactions work, but more niche stuff or my own incompetence
can always slip through.
## Why It's Good For The Game
<!-- Argue for the merits of your changes and how they benefit the game,
especially if they are controversial and/or far reaching. If you can't
actually explain WHY what you are doing will improve the game, then it
probably isn't good for the game in the first place. -->
A lot of organ work is quite restricted. You can't C4 someones heart,
you cant summon their organs and a lot of exceptions have to be made to
keep organs in nullspace. This lets organs (and bodyparts) play more
nicely with the rest of the game. This also makes it a lot easier to
move away from extorgans since a lot of their unique movement code has
been removed and or generalized.
I don't like making PRs of this size (I'm so sorry reviewers), but I was
in a unique position to replace the entire system in a way I couldn't
have done conveniently in multiple PRs
## Changelog
<!-- If your PR modifies aspects of the game that can be concretely
observed by players or admins you should add a changelog. If your change
does NOT meet this description, remove this section. Be sure to properly
mark your PRs to prevent unnecessary GBP loss. You can read up on GBP
and it's effects on PRs in the tgstation guides for contributors. Please
note that maintainers freely reserve the right to remove and add tags
should they deem it appropriate. You can attempt to finagle the system
all you want, but it's best to shoot for clear communication right off
the bat. -->
🆑
refactor: Your organs are now inside your body. Please report any issues
with bodypart and organ movement, including exotic organ, on github and
scream at me
fix: Cases of unexpected organ movement, such as teleporting bodyparts
and organs with spells, now invokes a proper reaction (usually violent
death)
runtime: Fixes HARS runtiming on activation/deactivation
fix: Fixes lag when species swapping
/🆑
<!-- Both 🆑's are required for the changelog to work! You can put
your name to the right of the first 🆑 if you want to overwrite your
GitHub username as author ingame. -->
<!-- You can use multiple of the same prefix (they're only used for the
icon ingame) and delete the unneeded ones. Despite some of the tags,
changelogs should generally represent how a player might be affected by
the changes rather than a summary of the PR's contents. -->
## About The Pull Request
I woke up today and thought 'what would be easy thing to do today so I
can say I've done something?'. Then I remembered I saw several gangtool
usages the time I split radio up, and I could remedy those. 7 hours
later, device.dmi is split in a folder of its own, and I've also given
unique sprites to door remotes and landing desginators.
## Why It's Good For The Game
The device.dmi was kind of a mess.
## Changelog
🆑
/🆑
## About The Pull Request
I've stumbled across this enough to finally go through the entire
codebase and fix it. I left out changelogs simply because rewriting
history logs is bad.
## Why It's Good For The Game
I find it pretty annoying because I stumble across words that are
misspelled for a few seconds, and I'm likely not the only one who feels
like this. Less spelling mistakes in code are better.
## Changelog
🆑
spellcheck: Occurrences of "recieve" has been changed to "receive".
/🆑
## About The Pull Request
Adds an arctangent 2 component (atan2)
## Why It's Good For The Game
It's made to convert offsets into angles, something thats pretty useful
in a coordinate based game
## Changelog
🆑
add: Adds an arctangent2 component to circuitry!
/🆑
## About The Pull Request
Third /icon/ cleansing splinter 1. Comments on commits say all it does
pretty much.
## Why It's Good For The Game
Inhand for walkietalkie was requested in the project, gets rid of some
usecases of old 'gangtool', headset splitoff requested by Fazzie.
Inhands reflecting the items they are supposed to represent is nice.
## Changelog
🆑
image: Following now have unique item sprites: syndicate war declaration
radio, curator and chief beacon's, chaplain beacon.
image: Following now have unique inhand sprites: radio, export scanner,
walkie-talkie, syndicate war declaration radio, curator and chief
beacon's, chaplain beacon.
/🆑
## About The Pull Request
Added a user type to integrated circuits that can't be stored as a user
type but can be typecasted to entity. Useful for components that
directly ask for an input from the user, like the list pick component.
Refactored the list pick component to use this user port and to also
send failure signals whenever a success signal is not sent.
Removed the triggered port for the list pick component.
Also fixes a runtime that occurs with the list pick component if the
list passed in only contains null values.
## Why It's Good For The Game
Can't force a prompt onto people who haven't interacted with your
circuit.
## Changelog
🆑
add: Added a user type to integrated circuits
/🆑
---------
Co-authored-by: Watermelon914 <3052169-Watermelon914@users.noreply.gitlab.com>
## About The Pull Request
Title
## Why It's Good For The Game
Less headache in the future for a macro thats not really obvious in what
it does
## Changelog
🆑
fix: signals in circuits now actually function
/🆑
## About The Pull Request
See title.
If someone was abusing signalers previously to cause server lag, going
into list signalers would actually cause even worse lag as byond sat
there and processed thousands of items into a string over and over,
which would cause string format operations on longer and longer strings,
resulting in more and more overhead. This is bad.
So instead there is now a limit to the size of the list, currently I
have that set to 500 although I am open to increasing and even reducing
the number.
I have also made signalers slightly more intuitive by having the
cooldown actually displayed in the ui as a tooltip instead of just being
a secret feature you didnt know about unless you code dived. Also made
the cooldown actually respected by things such as circuitry where it
didnt even implement the cooldown and would happily send as many signals
as you had items connected to your proximity circuit.
## Why It's Good For The Game
Admins won't accidentally kill the server by trying to parse a lag
machines signal list. Players lagging the server? No, how about the
admins trying to fix it!
## Changelog
🆑
qol: signalers now tell you their cooldown and also use balloon alerts
/🆑
## About The Pull Request
Implements /datum/pathfind/sssp, which generates /datum/path_map
/datum/path_maps allow us to very efficently generate paths to any turf
they contain from their central point.
We're effectively running the single source shortest paths algorithm.
We expand from the center turf, adding turfs as they're found, and then
processing them in order of addition.
As we go, we remember what turf "found" us first. Reversing this chain
gives us the shortest possible path from the center turf to any turf in
its range (or the inverse).
This isn't all that useful on its own, outside of a few niche cases
(Like if we wanted to get the farthest reachable turf from the center)
but if we could reuse the map more then once, we'd be able to swarm
to/from a point very easily.
Reuse is a bit troublesome, reqiures a timeout system and a way to
compare different movables trying to get paths.
I've implemented it tho. I've refactored CanAStarPass to take a datum,
/datum/can_pass_info. This is built from a movable and a list of access,
and copies all the properties that would impact pathfinding over onto
itself.
There is one case where we don't do this, pathing over openspace
requires checking if we'd fall through the openspace, and the proc for
that takes an atom.
So instead we use the weakref to the owner that we hold onto, and hold
copies of all the values that would impact the check on the datum.
When someone requests a swarmed path their pass info is compared with
the pass info of all other path_maps centered on their target turf. If
it matches and their requested timeout isn't too short, we just reuse
the map.
Timeout is a tricky thing because the longer a map exists the more out
of date it gets.
I've added a few age defines that let you modulate your level of risk
here. We default to only allowing maps that are currently
being generated, or finished generating in our tick.
Hopefully this prevents falling into trouble, but consumers will need to
allow "failed" movements.
As a part of this datumized pass info, I've refactored pathfinding to
use access lists, rather then id cards directly. This also avoids some
dumbass harddel oppertunities, and prevents an idcard from changing mid
path.
Did a few things to the zPass procs, they took args that they did NOT
need, and I thought it'd be better to yeet em.
If you'd all like I could undo the caching/can_pass_info stuff if you'd
all like. I think it's useful generally because it avoids stuff changing
mid pathfind attempt, but if it's too clunky I could nuke it.
Oh also I added optional args to jps that constricts how it handles
diagonals. I've used this to fix bot paths.
## Why It's Good For The Game
Much of this is redundant currently. I'm adding it because it could have
saved hugglebippers, and because I get the feeling it'll be useful for
"grouping" mobs like bees and such.
We're doing more basic mob work currently and I want to provide extra
tools for that work.
https://github.com/tgstation/tgstation/assets/58055496/66aca1f9-c6e7-4173-9c38-c40516d6d853
## Changelog
🆑
add: Adds swarmed pathfinding, trading accuracy for potential
optimization of used correctly
fix: Bots will no longer take diagonal paths, preventing weirdo looking
path visuals
refactor: Refactored bits of pathfinding code, hopefully easier to add
new pathfinding strategies now
/🆑
## About The Pull Request
This takes all the gib related procs:
- `gib()`
- `spawn_gibs()`
- `spill_organs()`
- `spread_bodyparts()`
And adds heavy documentation that communicates what the procs are used
for and how the different bitflags affect them. The difference is
noticeable:
`gib(TRUE, FALSE, FALSE, null)` vs `gib(DROP_ORGANS|DROP_BODYPARTS)`
The code is now much more legible which is important considering it's
used in a lot of places!
Another robust change, is that we had several places in the code where
there were double negatives like so:
```
/mob/living/carbon/spill_organs(no_brain, no_organs, no_bodyparts)
if(!no_bodyparts) // DOUBLE NEGATIVES ARE BAD M'KAY?!?
// do stuff here
```
This is a mindfuck to untangle. I inverted a lot of these parts so we
don't lose our sanity.
Last thing that was changed was a big `if()` loop in the `spill_organ()`
proc. This was refactored to just be a simple `for` loop with `continue`
statements where we needed to skip enabled bitflags. It's now shorter
and cleaner than before.
The only slight gameplay change this affects is that gibbing a mob now
guarantees to drop all items unless the `DROP_ITEMS` bitflag is
deliberately omitted. Some places like admin gib self, we don't want
this to happen.
## Why It's Good For The Game
Gib code is very old. (~15 years) People kept adding more arguments to
the procs when it should have been a bitflag initially. By doing it this
way, there is more flexibility and readability when it comes to adding
new code in the future.
## Changelog
🆑
refactor: Refactor gib code to be more robust.
qol: Gibbing a mob will result in all items being dropped instead of
getting deleted. There are a few exceptions (like admin gib self) where
this will not take place.
/🆑
## About The Pull Request
This PR does many things and I expect to be asked to atomize some stuff.
### Oldstation Additions
Oldstation now has their own research server, generating their own
points. To help alleviate major concerns, they have a few stuff to help
with this:
- They now have a pre-built operating computer
- They now have an Autopsy scanner
- They now have access to Experimental Dissection
Experimental Dissection is the old dissection, giving research points in
the form of paper notes on completion. They must be turned in to the RND
server (only works on the Oldstation one, so you can't abuse this) for
points. This was an idea I've had for some time, as Oldstation is used
somewhat as a representation of how ss13 used to be (through its use of
directional windows (before they got removed, but I'd like to bring them
back), old IDs, RTGs, and old engines before they got removed from the
game fully)
Considering there are 11 alien mobs in Oldstation, there is 27.5k
research points to get from alien corpses, enough to bring them up to
speed with whatever they wish to do. This is their 'alternative' for
experiments (which they can still do if they want, but it is very hard
to do, outside of dissection which is needed for the node).
This surgery isn't repeatable, isn't upgradable, and isn't removed by
being healed. It is not mutually exclusive with autopsy (so you can't
ruin yourself doing the wrong surgery).
### Other stuff
- Ninjas now drain RND points from the server they drain from, rather
than always hitting science
- Syncing machines to research roundstart is now a macro, and now
immediately syncs to a server on your Z-level. Machines will
automatically connect to the Science servers if none else are available.
### non-player facing
- Science, Admin, and Oldstation techwebs are now no longer vars on
research, but stored in research's list of techwebs.
- ``get_available_servers`` and ``find_valid_servers`` are now procs on
the research subsystem, rather than the experisci component.
- Oldstation code has been split into separate files.
## Why It's Good For The Game
Oldstation is one of my favorite ruins, but it is also one of the
largest complaints for RND (along with Golems) because they use the
station's Science nodes & points (I recently tried de-hardcoding Science
stuff to help prepare for this, but I didn't get everything in advance).
The complaint stems from these ghost roles, who are meant to be a fun
activity to do while waiting for the next round, using the station's
research points for their own stuff, completely untrackable unless
someone goes out of their way to grief a ghost spawn just for using
points to get things they need. These roles make their own servers to
drain the station, and I find that unfun and quite boring for everyone-
it's also not very flavorful, why would Charliestation know of the
station's RND to take advantage of it?
This hopes to fix those issues, make Charliestation more worthwhile, and
more flavorful.
## Changelog
🆑
fix: Getting a node researched now properly makes it no longer hidden.
fix: Ninjas draining RD servers now drains it from the connected
techweb, rather than sniping Science.
balance: Machines will first try to connect to a techweb with servers on
their z-level, with the Science techweb remaining as fallback.
add: Oldstation RND, comes with their own Techweb and special surgery to
gain research points through dissecting Xenomorphs.
/🆑
1. Removes `/obj/machinery/ore_silo/proc/remote_attackby()`. This proc
calls `datum/component/material_container/user_insert()` anyway which
performs all the checks necessary for inserting stuff into the ore silo
and `/obj/machinery/ore_silo/proc/remote_attackby()` was just repeating
its code & checks. So now inserting into the ore silo is directly
handled by the mat container without this proxy proc making the
operation slightly faster
2. Removed silo `attackby` code. Same operations can be done via
`screwdriver_act` & `crowbar_act` procs much cleaner
3. The ore silo now hooks onto signals
`COMSIG_MATCONTAINER_ITEM_CONSUMED` and
`COMSIG_MATCONTAINER_SHEETS_RETRIVED` and logs into silo when they are
triggered. This means when you insert/eject sheets from the silo the
connected machine performing the operation no longer has to do the
logging manually thus the proc `silo_log` has been removed from a lot of
places ,reducing overall code size
4. A lot of stuff that use materials from the ore silo follow this
pattern.
i.e. They first use the materials from the silo and then log it via
`silo_log` proc. This code pattern is repeated in a lot of places so
let's just merge these 2 lines with some extra sanity checks into a
single proc inside `remote_materials` itself. That's what was done and
the number of places where you log manually into the silo has been
removed further reducing code size everywhere.
5. Added auto doc & cleaned up some procs
Since logging is now done by the ore silo directly, we need a way to
pass the machine that is inserting items into the silo to the signal
handlers of the ore silo [via the `context` var]. So other code changes
elsewhere is because of this var
## About The Pull Request
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 `
## About The Pull Request
1. Fixes#77177
Some things were not connecting to the ore silo round start because the
silo was not initialized yet so it went to local storage. Now it
connects with the ore silo again
3. Removed some unused code in remote materials
4. Protolathe uses `eject_sheets()` defined in remote materials and not
it's own version because that's redundant
5. Don't put the item back in the players hand when inserting it in the
material container cause we haven't even removed it yet
6. `fast_split()` is now even faster & robust and is a global proc
7. Some code cleanup for RHD silo link
## Changelog
🆑
fix: some things not connecting to the ore silo round start
/🆑
## About The Pull Request
**1. Material container clean-up & refactor**
- Replaced `total_amount` var with `total_amount()` proc, this var can
be easily computed by summing up all material amounts rather than
storing it as a var which is tedious to update & keep track of when
materials are added/removed
- Removed unused procs `transer_amt_to()`, `can_insert_amount_mat()`,
and `get_categories()`. These procs are not used anywhere in the
codebase so let's remove them & make some space.
- Callbacks are replaced with signals, the callbacks don't need to be
explicitly garbage collected & having macros & procs marked with
`SIGNAL_HANDLER` makes your intentions more readable & explicit.
- Fixes#76151
All material adding, removal, checking operations are "Integer"
operations, i.e. the final value is rounded & them made 1 if the final
value is 0 using the macro `OPTIMIZE_COST`[coudn't come up with a better
name]. No more dealing with decimal value materials
The problem was after the protolathe was upgraded with better parts all
the design costs were multiplied with a decimal `efficiency_coeff`
value, this means even though in the UI the cost was displayed as 60
bluespace crystals its actual cost was `60.0001` something in the
backend causing this check for materials to fail & print the error
message.
- Replaced `GetComponent(/datum/component_material_container)` with just
a simple ref to the material container when adding the component, so we
can save some overhead from calling this proc
- Gave all procs a ton of documentation with documentation having
documentation
- Fixes#76506 RCD and other devices that uses the silo link upgrade now
have the correct material usages
- Fixes#72096. It wasn't just a problem with ancient protolathe but
with all machines that used `datum/component/remote_materials` the
problem was remote materials would add an instance of
`datum/remote/material_container` if it wanted to use local storage but
this component would get added before `datum/component/remote_materials`
could be registered i.e. it comes before remote_materials in the
component list. So when the machine is destroyed it will first destroy
`material_container` & then `remote_materials` therefore destroying the
materials before they could get ejected
- Silo link is established when parent is registered with remote
materials raher than adding an external timer which is faster
- Everything that uses a material container will auto eject their sheets
when destroyed
- Moved this & remote materials into its own folder for better
organization
**2. Material UI Changes**
- Removed the x25 & x50 print buttons from the autolathe, now they just
have x5 & x10 buttons like the protolathe, These buttons were of no use
since you could just type the exact amount you want to print in the
`[Max: <some amount>]` side bar. The code to compute these buttons was
just plain right nasty & some of it unused in the UI.
- The material eject button in the material bar does not gray out when
you can eject exactly one sheet
- All material cost are integer values rounded
- Fixes#76253 Exosuit Fabricator sends the material container static
data to the UI so its material bar is not greyed out when there are
sufficient materials to eject
- Component printer material bar sends the material container static
data to the UI so its material bar is not greyed out when there are
sufficient materials to eject
- Autolathe Material bars now display number of sheets available
- Max printable amount of items are now computed & updated correctly in
the UI. They were displaying wrong values & now get updated when items
are printed, materials are removed
- Silo hold actually works now. When a machine is put on hold it calls
this proc
e929cf39cd/code/datums/components/remote_materials.dm (L78-L87)
Notice how the key is `src` so we should be consistent during checking
if a machine is on hold using the same `src` var. But for some reason we
did dumb shit like this
e929cf39cd/code/datums/components/remote_materials.dm (L150-L153)
What is category? Why do we care for the area the machine is in? None of
it made sense so i removed all that junk and just made it check for
`src` like it should
- Removed redundant `removable` & `sheets` var from the material
container ui_data. These vars are unused in the UI
- If an item does not have the required materials then upon clicking
that item you will not get any error message but instead nothing happens
## Changelog
🆑
fix: items can be printed from autolathe & protolathe when the exact
material amounts are present in them after upgrading
fix: max printable amount now shows the correct value & updates when
items are printed, materials are removed in the autolathe & protolathe
fix: component printer material bar is not greyed out when there are
sufficient materials to eject
fix: rcd and other devices that uses the silo link upgrade now have the
correct material usages
fix: silo hold actually works
fix: machines using local storage to hold materials will eject it's
materials as sheets when deconstructed/destroyed
refactor: Autolathe Material bars now display number of sheets available
refactor: printing an item that does not have enough materials will fail
silently with no error messages
refactor: Drone dispenser will eject sheets upon deconstruction
refactor: all things that store materials will auto ejects its sheets(if
there is sufficient material) when destroyed
refactor: inserting an item into the material container will display the
units consumed as sheets not absolute units
refactor: removed x25 & x50 print buttons from the autolathe
## About The Pull Request
Prevailing feedback has been:
- The player base cannot be trusted to control MULEbots.
- It should be clearer what bots can and can't do.
The former is easy to fix.
The latter is sort of a matter for policy but I'm going to investigate
giving bots a rudimentary laws system. Plus that sounds much more
controversial than this so I am going to atomise this outside of that
PR.
MULEbots can still be set to allow sentience by cargo technicians, but
don't start that way.
ADDITIONALLY this PR just changes it so that MULEbots do not crush
people unless:
- They have been emagged.
- Their safety wire has been cut.
Either means works, so it's not too hard to access for nefarious
purposes, but hard to do to yourself.
Otherwise they just slow down for a few seconds instead.
Also fixed an unrelated name bug while I was there.
Closes#76926
## Why It's Good For The Game
Players would take them, not deliver any cargo, and repeatedly ask
people to lie down in front of them.
Plus Tram has 5 of the things which is frankly too many to be wandering
around the bar.
## Changelog
🆑
balance: You can't possess a MULE as soon as the round starts, someone
will have to give you permission.
balance: MULEbots no longer crush prone characters unless they have been
hacked (or emagged).
fix: Bots can put numbers in their names, what with being robots.
admin: Adds attack logging when certain wires are cut (for instance:
MULEbot safeties)
/🆑
## About The Pull Request
Further continous organizing and cleaning the Icons folder. There are
still some minior nitpicks left to do, but I reached my daily sanity
expenses limit again, and the faster these get in the less issues for
both me and others later. Also cleans some mess I caused by my blindness
last PR.
## Why It's Good For The Game
Saner spriters = better sprites
## About The Pull Request
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.
/🆑
## 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.
/🆑
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.
## About The Pull Request
[A common problem with explosions is an overabundance of
sleeping](6499077a09)
In an attempt to solve this issue, let's not continue to sleep and do
work in door closing if the door is already deleted
(This is caused by firelocks activating due to other adjacent objects
deleting, triggering an atmos update, and closing the firelocks before
they get bombed. I don't have a elegant way of resolving that core
problem, so let's just minimize the impact)
[Nukes a stupid sleep loop in airlock
code](5b16360520)
When an airlock was depowered, it would enter a sleep loop, decrementing
its delay by 1 second every well, one second, so long as it had the
right wires flipped
This is very stupid
Instead, let's use signals off wire changes and a combo of timer and
remaining time var to do this with JUST a timer
Most of the changes here are just swapping over wires to a setter to
make signal registration work\
## Why It's Good For The Game
Less sleeping around explosions means less dropped ticks after a bomb
goes off. Good just in general
Also this excises dumb boomer code and adds some hooks for other devs to
use (we should use wires more man)
## About The Pull Request
Signals were initially only usable with component listeners, which while
no longer the case has lead to outdated documentation, names, and a
similar location in code.
This pr pulls the two apart. Partially because mso thinks we should, but
also because they really aren't directly linked anymore, and having them
in this midstate just confuses people.
[Renames comp_lookup to listen_lookup, since that's what it
does](102b79694f)
[Moves signal procs over to their own
file](33d07d01fd)
[Renames the PREQDELETING and QDELETING comsigs to drop the parent bit
since they can hook to more then just comps
now](335ea4ad08)
[Does something similar to the attackby comsigs (PARENT ->
ATOM)](210e57051d)
[And finally passes over the examine
signals](65917658fb)
## Why It's Good For The Game
Code makes more sense, things are better teased apart, s just good imo
## Changelog
🆑
refactor: Pulled apart the last vestiges of names/docs directly linking
signals to components
/🆑
## About The Pull Request
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>
## 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>
## About The Pull Request
Resprites stock parts to bring them up to date, changes manipulators to
servo motors as I couldn't make manipulators work well at this scale.
(Power cells sold separately)
## Why It's Good For The Game
The old stock parts are dated, in some cased quite ugly, and in the case
of manipulators a ball of assorted pixels. Incidentally removed a couple
of single letter var names.
## Changelog
🆑
image: Stock parts have been resprited.
code: Manipulators have been renamed to servo motors, all related types
have been repathed to match.
/🆑
Ladies, Gentlemen, Gamers. You're probably wondering why I've called you
all here (through the automatic reviewer request system). So, mineral
balance! Mineral balance is less a balance and more of a nervous white
dude juggling spinning plates on a high-wire on his first day. The fact
it hasn't failed after going on this long is a miracle in and of itself.
This PR does not change mineral balance. What this does is moves over
every individual cost, both in crafting recipes attached to an object
over to a define based system. We have 3 defines:
`sheet_material_amount=2000` . Stock standard mineral sheet. This being
our central mineral unit, this is used for all costs 2000+.
`half_sheet_material_amount=1000` . Same as above, but using iron rods
as our inbetween for costs of 1000-1999.
`small_material_amount=100` . This hits 1-999. This covers... a
startlingly large amount of the codebase. It's feast or famine out here
in terms of mineral costs as a result, items are either sheets upon
sheets, or some fraction of small mats.
Shout out to riot darts for being the worst material cost in the game. I
will not elaborate.
Regardless, this has no functional change, but it sets the groundwork
for making future changes to material costs much, MUCH easier, and moves
over to a single, standardized set of units to help enforce coding
standards on new items, and will bring up lots of uncomfortable balance
questions down the line.
For now though, this serves as some rough boundaries on how items costs
are related, and will make adjusting these values easier going forward.
Except for foam darts.
I did round up foam darts.
Adjusting mineral balance on the macro scale will be as simple as
changing the aforementioned mineral defines, where the alternative is a
rats nest of magic number defines. ~~No seriously, 11.25 iron for a foam
dart are you kidding me what is the POINT WHY NOT JUST MAKE IT 11~~
Items individual numbers have not been adjusted yet, but we can
standardize how the conversation can be held and actually GET SOMEWHERE
on material balance as opposed to throwing our hands up or ignoring it
for another 10 years.
## About The Pull Request
0426f7ddba/code/game/objects/items/stacks/stack.dm (L449)
Ok, but can we not?
This PR refactors sheet crafting to generalize all the cases that were
previously locked behind grille/window type checks and such. In their
stead there are bitflags that can be set to achieve certain behaviors.
All the behavior from before should be preserved, but now it can be
extended to other items. E.g. if you want a railing that can be crafted
underneath directional windows, or an item that behaves like a grille
does--it's just a matter of setting the right obj_flags for it now.
This makes it very simple and painless to add new recipes that use
directional crafting! It's all modular now.
<details><summary>Details</summary>
---
### What I've done:
-Eliminated all the type checks, instead it will now be handled by
object flags and recipe vars, making for a much more configurable
system.
-Added two new obj_flags: `BLOCKS_CONSTRUCTION_DIR` and
`IGNORE_DENSITY`.
-Additionally, I renamed the existing flag `NO_BUILD` to
`BLOCKS_CONSTRUCTION`.
-Changes the proc `valid_window_location` to `valid_build_direction`,
and makes it work for things other than windows.
-Removed a deprecated `window_checks` var from the stack_recipe datum.
-Added three more vars to the stack_recipe datum: `check_direction` and
`check_density`, `is_fulltile`
-Decoupled `on_solid_ground` from the object density check. Now you can
set those separately, allowing you to make recipes that forbid/allow
building things over other things while in space.
---
### What the new flags do:
`BLOCKS_CONSTRUCTION` works as before---prevents objects from being
built on the object. I felt that the previous name was not descriptive
enough, you should know exactly what it does just from looking at the
name.
_example: dna scanner_
`BLOCKS_CONSTRUCTION_DIR` -- setting this on an object will prevent
objects from being built on it when their directions are the same.
_example: directional windows, windoors, railings_
`IGNORE_DENSITY` -- setting this on an object will cause its density to
be ignored when performing the construction density check. This could
have other potential uses as well in the future.
_example: grilles, directional windows, tables_
These three flags cover all the bases for the types of items that are
currently craftable, so there is no more need for any type checking or
weird snowflake window checks. Simply set the appropriate flag and it'll
work as you would expect.
---
### What the recipe vars do:
`check_direction` tells the recipe to check if there's something in that
direction with the `BLOCKS_CONSTRUCTION_DIR` flag set.
`check_density` tells the recipe to run the density check when set. This
is true by default. There are very few items in the game that currently
have this set to false--namely grilles. Setting this to false will make
it so that the object can be constructed regardless of what is in that
tile (unless `one_per_turf` is also set, which will make it so that you
can't craft the same thing twice in the same turf).
`is_fulltile` is used for fulltile windows, but it doesn't necessarily
have to be--you can give this to any recipe and it will adopt the same
properties as that of the fulltile window. Basically they have a special
case where they shouldn't be able to be built over directional
constructions, where normally things would be able to be. Setting this
makes check_direction true as well.
---
### In summary:
Sheet crafting still works just as it did before. But the backend of it
has gotten a glow up and will be able to more easily support new
behaviors.
</details>
## Why It's Good For The Game
This makes the crafting system much more flexible to add recipes to, and
will prevent bad code practices of stacking more conditionals down the
line whenever someone wants to add an item that behaves like grilles or
directional windows in how they are constructed.
It had to be done. Those window checks were a mess.
## Changelog
🆑
qol: added fifty stack versions of remaining glass sheet stacks for ease
of debugging
refactor: refactored sheet crafting to better support directional
constructions that aren't windows
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
This tracks the seconds per tick of a subsystem, however note that it is
not completely accurate, as subsystems can be delayed, however it's
useful to have this number as a multiplier or ratio, so that if in
future someone changes the subsystem wait time code correctly adjusts
how fast it applies effects
regexes used
git grep --files-with-matches --name-only 'DT_PROB' | xargs -l sed -i
's/DT_PROB/SPT_PROB/g'
git grep --files-with-matches --name-only 'delta_time' | xargs -l sed -i
's/delta_time/seconds_per_tick/g'
## About The Pull Request
I underestimated SEND_GLOBAL_SIGNAL and assumed it worked differently to
SEND_SIGNAL, as in I thought it would not be sending the source as the
first arg.
Because it does, it meant that the list of data was actually just ntnet
sending circuit. This fixes it and makes the args work properly.
I've shamelessly stolen the circuit in the screenshot of the issue to
test it in-game
## Why It's Good For The Game
Closes https://github.com/tgstation/tgstation/issues/74327
## Changelog
🆑
fix: NtNet receive/send circuits should work now.
/🆑
# MAINTAINER - USE THE BUTTON THAT SAYS "MERGE MASTER" THEN SET THE PR
TO AUTO-MERGE! IT'S MUCH EASIER FOR ME TO FIX THINGS BEFORE THEY SKEW
RATHER THAN AFTER THE FACT.
## About The Pull Request
Hey there,
This took a while to do, but here's the gist:
Python file now regexes every file in `/code` except for those that have
some valid reason to be tacking on more global defines. Some of those
reasons are simply just that I don't have the time right now (doing what
you see in this PR took a few hours) to refactor and parse what should
belong and what should be thrown out. For the time being though, this PR
will at least _halt_ people making the mistake of not `#undef`ing any
files they `#define` "locally", or within the scope of a file.
Most people forget to do this and this leads to a lot of mess later on
due to how many variables can be unmanaged on the global level. I've
made this mistake, you've made this mistake, it's a common thing. Let's
automatically check for it so it can be fixed no-stress.
Scenarios this PR corrects:
* Forgetting to undef a define but undeffing others.
* Not undeffing any defines in your file.
* Earmarking a define as a "file local" define, but not defining it.
* Having a define be a "file local" define, but having it be used
elsewhere.
* Having a "local" define not even be in the file that it only shows up
in.
* Having a completely unused define*
(* I kept some of these because they seemed important... Others were
junked.)
## Why It's Good For The Game
If you wanna use it across multiple files, no reason to not make it a
global define (maybe there's a few reasons but let's assume that this is
the 95% case).
Let me know if you don't like how I re-arranged some of the defines and
how you'd rather see it be implemented, and I'd be happy to do that.
This was mostly just "eh does it need it or not" sorta stuff.
I used a pretty cool way to detect if we should use the standardized
GitHub "error" output, you can see the results of that here
https://github.com/san7890/bruhstation/actions/runs/4549766579/jobs/8022186846#step:7:792
## Changelog
Nothing that really concerns players.
(I fixed up all this stuff using vscode, no regexes beyond what you see
in the python script. sorry downstreams)
## About The Pull Request
Refactors regenerate organs to be slightly more intelligent in handling
organ changes and replacements.
Noteably:
- We don't remove organs that were modified by the owner; such as
changing out your heart for a cybernetic
- We early break out of the for loop if they aren't supposed to have an
organ there and remove it
- We check for the organ already being correct, and just healing it and
continuing if it is
Also changes the names of some of the organ helpers into snake_case
### Mapping March
Ckey to receive rewards: N/A
## Why It's Good For The Game
## Changelog
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
## About The Pull Request
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>
## About The Pull Request
These changes fix how machines are pried open with crowbars. Currently,
most machines can be pried open, but many of them have no method for
being closed again. This means they can be pried once, and then never
again (as their internal logic has them stuck in an "open" state).
Additionally, the densities of these machines is also inconsistent, as
density is tied to the procs for opening/closing machines (open =
non-dense, closed = dense). Thus, these new changes allow desired
densities to be passed to `open_machine()` and `close_machine()`, as
well as `default_pry_open()`, meaning that atypical machine densities
can be maintained (e.g. machines that should remain dense when open, or
non-dense when closed).
I've also added a `close_after_pry` boolean parameter to the
`default_pry_open()` proc, which determines whether to immediately close
a machine after opening it. This is useful for machines that don't
really have a use case for remaining open, often lacking a sprite to
represent this state as well.
* Note: Opening and immediately closing machines with this boolean will
still drop their contents onto the floor, but will now immediately
"close" in their logic, allowing for further prying attempts in the
future.
It's worth noting that this implements default density values for these
procs, which match the existing behavior for machines, so as to
(hopefully) not disrupt existing or expected machine behavior.
Two caveats to these changes currently exist:
1. On machines that immediately close after prying, the prying action
can now be spammed to the chat with repeated clicking. I'm uncertain if
this needs some sort of spam protection or if it's fine as is.
2. I've only been able to manually test this code. I'd love to write
unit tests for it, as it affects a lot of different machines, but don't
know where to begin with DM Unit Testing (or which files would be good
examples to reference in the code base).
* Note: I did manually test each and every machine that calls
`default_pry_open()` and they all seem to be working correctly. (Except
for `obj/machinery/plumbing/sender`, but that doesn't seem to need
prying, as it has no contents to drop, only reagents.)
As always, let me know if any improvements/changes should be made.
This closes#26833.
## Why It's Good For The Game
These changes allow crowbar prying to correctly occur multiple times on
any machine, which is intended behavior. It prevents player confusion
that could occur when a machine couldn't be pried open a second time
during a shift, even though it had previously been pried before, forcing
players to question themselves. (Are they missing something? Did they
perform the action a different way last time? Is the machine actually
still powered on instead of off? Etc.)
These changes also maintain the correct density for machines after
prying, preventing scenarios where a machine might behave differently
once it had been pried open. (An example of this was being able to walk
through a smartfridge after prying it open.) Additionally, players are
no longer required to know/use workarounds (such as machine disassembly)
to retrieve a powered-off machine's contents.
Overall, these changes improve consistency around machines, creating
more scenarios where they behave as players would expect.
## Changelog
🆑
fix: machines can now be pried open more than once.
fix: machines now have the correct density when pried open.
/🆑
---------
Co-authored-by: san7890 <the@san7890.com>
## About The Pull Request
This PR adds a new unit test for all organs, a new unit test for lungs,
and includes improvements for the existing breath and organ_set_bonus
tests. Using the tests, I was able to root out bugs in the organs. This
PR includes an advanced refactor of several developer-facing functions.
This PR certainly represents a "quality pass" for organs which will make
them easier to develop from now on.
### Synopsis of changes:
1. Fixed many fundamental bugs in organ code, especially in
`Insert()`/`Remove()` and their overrides.
2. Added two new procs to `/obj/item/organ` named `on_insert` and
`on_remove`, each being called after `Insert()`/`Remove()`.
3. Added `organ_effects` lazylist to `/obj/item/organ`. Converted
`organ_traits` to lazylist. 2x less empty lists per organ.
4. Adding `SHOULD_CALL_PARENT(TRUE)` to `Insert()`/`Remove()` was very
beneficial to stability and overall code health.
5. Created unit test `organ_sanity` for all usable organs in the game.
Tests insertion and removal.
6. Created unit test `lungs_sanity` for
`/obj/item/organ/internal/lungs`.
7. Improved `breath_sanity` unit tests with additional tests and
conditions.
8. Improved `organ_set_bonus_sanity` unit tests with better
documentation and maintainable code.
---
### Granular bug/fix list:
- A lot of organs are overriding `Insert()` to apply unique
side-effects, but aren't checking the return value of the parent proc
which causes the activation of side-effects even if the insertion
technically fails. I noticed the use-case of applying "unique
side-effects" is repeated across a lot of organs in the game, and by
overriding `Insert()` the potential for bugs is very high; I solved this
problem with inversion-of-control by adding two new procs to
`/obj/item/organ` named `on_insert` and `on_remove`, each being called
after `Insert()` and `Remove()` succeed.
- Many organs, such as abductor "glands", cursed heart, demon heart,
alien hive-node, alien plasma-vessel, etc, were not returning their
parent's `Insert()` proc return value at all, and as a result those
organs `Insert()`s were always returning `null`. I have been mopping
those bugs up in my last few PRs, and now the unit test reveals it all.
Functions such as those in surgery expect a truthy value to be returned
from `Insert()` to represent insertion success, and otherwise it
force-moves the organ out of the mob.
- Fixed abductor "glands" which had a hard-del bug due to their
`Remove()` not calling the parent proc.
- Fixed cybernetic arm implants which had a hard-del bug due to
`Remove()` not resetting their `hand` variable to `null`.
- Fixed lungs gas exchange implementation, which was allowing exhaled
gases to feedback into the inhaled gases, which caused Humans to inhale
much more gas than intended and not exhale expected gases.
### Overview of the `organ_sanity` unit test:
- The new `organ_sanity` unit test gathers all "usable" organs in the
game and tests to see if their `Insert()` and `Remove()` functions
behave as we expect them to.
- Some organs, such as the Nightmare Brain, cause the mob's species to
change which subsequently swaps out all of their organs; the unit test
accounts for these organs via the typecache `species_changing_organs`.
- Some organs are not usable in-game and can't be unit tested, so the
unit test accounts for them via the typecache `test_organ_blacklist`.
### Overview of the `lungs_sanity` unit test:
- This unit test focuses on `/obj/item/organ/internal/lungs` including
Plasmaman and Ashwalker lungs. The test focuses on testing the lungs'
`check_breath()` proc.
- The tests are composed of calling `check_breath` with different gas
mixes to test breathing and suffocation.
- Includes gas exchange test for inhaled/exhaled gases, such as O2 to
CO2.
### Improvements to the `breath_sanity` unit tests:
- Added additional tests for suffocation with empty internals, pure
Nitrogen internals, and a gas-less turf.
- Includes slightly more reliable tests for internals tanks.
## Why It's Good For The Game
**Organs and Lungs were mostly untested. Too many refactors have been
submitted without the addition of unit tests to prove the code works at
all.** Time to stop. _Time to get some help_. Due to how bad the code
health is in organs, any time we've tried to work with them some sort of
bug caused them to blow up in our faces. I am trying to fix some of that
by establishing some standard testing for organs. These tests have
revealed and allowed me to fix lot of basic developer errors/oversights,
as well as a few severe bugs.
## Changelog
🆑 A.C.M.O.
fix: Fixed lungs gas exchange implementation, so you always inhale and
exhale the correct gases.
fix: Fixed a large quantity of hard-deletes which were being caused by
organs and cybernetic organs.
fix: Fixed many organs which were applying side-effects regardless of
whether or not the insertion failed.
code: Added unit tests for Organs.
code: Added unit tests for Lungs.
code: Improved unit tests for breathing.
code: Improved unit tests for DNA Infuser organs.
/🆑
## About The Pull Request
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.
/🆑
## About The Pull Request
- Juggernaut and Rust Walker projectiles were subtyped off of magic,
which is `nodamage`.
- The juggernaut actually had a copy+paste error with their type
`on_hit` which caused none of their special effects on hit ("relative
patching catches this")
- Then I realized projectiles have this var `nodamage` which is, for all
intents and purposes, just `damage > 0`. it's not checked for pacifism,
it's just that. This is dumb. So very dumb, so I removed it.
- There are, however, a few situations which used it in a unique way,
such as the blast wave cannon. This is why I replaced it with a proc,
`is_hostile_projectile`, for certain situations to actually find out if
the projectile is damaging. Projectiles can override this on a per type
basis by default, damaging projectiles = hostile.
- This has a chance to break some things, but I ... kinda doubt it will.
Fixes#73756
## Why It's Good For The Game
Projectiles that act as they should, less dumb vars
## Changelog
🆑 Melbert
fix: Fixes Juggernaut / Rust Walker projectiles doing zero damage
fix: Fixes Juggernaut projectiles not doing bonus damage to nearby
structures
code: Removed projectile nodamage var, replaces it with just checking
for damage
/🆑
## About The Pull Request
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.
/🆑
This builds on what #69790 did and improved the code even further.
Notable things:
- `Topic()` is a deprecated proc in our codebase (replaced with
Javascript tgui) so it makes sense to rename `canUseTopic` to
`can_perform_action` which is more straightforward in what it does.
- Positional and named arguments have been converted into a easier to
use `action_bitflag`
- The bitflags adds some new checks you can use like: `NEED_GRAVITY |
NEED_LITERACY | NEED_LIGHT` when you want to perform an action.
- Redundant, duplicate, or dead code has been removed.
- Fixes several runtimes where `canUseTopic` was being called without a
proper target (IV drips, gibber, food processor)
- Better documentation for the proc and bitflags with examples
## About The Pull Request
Damn that's a long title.
Admin Verbs can be used in the verb bar with hyphens instead of spaces
again.
## Why It's Good For The Game
Admin muscle memory
## Changelog
## About The Pull Request
>_"I don't remember buying tickets to Mutants on Ice."_
>-Duke Nukem
This PR is (hopefully the final) part of a series of my continuing
refactors of the DNA Infuser. This PR represents a "quality pass" which
should also iron-out the rest of the most impactful bugs.
Granular list of changes:
- This PR adds unit tests for the DNA Infuser organs and
`/datum/status_effect/organ_set_bonus` as recommended by @AnturK
- I noticed that the base `/datum/infuser_entry` was being used in the
machine for the Fly and "rejected" infusions, whereas usually we would
expect it to be a base type used only as a development template. I
corrected this issue and created `/datum/infuser_entry/fly` to be used
for that use-case instead.
- Added `/mob/proc/can_mutate()` and `/mob/living/carbon/can_mutate()`
to replace a few copied lines across several files. The proc is normally
used in the context of mutating a Human via their DNA.
- I fixed a ton of typos in organ-related code, specifically where
"receiver" was typo'd as "reciever". There are far more of those typos,
but I limited the scope of my changes to organs.
- I noticed a bug in `/datum/species/proc/regenerate_organs` wherein a
race condition caused an organ to remove itself before it's done
inserting itself. This happens because the Fly organ set bonus runs
`regenerate_organs` which calls `Remove` on the organ while `Insert` is
still in the call-stack. I added `INVOKE_ASYNC` as a workaround, and
also changed the order the signals are emitted to prevent future bugs.
This bug primarily only impacted the flyperson species transformation,
which was part of the DNA Infuser's flyperson infusion organ set bonus.
- In my last refactor PR #72745 I also introduced a bug in
`/obj/machinery/dna_infuser/proc/infuse_organ` wherein I forgot to add
the usage of `new` when attempting to implant new organs, and this PR
fixes the erroneous code.
- Fxed a bug which causes the organ set bonus to activate when mixing
organs from different sources, which is caused by a developer oversight
wherein all `/datum/status_effect/organ_set_bonus` had identical IDs.
- Added a cleaner `replacetext`-based way of handling pronouns in
`/datum/element/noticable_organ/proc/on_receiver_examine`, using custom
macros `%PRONOUN_S` and `%PRONOUN_ES` as advised by @MrMelbert
- This PR also fixes#72767
## Why It's Good For The Game
With the changes in this PR the machine will finally work as we expect
it to. By adding unit tests we will also be able to ensure that it works
as expected from now on. I feel confident saying that the completeness,
algorithmic correctness, and code health of the DNA Infuser is much
better than it was before.
## Changelog
🆑 A.C.M.O.
fix: Fully fixed the DNA Infuser, which will now infuse organs as
expected.
fix: Fixed flyperson species transformation and organ set bonus, which
was throwing a runtime.
fix: Fixed many typos in organ-related source code.
/🆑
---------
Co-authored-by: Time-Green <timkoster1@hotmail.com>
## 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
/🆑
## 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.
## 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
/🆑
