Tg parity #6
Merged
Tg parity #6
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
## About The Pull Request Fixes tgstation#74145 Forgot to make aux construction console RCD use `afterattack()`. :cl: fix: aux construction console RCD works again /:cl:
…4134) ## About The Pull Request Closes tgstation#74106 Makes it so that it actually uses the values of the object instead of the object it self. First PR so please bear with me. CharredPotato helped immensely with the PR. I thank him for that. ### Mapping March Ckey to receive rewards: N/A ## Why It's Good For The Game bug bad fix kill bug fix good ## Changelog :cl: fix: Circuit-based bluespace launchpads now work again! /:cl:
…ation#74160) ## About The Pull Request Does as the title says. When drawing from an empty deck, the deck would have a chance to preform a transformation on a card that doesn't exist. This PR makes it so that if there is no card, the code returns `FALSE`. ### Mapping March Ckey to receive rewards: N/A ## Why It's Good For The Game Runtimes aren't a good thing to have in the game. ## Changelog :cl: fix: drawing from an empty tarot card deck no longer causes runtimes /:cl:
## About The Pull Request fixes these decimals popping up  ### Mapping March Ckey to receive rewards: N/A ## Why It's Good For The Game bug fixing ## Changelog :cl: fix: the orm will no longer display weird decimals /:cl:
…eficiency (tgstation#74143) ## About The Pull Request This is a followup PR to tgstation#73866 Fixes Skyrat-SS13/Skyrat-tg#19991 I had suspected the nutrition loss slimes experience alongside blood regen might necessitate some tweaks down the line and here we are. This PR has two parts. --- **PART I:** _Reworking the blood deficiency quirk backend_ As it is, blood drain from the blood deficiency occurs in the quirk's subsystem process() call asynchronously to Life(), where the blood regen occurs. This results in the blood volume fluctuating constantly, making it difficult to really make sense of readings and potentially introducing race conditions. This PR changes that. The blood deficiency quirk no longer processes and instead has a proc, `lose_blood(delta_time)`, which is called in the `handle_blood()` proc at the same time blood gets regenerated. Added a `get_quirk` proc to help with this, so that we only have to iterate through the quirks list once for each mob (rather than calling has_quirk, then locate in quirks... etc). Added a `TRAIT_BLOOD_DEFICIENCY` to further optimize the code. --- **PART II:** _Some fine tuning of the slime blood deficiency quirk_ Slime regen works a bit differently than humans such that if they lose -any- blood whatsoever, they will also lose nutrition. This means that even if hooked up to an IV they will still become starving rather quickly. A bit -too- quickly. Instead, now the hunger does not kick in until `blood_volume` reaches 550. This means that if a slime with the blood deficiency quirk is hooked up to an IV with say, welding fluid, and has over 150 nutrition, they will regen blood faster than they lose it from the blood deficiency quirk. Once they get to over 550 `blood_volume`, they will stop losing hunger (from blood regen, anyway--normal hunger rate still applies). So essentially this just allows slimes with the blood deficiency quirk to be able to function so long as they stay hooked up to their IV's (or chug welder fluid/some other toxin), which is the intended purpose of the quirk. Edit: As a bonus I added new blood bags for the exotic blood types, and added a proc `update_mail_goodies` which updates the blood deficiency quirk's mail goodies accordingly (crewmembers with blood deficiency get sent blood bags, now they will get the correct type if their species changes). While I was in these files I changed any immediate single letter vars I could find and cleaned up what I could.  <details> <summary>The new blood packs</summary>  </details> ## Why It's Good For The Game -This is arguably a more performant option than before, and fixes race conditions from `Life()` and `quirk/blooddeficiency/process()` fighting with one another. -Adjustments to slime blood deficiency will enable it to function as intended. -It is now easier to read health analyzer blood volume readings for blood deficient mobs. -Now the correct blood packs are sent in the mail. ## Changelog :cl: qol: adjusted the blood deficiency quirk for slimepeople to not cause excessive hunger as long as blood volume is kept above 550 via an IV drip (or other means of getting welding fluid/some other toxin etc into the bloodstream, e.g. ingestion) qol: speciees with exotic blood types will now receive the correct blood bag in the mail from having the blood deficiency perk add: adds new blood bag types: TOX (slimepeople), H2O (podpeople), S (snail) fix: fixed blood deficiency quirk causing wild fluctuations in blood volume on the analyzer, giving more accurate readings /:cl: --------- Co-authored-by: san7890 <the@san7890.com>
…ation#74173) ## About The Pull Request tgstation#73796 Seems to have made it so that gondola meat is used in the infuser instead of its body, which turns into meat on death. The issue with that is the meat slab does not have the `GORE` flag and so was rejected by the infuser. As per https://github.com/tgstation/tgstation/blob/afe6ecc353eef0db92a23dd1928768651071d11e/code/game/machinery/dna_infuser/dna_infuser.dm#L294-L297 Looking at the code this should fix it right up. ## Why It's Good For The Game Bugfix ## Changelog :cl: fix: fixes gondola meatslab not being able to be placed into the DNA infuser /:cl:
… regular xenos a fluff objective so their popup isn't blank. (tgstation#73852) ## About The Pull Request Xenomorphs who are a product of the roundstart xenobio egg delivery will now spawn as "Captive Xenomorphs", who receive an objective to break containment. Here's how it works: When a delivery egg is generated that area will be marked as the "captivity area". Xenomorphs born within this area now have their own team, and have their own section in the roundend report that will greentext them based on if they were able to survive and escape captivity. Xenomorphs born outside of this area will spawn as normal Xenomorphs, with no escape objective or special fanfare. To further encourage people from actually taking the role and potentially resigning themselves to an hour in Xenobio CBT prison, the first of the hive gets their own header on the roundend report. (When I say "team" here, I mean they receive a different antag team datum. They're still able to collaborate and cooperate with other Xenomorphs, they just have a different title and extra objective in addition to the bonus roundend report limelight.)   (This also adds a basic "survive and advance the hive" objective for all xenomorphs, since their objective popup was otherwise completely blank). Since the captivity area is entirely dependent on the location of the egg itself, admins can plop one of these down anywhere, and mappers don't have to put the egg mapping helper specifically in Xenobio. For clarification -- To be qualified for the Captive Xenomorph team, **a delivery egg must be spawned**, and the xeno you inhabit must be born in the same area the egg was spawned. If the queen breaks captivity and starts nesting elsewhere on the station, their children will be born as normal Xenomorphs, not Captive Xenomorphs. ## Why It's Good For The Game Adds a bit of distinction, and gives bragging rights, to anyone bold enough to take a roundstart xeno roll and escape with it. The Xeno egg delivery is already rare enough, I think it deserves a bit more fanfare (especially considering the dramatic impact it sometimes has on the direction of a round). ## Changelog :cl: add: Xenomorphs born in the room the roundstart delivery egg was spawned in will be part of a special "captive xenomorph" team, tasked with escaping and tracked in the roundend report. fix: Regular Xenomorphs no longer receive a blank objectives popup on spawn. /:cl:
## About The Pull Request  It looks like this task has fallen to me. The reason this was originally removed was threefold: - Having your brain replaced would ghost you. - Having your lungs replaced would often instantly kill you in a way that people would take a long time to notice. - Several abstract or otherwise inappropriate organs could end up inside someone. I have solved all three of these problems using a blacklist. Lungs are simply never touched. Brains, sadly, are also never touched. We _can_ modify your brain without ghosting you and originally I implemented it that way, but the fact of the matter is that having your brain scrambled is essentially irreversible except via DNA infuser, if you had your brain replaced with a monkey brain which renders you unable to use complex machinery (or worse, a Psyker brain) there is very little that can be done about it. If people think that this is good to have anyway I can put it back in but it's probably for the best to leave it off. I moved the code that the DNA infuser used to safely implant a brain into a proc on organs when I originally expected that brain replacement would be a feature of this PR, but I've left it there in case anything else wants to do convenient brain replacement in the future (or already does and can be updated to use this method). The reason I didn't use a _white_list is because it seems like this list would easily become incredibly long and nobody would maintain it. A blacklist is slightly less safe, but reviewing the list it generates it seems fine. I also noted that the anomaly and the armour both implemented exactly the same code in two places, so I moved that into a proc on `carbon` instead. Now you don't need to apply changes in two places, and if anything else needs to do this in the future once anyone adds literally any items which use a bioscrambler core as material then it's easy for them too. Finally I scrubbed all cybernetics from the list and also made the anomaly not affect cybernetics. No strong reason for this one, just seemed like how it should work given that it's also blocked by bio armour. ## Why It's Good For The Game The bioscrambler in its current state doesn't do a whole lot, half of the things it changes are invisible under your clothes and often won't come up as a mechanical change unless you have developed chunky fingers or a sunlight allergy. This makes them somewhat more potentially dangerous and means people who are negatively effected might turn up at medbay asking for new eyes or a new stomach. Like the Dimensional anomaly it also introduces somewhat of a gamble feature. Some of the things on the list are _good_, and standing next to it might help you rather than harm you. Or more likely, both. As the infuser mechanic continues to add new organs with benefits and downsides it also makes this anomaly more interesting. Finally this gives the bioscrambler reactive armour a purpose, because now it means that people attacking you have a chance to spontaneously grow cat ears or snail eyes. ## Changelog :cl: add: Bioscrambler anomalies will once again swap your organs with other organs. balance: Bioscrambler anomalies no longer affect synthetic parts. /:cl:
…u use incorrect tool (tgstation#74184) ## About The Pull Request currently if someone is in surgery you can only harm them with a surgical tool if you are in combat mode the way the check works is that it only applies to tools that have the SURGICAL_TOOL item flag prosthesis organ manipulation is the only surgery that uses normal engineering tools, and because it involves steps with normal tools, it means that if you forget or misclick you can easily hurt someone with the wrong tool this makes that not happen anymore ## Why It's Good For The Game i feel like it makes sense for the surgery that uses engineering tools as surgery tools to treat engineering tools as them, with the same considerations with regards to only having you bludgeon the patient if you wanted to ## Changelog :cl: qol: Prosthesis organ manipulation now warns you if you are using the incorrect engineering tool /:cl:
…ial densities (tgstation#74163) ## About The Pull Request These changes fix how machines are pried open with crowbars. Currently, most machines can be pried open, but many of them have no method for being closed again. This means they can be pried once, and then never again (as their internal logic has them stuck in an "open" state). Additionally, the densities of these machines is also inconsistent, as density is tied to the procs for opening/closing machines (open = non-dense, closed = dense). Thus, these new changes allow desired densities to be passed to `open_machine()` and `close_machine()`, as well as `default_pry_open()`, meaning that atypical machine densities can be maintained (e.g. machines that should remain dense when open, or non-dense when closed). I've also added a `close_after_pry` boolean parameter to the `default_pry_open()` proc, which determines whether to immediately close a machine after opening it. This is useful for machines that don't really have a use case for remaining open, often lacking a sprite to represent this state as well. * Note: Opening and immediately closing machines with this boolean will still drop their contents onto the floor, but will now immediately "close" in their logic, allowing for further prying attempts in the future. It's worth noting that this implements default density values for these procs, which match the existing behavior for machines, so as to (hopefully) not disrupt existing or expected machine behavior. Two caveats to these changes currently exist: 1. On machines that immediately close after prying, the prying action can now be spammed to the chat with repeated clicking. I'm uncertain if this needs some sort of spam protection or if it's fine as is. 2. I've only been able to manually test this code. I'd love to write unit tests for it, as it affects a lot of different machines, but don't know where to begin with DM Unit Testing (or which files would be good examples to reference in the code base). * Note: I did manually test each and every machine that calls `default_pry_open()` and they all seem to be working correctly. (Except for `obj/machinery/plumbing/sender`, but that doesn't seem to need prying, as it has no contents to drop, only reagents.) As always, let me know if any improvements/changes should be made. This closes tgstation#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 :cl: fix: machines can now be pried open more than once. fix: machines now have the correct density when pried open. /:cl: --------- Co-authored-by: san7890 <the@san7890.com>
) ## About The Pull Request I thought it would be fun to learn mapping with [this guide](https://hackmd.io/QBaz0CaTRhOp7pEnUlXnzQ), and perhaps along the way I could make a bit of content that I would like to see in space some day. I wanted to create an only recently abandoned space structure that is relatively small but could be used as a pitstop for space-travelling spessmen to rest and recharge, perhaps even be used as a second base for further exploration. The structure starts unpowered, but after you break in, you can turn on the APC (starts unlocked) and set the solar panels to generate power. With all it's amenities, it's similar to the "Space Bunker" (deepstorage.dmm), but of course much smaller. There is not much in terms of loot, just a random toolbox, night vision goggles and a better capacitator for the charger. With all the new space ruins upcoming, perhaps its not the worst idea to have a place like this.   _Since this is my first map, I might have missed some things. I am a little bit torn between "it does not look abandonded enough" and "it should look nice because its a resting point"._ ### Mapping March Ckey to recieve rewards: LordVollkorn ## Changelog :cl: LordVollkorn / Gage Gaebler add: Added Traveler's Rest, a tiny space structure for space travellers to relax and to prepare for the explorations ahead. /:cl:
…special attack instead of a universal click cooldown (tgstation#74159) ## About The Pull Request Rather than using a click cooldown, the tendril hammer instead can make its special heavy attack every 2 seconds. ## Why It's Good For The Game In my newfound quest to try and eliminate universal click cooldowns or weird non-interactivity timers as balancing factors, this definitely is one of the biggest standout offenders. Lemme make an argument for universal click cooldowns increases being an ineffective limitation. I'll use the problems presented by the tendril hammer to highlight some of those problems, as well as unique problems to the tendril hammer itself. <details> <summary>da big discussion</summary> A) The functionality of the hammer actively inhibits all in-game handuse interaction for several seconds, without explaining this to a player. As a player, you won't know why this is happening, as universal click cooldown is not present as a UI element. B) Since universal click cooldowns are not visible to players, it might feel more like the game is malfunctioning rather than being a deliberate mechanic. Even if click cooldowns were visible, players probably would think that the cooldown applies to the hammer, and not handuse interactivity with the game world as a whole for several seconds. C) The functionality of the hammer could work fine as an internal cooldown on the hammer, only relevant to the hammer. This ensures that its special effects are exclusive, without the need to interrupt player interaction as a whole. D) Since we're talking about miners. If someone is concerned about the hammer being used on the station against carbon players; you need someone to help mutate you into goliath mutant, which cannot be bypassed whatsoever. An excellent example of something similar is the chainsaw arm, created right next door to genetics in robotics, which does even more force than the arm and is sharp. With the limitations that exist, I think it probably discourages most powergaming, if that was even a realistic concern (it really isn't). E) You lose both a hand AND your gloves slot when you get the hammer. No modsuits, no glove equipment, no two-handed equipment, and you now have to juggle everything with one hand assuming you're not on your, once again, universal click cooldown for several precious seconds. Miners live or die in their rapid response to problems. This is also the total sum of what you lose as a miner. That's a steep cost and it just doesn't justify its own value compared to what you lose. </details> TL;DR - There is no offset to the cost of this weapon, it is strictly a detriment because of poorly conceived implementation. This is maybe one of the coolest ideas conceptually for the infusions so far, heavily hampered by what seems to be an intense fear of the mutation being _too useful_. So it was made _borderline masochistic to willingly seek out and use_. I want to see this actually be useful. I can't see this with the restrictions it has. Hopefully this is enough to make it worthwhile getting. ## Changelog :cl: balance: Changes the universal click cooldown of the tendril hammer from the goliath infusion into an internal cooldown just for the special heavy attack. /:cl: --------- Co-authored-by: Jacquerel <hnevard@gmail.com>
## 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 alright alright, before the MOB chases me down for this heretical pr. let me explain so, you know empty space tiles? they shouldn't have nearstation areas so, you know those tiles with turfs on them in space? they should have nearstation areas what am i even doing anymore missing nearstation area  there shouldn't be nearstation here  ### Mapping March Ckey to receive rewards: Spockye ## Why It's Good For The Game standardization good! ## Changelog :cl: fix: fixed some tiles missing nearstation on Metastation fix: fixed some tiles having spacetiles with nearstation on Metastation /:cl:
…maly placer blacklist (tgstation#74252) ## About The Pull Request Fixes tgstation#74108 it seemed easy enough to fix so I thought I'd knock it out really quick ## Why It's Good For The Game Was kind of frustrating that an anomaly could appear in a place where it wouldn't affect anything, now that's gone! ## Changelog :cl: fix: Anomalies will no longer spawn at the bomb testing range satellite. /:cl:
… be airless tiles (tgstation#74253) ## About The Pull Request The solar panel tiles of the Traveller's Rest had air, which caused roundstart active turfs. This PR fixes that. ### Mapping March Ckey to receive rewards: N/A ## Why It's Good For The Game Less alerts during initialization. Closes tgstation#74245 ## Changelog Nothing player facing
## About The Pull Request Part of CTF fourside had an area passthrough instead of a ctf area, this resulting in the yellow spawnpoint having incorrect lighting on some wall turfs. ## Why It's Good For The Game Bugfix ## Changelog :cl: fix: CTF fourside's yellow spawnpoint walls now use the same lighting as the rest of the map instead of space lighting. /:cl:
…on) (tgstation#74224) ## About The Pull Request Before, dogs were somehow magically able to drag their bed to you while barking at/chasing you. that's silly, let's fix it by checking if you're buckled, and then aborting course if we're comfy on our little bed ## Why It's Good For The Game  Fixes tgstation#74082 the dog is BUCKLED. it can't move. probably a better fix to this somehow on a very deep AI level but that wouldn't allow us to have such a soulful message (as well as potentially rule out a myriad of edge cases), so i'm proposing this one. ## Changelog :cl: fix: If you buckle a dog to a bed, it will no longer drag its bed as it goes to bark at the mailman. It will instead be comfy and chilling, as expected. /:cl:
) ## About The Pull Request Did you know that there's 2 types of disks Science can print? One of them creates a whole new techweb and is used to transfer data to and from techwebs (which used to be for Theft objective, but nowadays all it's used for is Admin techweb). The other one is these disks you can find from Lavaland & for the Limbgrower which holds nodes on them directly, they don't need anything else. These are both printable and have very similar names which could easily confuse people, especially since they are both printed and used at the same place, being the R&D room and R&D console. This will hopefully simplify it, by removing the base Tech disks from being printable. The only one that can be printed now is for Limbgrowers, which can't be easily mixed with the other type of Disk. Outside of that, Lavaland disks are staying the same, but I've moved Bepis disks to use this, which allows us to remove Bepis techwebs being made every single time a new bepis disk is created. Examples of it in-game    ## Why It's Good For The Game There's no reason why every single Bepis node should be making a whole new techweb set with experiments to complete, roundstart nodes researched, being constantly checked if it should gain research points, have a list of papers to publish, and everything else that techwebs do. Can you guess which disk does what in this screenshot?  ## Changelog :cl: balance: You can no longer print Technology data disks. You can still print Tech disks, which hold techweb information on it, just not the one that holds up to 5 nodes. balance: ^ Because of this, there's no way to download nodes from an RD console and upload them to an Autolathe to bypass departmental restrictions, you have to go through a Techfab/Circuit imprinter for your needs. balance: Ones that are found cannot have anything uploaded/deleted off of them either, you can only upload them to the Web. code: Every individual Bepis disk no longer create an entire techweb /:cl:
## About The Pull Request I had to add new Windows signatures to auxtools so it would work on 515. I then had to bump the auxtools lua dependency and push a new release version. This PR bumps the auxlua dependency version. ## Why It's Good For The Game Fixes admin lua scripting on Windows for 515, for now (it will probably break again as more 515 beta releases come down the pipeline, but what else can you do about it? It's probably still broken on Linux but that's because nobody's found the 515 function signatures on Linux.) ## Changelog :cl: admin: Fixed admin lua scripting on Windows-hosted servers running on beta version 515.1602 (the latest version as of this change) /:cl:
dwasint
pushed a commit
to dwasint/Monkestation2.0
that referenced
this pull request
Aug 22, 2023
…nent (tgstation#77539) Hey there, I've personally fallen for this stupid thing twice (in tgstation#77503 and tgstation#75627 (d357516)), 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. 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 Monkestation#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 Monkestation#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 Monkestation#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 Monkestation#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 Monkestation#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 Monkestation#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 Monkestation#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 Monkestation#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 Monkestation#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 Monkestation#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 Monkestation#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 Monkestation#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) :cl: fix: Growing spiders will now retaliate against you like they were always meant to. /:cl:
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
About The Pull Request
Mapping March
Ckey to receive rewards: N/A
Why It's Good For The Game
Changelog
🆑
/:cl: