* Collected food fixes (#78190)
I went through the code and tried to find all of the remaining places we
forgot to update the arguments passed into `item/food/Initialize` after
more arguments were added to it, because there were a couple and they
caused things to stop working.
Most notably, golems were unable to eat anything because nothing would
correctly spawn "golem food".
_Additionally_ we were using a bunch of named arguments in new whenever
crafting or cooking food. This runtimed, causing the food not to init
properly.
_On top of that_ a late code review on a recent PR processed a list into
a string_assoc_list twice causing it to become null.
Finally, we were trying to check the food preferences of examining
ghosts or dogs or other non-human mobs. We shouldn't do that.
I also added a unit test for moth and golem food in the hopes that we'll
notice them breaking.
* Collected food fixes
---------
Co-authored-by: Jacquerel <hnevard@gmail.com>
* Ensures that all Unit Tests are ticked in `_unit_tests.dm` (#76404)
## About The Pull Request
Ensures we don't get a repeat of #76345 (unit test that wasn't ticked in
the `_unit_tests.dm` file, fixed in
596ca8b6d4). Basically, we leverage the
code that was already being used in the DME Validator but then expand it
a bunch via using JSON Schemas that correspond to the type of scan we
want to run. Even though sorting unit tests alphabetically is a bit
different than sorting the tgstation DME, it's good to leverage the
already existing framework rather than create a copy-pasta "lesser" code
runner. This went through strenous testing on my end, so let me know if
anything seems off.
While in the area, I added some other niceties that I've found work
really well in GitHub Runners environments, as well as local testing in
case you really like doing that before you make a PR for some reason.
## Why It's Good For The Game
This is what it looks like pre-596ca8b6d4cc49cd69fc104b53b7f4973497a2e5
(this is now merged, so it will pass CI)
De-hardcodes some stuff and allows for some neater flexibility, less
cringe unit tests being coded and not being ticked in the file, etc.
etc.
## Changelog
Nothing for players to care about.
Let me know if you have a better idea than the schemas, I couldn't think
of one that could be really extensible and flexible in the same way this
is.
# Conflicts:
# code/modules/unit_tests/_unit_tests.dm
# tools/validate_dme.py
* Modular tick enforcement
* Update tgstation_dme.json
* Update tgstation_dme.json
* Update tgstation.dme
* Update unit_tests.json
* Modular tick enforcement
* oop
* Update ticked_file_enforcement.py
I cannot python what the heck
* Update ticked_file_enforcement.py
* Update ticked_file_enforcement.py
* Update ticked_file_enforcement.py
* Update ticked_file_enforcement.py
ugh
* Update ticked_file_enforcement.py
* You have got to be kidding me.....
* Update _unit_tests.dm
* Update _unit_tests.dm
* Update _unit_tests.dm
* Update unit_tests.json
* Update unit_tests.json
* Update _unit_tests.dm
* Update unit_tests.json
* Update _unit_tests.dm
* Update _unit_tests.dm
* Update
* Update unit_tests.json
* Update ci_suite.yml
* Update ci_suite.yml
* Update ci_suite.yml
* Update _unit_tests.dm
* Update
* Ughdate
* Ughdate
* Ughdate
* Debug time
* Update ticked_file_enforcement.py
* Update _unit_tests.dm
* Update tgstation.dme
* Revert "Update tgstation.dme"
This reverts commit 4e82ad6b0be937d26ac36884f2d00d6718d72029.
* Update _unit_tests.dm
* What
* Hmm
* Update unit_tests.json
* Ugh
* Update ticked_file_enforcement.py
* This is so jank
* hnnng
* Update ticked_file_enforcement.py
* what. do. you. want.
* Update ticked_file_enforcement.py
* Now let's see if it works
* Revert "Now let's see if it works"
This reverts commit 915c40d99da8b7a869db1205e48e4f7178da9b8e.
---------
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
Co-authored-by: Bloop <13398309+vinylspiders@users.noreply.github.com>
* Adds a unit test to check items are dropped when the arm holding them is dismembered. (#77646)
## About The Pull Request
What it says on the tin. First time ever making a unit test, so
critiques and feedback are very much appreciated.
If anyone thinks of other relevant edge cases, please do bring them up.
## Why It's Good For The Game
Requested in #77613 (71fe46511a), as the
fact it broke again is a regression. Will fail until that PR is merged,
as you might expect.
* Adds a unit test to check items are dropped when the arm holding them is dismembered.
---------
Co-authored-by: A miscellaneous Fern <80640114+FernandoJ8@users.noreply.github.com>
* Fixes Ticked File Enforcement and Missing Unit Test (and makes said Unit Test Compile) (and genericizes the C&D list to the base unit test datum)
* Updates ignores
---------
Co-authored-by: san7890 <the@san7890.com>
Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com>
* Unit Tests for AI Planning Subtrees not having required element/component (#77539)
## About The Pull Request
Hey there,
I've personally fallen for this stupid thing twice (in #77503 and #75627
(d3575161ca)), so I decided to spend a few
hours to crack out a unit test to ensure that I (and no one else) falls
for this stupid thing again.
Let me know if there's a smarter way to code something like this, but I
couldn't figure out a better way to accomodate the current framework and
be as agnostic to certain oddities as possible.
## Why It's Good For The Game
Catches stuff like this:
```txt
[2023-08-11 21:10:04.019] FAILURE #1: The mob Garden Gnome does not have ANY instances of TRAIT_SUBTREE_REQUIRED_ELEMENT, but has a planning subtree (/datum/ai_planning_subtree/target_retaliate) that requires it! at code/modules/unit_tests/ensure_subtree_element.dm:45
- FAILURE #2: The mob the morph does not have ANY instances of TRAIT_SUBTREE_REQUIRED_ELEMENT, but has a planning subtree (/datum/ai_planning_subtree/target_retaliate) that requires it! at code/modules/unit_tests/ensure_subtree_element.dm:45
- FAILURE #3: The mob the guard spiderling (946) does not have ANY instances of TRAIT_SUBTREE_REQUIRED_ELEMENT, but has a planning subtree (/datum/ai_planning_subtree/target_retaliate/to_flee) that requires it! at code/modules/unit_tests/ensure_subtree_element.dm:45
- FAILURE #4: The mob the ambush spiderling (255) does not have ANY instances of TRAIT_SUBTREE_REQUIRED_ELEMENT, but has a planning subtree (/datum/ai_planning_subtree/target_retaliate/to_flee) that requires it! at code/modules/unit_tests/ensure_subtree_element.dm:45
- FAILURE #5: The mob the scout spiderling (375) does not have ANY instances of TRAIT_SUBTREE_REQUIRED_ELEMENT, but has a planning subtree (/datum/ai_planning_subtree/target_retaliate/to_flee) that requires it! at code/modules/unit_tests/ensure_subtree_element.dm:45
- FAILURE #6: The mob the flesh spiderling (337) does not have ANY instances of TRAIT_SUBTREE_REQUIRED_ELEMENT, but has a planning subtree (/datum/ai_planning_subtree/target_retaliate/to_flee) that requires it! at code/modules/unit_tests/ensure_subtree_element.dm:45
- FAILURE #7: The mob the hunter spiderling (869) does not have ANY instances of TRAIT_SUBTREE_REQUIRED_ELEMENT, but has a planning subtree (/datum/ai_planning_subtree/target_retaliate/to_flee) that requires it! at code/modules/unit_tests/ensure_subtree_element.dm:45
- FAILURE #8: The mob the nurse spiderling (629) does not have ANY instances of TRAIT_SUBTREE_REQUIRED_ELEMENT, but has a planning subtree (/datum/ai_planning_subtree/target_retaliate/to_flee) that requires it! at code/modules/unit_tests/ensure_subtree_element.dm:45
- FAILURE #9: The mob the tangle spiderling (19) does not have ANY instances of TRAIT_SUBTREE_REQUIRED_ELEMENT, but has a planning subtree (/datum/ai_planning_subtree/target_retaliate/to_flee) that requires it! at code/modules/unit_tests/ensure_subtree_element.dm:45
- FAILURE #10: The mob the broodmother spiderling (855) does not have ANY instances of TRAIT_SUBTREE_REQUIRED_ELEMENT, but has a planning subtree (/datum/ai_planning_subtree/target_retaliate/to_flee) that requires it! at code/modules/unit_tests/ensure_subtree_element.dm:45
- FAILURE #11: The mob the viper spiderling (519) does not have ANY instances of TRAIT_SUBTREE_REQUIRED_ELEMENT, but has a planning subtree (/datum/ai_planning_subtree/target_retaliate/to_flee) that requires it! at code/modules/unit_tests/ensure_subtree_element.dm:45
- FAILURE #12: The mob the tarantula spiderling (963) does not have ANY instances of TRAIT_SUBTREE_REQUIRED_ELEMENT, but has a planning subtree (/datum/ai_planning_subtree/target_retaliate/to_flee) that requires it! at code/modules/unit_tests/ensure_subtree_element.dm:45
- FAILURE #13: The mob the spiderling (100) does not have ANY instances of TRAIT_SUBTREE_REQUIRED_ELEMENT, but has a planning subtree (/datum/ai_planning_subtree/target_retaliate/to_flee) that requires it! at code/modules/unit_tests/ensure_subtree_element.dm:45
```
(ignore the part about gnomes and morphs, this was an earlier version of
the unit test. everything else was relevant and is fixed)
## Changelog
🆑
fix: Growing spiders will now retaliate against you like they were
always meant to.
/🆑
* Unit Tests for AI Planning Subtrees not having required element/component
---------
Co-authored-by: san7890 <the@san7890.com>
* Adds a unit test for client colours. (#77484)
## About The Pull Request
I'm adding a unit test for the sanity of client colours, ancient datums
which I had refactored a long time ago. This also affects the
`color_to_full_rgba_matrix()` proc, which I had also worked on.
## Why It's Good For The Game
Ever since that aforementioned years old refactor, there have always
been a few issues with client colours.
The most annoying one being the monochromacy client color lingering even
after the blindness status effect is ok.
It's unlikely this will fix that. However, this should clear a few other
runtimes with the feature.
## Changelog
N/A.
* Adds a unit test for client colours.
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
* Fixes Shadow Walk (#77518)
## About The Pull Request
Phased mobs are not turfs so the new check failed.
Fixes this and adds a unit test for it.
Also makes shadow walk VV-able to any level of lightness.
## Changelog
🆑 Melbert
fix: Fixes Shadow Walk
/🆑
* Fixes Shadow Walk
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Kills `seconds_per_tick` from status effect `tick`, replaces it with `seconds_between_ticks` to clarify some things (#77219)
## About The Pull Request
https://github.com/tgstation/tgstation/pull/66573#discussion_r861157216
`status_effect/proc/tick(seconds_per_tick)` is wildly misleading and I
feel like I should address it
For a majority of status effects, they process on fast processing but do
not tick every fastprocessing tick
This means that using `seconds_per_tick` here is not giving you the
seconds between status effect ticks, it's giving you seconds between
processing ticks (`0.2`)
This is how it's misleading - If you have a tick interval of `1
SECONDS`, you'd think `seconds_per_tick` is, well, one. But it's
actually one-fifth. So all of your effects are now 80% weaker.
I have replaced the use of `seconds_per_tick` in tick with
`seconds_between_ticks`.
This number is, quite simply, the initial tick interval of the status
effect divided by ten.
An effect with the tick interval of `1 SECONDS` has a
`seconds_between_ticks` of 1.
As a consequence, some things which were inadvertently made weaker, such
as fire and some heretic things (at a glance), are now a little
stronger.
## Why It's Good For The Game
See above. Makes it more clear what you're doing when working with
effects.
## Changelog
🆑 Melbert
code: Updated some status effect tick code to be more clear of how long
is elapsing between ticks. Some effects that were inadvertently weakened
are now stronger as a result (fire and some heretic effects).
/🆑
* Kills `seconds_per_tick` from status effect `tick`, replaces it with `seconds_between_ticks` to clarify some things
* Modular updates
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com>
* Add leash component to pAIs that keeps them within range instead of directly teleporting them back, increases default range to max range (#77030)
## About The Pull Request
Tries to keep pAIs in range of their owner by moving them closer when
the owner moves, rather than jarringly teleporting every time the owner
gets out of range. Does this by calculating the closest path a nearby
tile and forcefully moving you there. Still a bit janky at times but is
better than teleporting directly onto the owner 100% of the time I feel.
Also prevents you from moving out of range, rather than forcefully
teleporting you back.
Increases the default pAI range to the maximum (9 tiles)
## Why It's Good For The Game
New leashing makes being a leashed pAI significantly less jarring and
obvious. Ideally we would also have a visible max range too.
Default pAI range was pretty small in my testing and I think it's not
unreasonable to think a lot of people won't bother changing it. That
they are leashed at all is the important part.
## Changelog
🆑
qol: pAIs now try to stay within range of their owner, and teleport back
only when necessary
qol: Default max pAI range has been changed to the maximum range you can
choose (9 tiles)
/🆑
---------
Co-authored-by: Jacquerel <hnevard@ gmail.com>
* Add leash component to pAIs that keeps them within range instead of directly teleporting them back, increases default range to max range
* Fixes the leash enable/disable
* A workaround because the procs are private.
* Update card.dm
* Update card.dm
what I get for rushing
* Update card.dm
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: Jacquerel <hnevard@ gmail.com>
Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com>
* Adds a unit test to stop elements from using identical lists for their arguments. (#76322)
## About The Pull Request
Ok, so a few days ago I made an issue report about multiple instances of
identical elements being generated because of uncached lists.
ninjanomnom (the mind being the element datums) cleared it up and said
an implementation of GetIdFromArguments() that also checks the list
contents wouldn't be worth the performance cost, while adding that a
unit test should be written to check that it doesn't happen at least
during init, which should catch a good chunk of cases.
Also, i'm stopping RemoveElement() from initializing new elements
whenever a cached element is not found. Ideally, there should be a focus
only unit test for that too, but that's something we should tackle on a
different PR.
Some of the code comments may be a tad inaccurate, as much as I'd like
to blame drowsiness for it. Regardless, the unit test takes less than
0.2 seconds to complete on my potato so it's fairly lite.
## Why It's Good For The Game
This will close#76279.
## Changelog
No player-facing change to be logged.
* Adds a unit test to stop elements from using identical lists for their arguments.
* Fixes unit test
* seeing double
---------
Co-authored-by: Ghom <42542238+Ghommie@users.noreply.github.com>
Co-authored-by: Giz <13398309+vinylspiders@users.noreply.github.com>
* Refactors mind language holders into non-existent, fixes new languages being deleted on species swap + tests
* Fixing merge conflicts
* don't forget to ctrl+s!
* Another forgotten file
* urgh
* gets rid of vestiges of update_atom_languages()
and mind language holders
* No longer needed
* Fixes some modular grant_language calls
* Deprecated code
* This was up here before..
* Fixes failing unit tests, refactors silverscale lizards language a bit removing the need for skyrat edits
Removes some no longer needed code
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: Pinta <68373373+softcerv@users.noreply.github.com>
Co-authored-by: Giz <vinylspiders@gmail.com>
* Merge branch 'master' of https://github.com/Skyrat-SS13/Skyrat-tg into upstream-merge-76184
* Akula's are angry apparently
* Video Search is a liar
* wetsuit pain
* Fix Too Slowing people with high fives (#76277)
## About The Pull Request
At some point with the refactors to offering it was made so that
dropping the item stops the offer, unfortunately too slowing people with
high fives relied on this behavior (dropping not stopping the offer).
Restores that behavior with a bit more code tweaking.
## Why It's Good For The Game
How can I be too slow?
## Changelog
🆑 Melbert
fix: You can once again "too slow" someone with a high five
/🆑
* Fix Too Slowing people with high fives
* d'oh!
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: Pinta <68373373+softcerv@users.noreply.github.com>
* Removes amount_list_postion from reagent containers, adds related unit test. (#76057)
We had more issues like what #76013 addressed, now they're gone.
Variable transfer amount is now explicit.
Amount is now inferred from current value, performance concern here is
minimal. Less work and mistakes when making new types.
* Removes amount_list_postion from reagent containers, adds related unit test.
* update modular
* Fixes the failing unit test, hopefully
---------
Co-authored-by: AnturK <AnturK@users.noreply.github.com>
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* Refactors the worst list ever, Stun Absorptions, into status effects + makes status flags more accurate (making certain mobs more vulnerable to incapacitations?) (#76000)
## About The Pull Request
- Refactors the stun absorption list into a status effect
- Does a fair bit of cleanup around stun code
Weird thing involved in this.
Check out this define.
`IS_STUN_IMMUNE(source, ignore_canstun) ((source.status_flags & GODMODE)
|| (!ignore_canstun && (!(source.status_flags & CANKNOCKDOWN) ||
HAS_TRAIT(source, TRAIT_STUNIMMUNE))))`
Notice anything odd about it?
It only checks for `CANKNOCKDOWN`.
What does this mean?
Well, *every single* one of the stun procs used this macro for checking
stun immunity. Which means every method of stun checked the
`CANKNOCKDOWN`.
This means that, say you have a mob which has `CANSTUN` but not
`CANKNOCKDOWN`.
Intuitively this means that the mob cannot be knocked down, but can be
stunned.
But instead, this means the mob can't be stunned either.
This doesn't affect humans, they have all the status flags, but it does
affect some other mobs.
Alien adults (not queens) have `CANUNCONSCIOUS|CANPUSH`. Before, they
didn't have `CANKNOCKDOWN`, so they were fully immune to stuns and
sleeps. But now, they can be knocked unconscious.
However, overall it doesn't change much, as most mobs that flipped off
`CANKNOCKDOWN` flipped off the others too.
For consistency though it makes sense for these flags to work as they
imply.
- `incapacitate` didn't have a signal, now it does
## Why It's Good For The Game
More consistent, better code? I may use this in the future.
## Changelog
🆑 Melbert
refactor: Refactored Stun Absorptions (Bastard Sword, His Grace)
refactor: Refactored Stun Immunity. Note this means that some mobs
which, prior, were immune to all forms of incapacitation are now
vulnerable to some. Notably, adult non-queen xenomorphs are now
vulnerable to falling unconscious.
/🆑
* Refactors the worst list ever, Stun Absorptions, into status effects + makes status flags more accurate (making certain mobs more vulnerable to incapacitations?)
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
New traitor item: Mail Counterfeit Devices (#75390)
## About The Pull Request
This PR will add new (antag) device, that will allow players to
counterfeit mails, putting (almost) anything they want and arming it, if
they liked to.
Upon activation this device will give you multiple choices like:
- Is it gonna be an envelope or a normal mail?
- Is it gonna be armed?
- Who is gonna be a recipient?
- If it is a non private mail, then what title it is gonna have?
Those devices can put any single normal sized item inside a mail, that
is gonna be activated upon opening if mail armed. Mail creator and other
ditalis will be shown to admins upon activation for admin purposes.
By activation i mean `attack_self` proc of an item.
Armed mail can be disarmed by using, BUT! Only owner can disarm it with
100% success rate. Other people will have 50% chance of fail, that will
activate a trap.
Those devices also have few more admin-only variations:
```
/obj/item/storage/mail_counterfeit_device/advanced
/obj/item/storage/mail_counterfeit_device/bluespace
```
They can put more items inside a mail.
### How to get those naughty devices?
- Those devices can be purchased in uplink. One device goes for one TC.
- QM and Cargo Technicians have special kits that costs 2 TC and have 6
devices.
And yeah, i also fixed issue with envelopes, they actually have 2 items
inside, but player were given only first one.
Proof of testing:
(minibomb was set to instant detonation before recording)
## Why It's Good For The Game
This PR will give a lot of new possibilities for traitors. Those mails
can be used not only as bombing tools, but also for contraband and other
purposes. Also those mails can be used for (b)admin stuff.
## Changelog
🆑
add: added a mail counterfeit device that can make custom (and also
armed) mails. Traitors have those devices in their uplinks.
add: added new kit for QM and Cargo Technicians that have multiple mail
counterfeit devices for neat price.
fix: fixed envelopes that were giving only their first item, even tho
they had two items insede.
image: added new icon for mail counterfeit device.
/🆑
---------
Co-authored-by: HWSensum <121913313+HWSensum@users.noreply.github.com>
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com>
* Turf Icons Unit Test (#75488)
unit tests turf icons to find... well, missing icons. honk.
fixes#75372
corrects a bunch of things messed up in #65504🆑 ShizCalev
code: Made a new unit test to find turfs with broken/missing icons!
Rejoice!
fix: Fixed a bunch of incorrect and missing turf icons.
/🆑
* Turf Icons Unit Test
* Turf icon unit test modularity support update
* Should hopefully fix all of the failing turf icon tests
---------
Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com>
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
* PT1 MAP RESET
* Lints
* [MDB Ignore] Adds a unit test for typepaths that are required to be mapped onto each station map (#74985)
Inspired by #74967 and #68459 , and the fact that Tramstation regresses
very often -
Adds a unit test, `required_map_items`, which ensures that certain
typepaths which should definitely be mapped onto every map is mapped
onto every map
It can also be used to ensure that items which should not be mapped in
multiple times are not, among other things.
I included a few examples -
- Min 1, max inf of each head of staff stamps
- Min 1, max 1 departmental order consoles
- Min 1, max inf comms console
- Min 1, max 1 Pun Pun
- Min 1, max 1 Poly
- Min 1, max 1 Ian
If, in the future, a mapper decides they (for some reason) do not want a
certain previously-required item on their map, the test can be adjusted
such that it allows excluding or something, but currently it should be
for items which require conscious thought about.
I attempted to make this a linter before realizing two things
1. Someone might make a spawner which spawns the items, or they might
get placed in a locker, in any case this accounts for everything on init
2. Linters run on every map, non-station maps included
So I went with a test
Why is it always the CMO stamp?
Not necessary (unless I find a map missing something, then this will be
updated)
* yay
* Update VoidRaptor.dmm
* Update blackmesa.dmm
* wew
* New sand and water sprites (ported from Bay) (#75254)
* e
* Update AntagInfoClock.tsx
* Update LimbsPage.tsx
* Update area_spawn_entries.dm
* Update LimbsPage.tsx
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Expands conversion unit test coverage (#74563)
## About The Pull Request
Requires #74562 and #74556 be merged first.
Unit tests cult conversion and throws in a case for rev AOE flashes
## Changelog
Not necessary
---------
Co-authored-by: san7890 <the@ san7890.com>
* Expands conversion unit test coverage
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: san7890 <the@ san7890.com>
Co-authored-by: Tom <8881105+tf-4@users.noreply.github.com>
* Moves revolution code of out of flash code, fixes April Fool conversion forcesay never working in any cirumstances (#74411)
## About The Pull Request
- Signallizes head revolutionary flash conversion code, moving it out of
core flash code.
- Removes "tacticool" flashing from head revs, but they can still
convert from any direction
- Fixes April Fools "You son of a bitch! I'm in" force say never
working.
- Revs are muted on conversion so they couldn't talk.
- Fixed by only muting revs on non-holidays
- Cultists are unconscious on conversion so they couldn't talk
- Fixed by only unconscious-ing cultists on non-holidays
- Brainwash victims are more often than not unconscious / asleep so they
couldn't talk
- Just left this one.
- Reduced the chance of them occurring and limits it to April Fools only
- A 1% chance of the force says ocurring means they will happen pretty
much once a week, given multiple rev / cult rounds happen every week and
on average like, 20 people are converted. A little absurd, it's good
that it never worked?
## Why It's Good For The Game
Antag code in core item code is bad
It's funny this meme has existed for like 2, 3 years now? No one's
tested it, it's never worked
## Changelog
🆑 Melbert
refactor: Removes Rev code from core flash code
fix: Getting converted on April Fools now triggers the meme force say as
always intended
del: The meme force say can no longer trigger on any day (it didn't work
before anyways)
/🆑
* Moves revolution code of out of flash code, fixes April Fool conversion forcesay never working in any cirumstances
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Fixes slimes not having a mischievous face (#74483)
## About The Pull Request
The icon state was improperly named, so it didn't actually exist.
This fixes that.
## Why It's Good For The Game
Fixes a bug
## Changelog
🆑
fix: Slimes' mischievous emote now works.
/🆑
* Fixes slimes not having a mischievous face
---------
Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com>
* Unit Test connected station areas (#74367)
## About The Pull Request
Ensures that we don't get station areas which are disconnected
### Mapping March
Ckey to receive rewards: N/A
## Why It's Good For The Game
"Drake, why is this room depressurized?"
## Changelog
* Unit Test connected station areas
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@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>
* 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 all antag datum moodlets being removed when any single antag datum is removed (#73305)
## About The Pull Request
All antag datums operated under the `antag_moodlet` mood category, which
is clearly an issue when you can (and commonly) have multiple antag
datums of different types on your mob.
New antag datums of different type will now no longer override older
antag datum moodlets, now they will stack. This means traitor
revolutionaries are the most zealous folk on the station.
This has a few potential oversights down the line:
- Someone adds an antag datum players can have duplicates of, and also
has a moodlet associated
- Re-used moodlets in antag datums that can easily be stacked will be
noticed
- Most solo antags used `focused` right now, but none can stack outside
of admemes
But I don't think it's an issue for now.
## Why It's Good For The Game
Prevents a quick revolution from stripping you of your joy.
Fixes#67313
## Changelog
🆑 Melbert
fix: Revolutionary Heretics and Cultists Traitors no longer lose all of
their joy in life after being de-converted from their respective causes.
/🆑
* Fixes all antag datum moodlets being removed when any single antag datum is removed
* fix
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: lessthanthree <83487515+lessthnthree@users.noreply.github.com>
Co-authored-by: John Doe <gamingskeleton3@gmail.com>
* Fixes an issue with nightmare revival, Unit tests some fully heal stuff (#73612)
## About The Pull Request
- Same issue as Ethereals. Owner was `null`ed because the heart was
recreated. I opted for a more permanent solution, that being introducing
a new flag to avoid recreating organs.
- Adds some unit tests for fully heal stuff to make sure it works.
## Why It's Good For The Game
More cases of revival working as expected
## Changelog
🆑 Melbert
fix: Nightmare revival acts less funky - stops it from re-creating the
Light Eater.
/🆑
---------
Co-authored-by: san7890 <the@ san7890.com>
* Fixes an issue with nightmare revival, Unit tests some fully heal stuff
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: san7890 <the@ san7890.com>
* Optimize cardboard cutouts saving 1.5s+ on init times (#73404)
New regression in init times. Closes
https://github.com/tgstation/dev-cycles-initiative/issues/32. CC @ Fikou
- Instead of creating a human and icon for *every* cardboard cutout when
initialized, only creates the one we're actually using. When you're
about to use a crayon, creates all of them.
- Instead of using getFlatIcon, uses appearances directly.
* Optimize cardboard cutouts saving 1.5s+ on init times
---------
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
* Fix underlying armor logic and fix bug with constructed ripleys having zero armor (#73319)
## About The Pull Request
See title
## Why It's Good For The Game
Messed up one of the armor procs; it changed the given values but never
carried over existing values.
So you would end up with an armor of that one specific value and nothing
else.
This wasn't actually used anywhere other than mecha, lava burning, and
sentient viruses, so the issue isn't that bad.
It's still an issue however.
## Changelog
🆑
fix: Mechs no longer have zero armor when built.
/🆑
* Fix underlying armor logic and fix bug with constructed ripleys having zero armor
---------
Co-authored-by: Zephyr <12817816+ZephyrTFA@users.noreply.github.com>
* Converts blindness and nearsightedness to status effects, scratches some VERY dumb blindness handling that resulted in mobs becoming "incurably" blind
* Fixes the conflicts and makes shit compile!
* Fixes other things that didn't show up because I hadn't updated
* Fixes the lints.
* Okay NOW it's ready (please don't add anything else that touches blindness I beg you)
---------
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
Water will now make you wet (#72844)
Water, when exposed to a mob either via `TOUCH` or `VAPOR` application,
will now apply wet stacks to said mob according to the amount of water
used. For touch application, the ratio is 0.5 wet stack per unit of
water, whereas for vapor application (so for foam and sprays), that
ratio is lowered to 0.1 wet stack per unit of water. Yes, that would
mean that you could now put someone out by spraying enough water at them
with a spray bottle (usually around 50-150u), and I think that is quite
simply hilarious.
I also updated the unit test of water's `expose_mob()` proc, to check
that wet stacks were being applied properly, hopefully making sure that
there's no regression on that part in the future.
Fixes strange geyser and geyser regen (#72221)
Called the random reagent code after it was initialized
Registered the reagent del/remove signal on the geyser, not the reagent
datum of the geyser
Closes#72037🆑
fix: Strange geysers have random reagents again
fix: Geysers regen reagents again
/🆑
Co-authored-by: Time-Green <timkoster1@hotmail.com>
Abstract away stuff that acts on baseturfs directly into their own procs, and kills some dead code related to baseturfs + tests (#72117)
Adds some new procs relating to baseturfs that replaces some code that
reads and sets them directly. Moves them to their own file. **To
reviewers: Any proc in baseturfs.dm that is snake_case is mine, anything
else is just moved**.
Adds tests for the existing procs of baseturfs.
I'm going to be doing some optimizations to baseturfs that change the
actual representation of baseturfs, and so I'm prepping these to be
implementation agnostic.
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
Co-authored-by: Mothblocks <35135081+Mothblocks@users.noreply.github.com>
Co-authored-by: LemonInTheDark <58055496+LemonInTheDark@users.noreply.github.com>
* [ready] unit tests all worn icons (#72370)
Fixes#71692🆑 ShizCalev
code: Added a unit test for ALL worn icons.
fix: Fixed a bunch of broken worn icons!
/🆑
* [ready] unit tests all worn icons
* Should have fixed most of the failures now
* Here, hopefully that should fix what was left
* Okay maybe it just hadn't been fixed yet
* I can be a bit dumb sometimes
* Okay, now it's going to work, I promise
* I'm so tired of this
Co-authored-by: ShizCalev <ShizCalev@users.noreply.github.com>
Co-authored-by: GoldenAlpharex <jerego1234@hotmail.com>
Co-authored-by: GoldenAlpharex <58045821+GoldenAlpharex@users.noreply.github.com>
* Reworks how legs are rendered yet again because it was very convaluted i hated it
* merge conflicts
* correct comment
* Fixes husk appearances not working, adds a screenshot test for it (#72190)
## About The Pull Request
Fixes#72159
Before this proc used to early return when the limb was husked
The leg refactor changed it to no longer early return and as a result it
overrided the generated husk icon with a normal limb icon
So I just wrapped even more of the proc in `!is_husked`, since like most
of it is not supposed to run
Screenshot tests husks too
## Why It's Good For The Game
Husks are good(?)
## Changelog
🆑 Melbert
fix: Husked bodies look husked again
/🆑
Co-authored-by: ChungusGamer666 <82850673+ChungusGamer666@users.noreply.github.com>
Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com>
* Unit Tests Door/Airlock Access Working (#72461)
I screwed up with my access changes (on my local, I made sure I could
still open doors rather than be kept out of places), and #72458 fixes
that. However, let's also add a unit test to prevent that regression
again. We just do five different access "checks", and see if all five
different scenarios should work as intended.
As you can see, this PR will not pass unit tests. This is supposed to
happen, because at the time of this PR is opened, we will be in a
regression state that the aforementioned PR fixes. When the
aforementioned PR is merged, it should clear CI without any difficulties
(I know this because I ran the unit test myself)
* Unit Tests Door/Airlock Access Working
Co-authored-by: san7890 <the@san7890.com>
SkyratBot
