c5f1b7f8c3
## About The Pull Request This PR makes a number of changes focusing on improving the blob minions, spores, nauts, zombies and their associated component. ## New sprites The blob spore, blob zombie and blobbernaut has been resprited. The spore and zombie have been lightly touched to preserve the most of the original characteristics while given a cleaner look. The spore and zombie have a partially desaturated version used to let more of the strain colour through instead of them all ending up dark brown. The blobbernaut has been reshaded and the side sprite has been made coherent with the front state, I made decided how the front state was shaded should be the "canon" one (this might be a bit controversial but the wild inconsistency was bugging me.) The blobbernaut is a bit less veiny, but the veins look more natural and use the strain complementary colour. Many combinations are cool, some are a bit lacking due to the weird choices of complementary colour.   ## New Cytology Related Features Blob mobs can now have strains independently of an overmind. The 15% mutation chance of vat grown creatures causes a spore or blobbernaut to get a random strain. When I first added the blob spore cell line, ghosts could click on cyto blob spores to posses them, they would then presumably(?) but not explicitly be free antags. This ability was lost when the blob spore code was modernised. Very few people knew about this, and no one grew blob spores anyway. This feature is coming back in a big way, vat grown blob spores present a new unique job hazard, they are automatically offered to ghost as an extremely shitty, but free antag. I have tested spawning like 15 antag pre-buff blob spores in a live round and they failed completely to antagonise the crew effectively, hopefully these buffed spores won't present too much of an issue to our great administration team, if that ends up being the case, there are many levers to pull to tone them down. ## Blob Spore Buffs Blob spores prior to this PR were almost completely useless. The main cause of this was the extremely dilute reagent smoke reaction; 10u divided over 20 seconds. This resulted the smoke clouds dealing 0.15 - 0.6 DPS, a completely negligible and useless amount. The smoke reagent concentration has been massively increased(10u -> 40u) and the smoke duration has been reduced(20s -> 8s). The result of this is that blob spore clouds are something you want to avoid standing in, but they provide less smoke cover for the blob and nauts. Blob spores have also gained the ability to vent crawl. Simple mobs that can't either open doors or vent crawl feel super bad to play. They also deal a little more melee damage, but this is still pathetically low on account of their low attack speed. I have adjusted their supplementary reagents and reduced the amounts of spores produced per cycle(2 -> 1) to make them a bit harder to mass produce. ## Blob Strain Buffs I have not made this PR with the goal of buffing any particular strain, but some changes have affected blob strain balance: ### Debris Devourer This was the only strain that was strongly mechanically tied to the core. In order to allow for independent debris devourer mobs, they can now eat trash(or any item really), they are independent, they store these items inside their mob, and use these for the debris devourer reactions. If they have an overmind, the item gets sent to the core. This should result in a nice buff to the strain, which I've been told is one of the bad ones. ### Regenerative Materia & Cryogenic Poison 5 years back another contributor removed the ability of blobs and blobbernauts to transfer reagents with their attacks(as their expose method is vapour). This was a completely undocumented change and possibly unintentional, so I am reverting it by giving blob reagents penetrates_skin = VAPOR again. This only really affects these two strains. It makes regenerative materia much stronger, while barely having any effect on cryogenic poison, because temperature normalisation changes has made it completely ineffective even with much more reagent applied. ### Electromagnetic Web The spore reagent cloud buff might also give a boost to some strains with good expose effects, like electromagnetic web. ## Blob Cooking Blob spores now drop spore sacks, they can be ground for spore toxin, or cracked on a griddle to create an egg-like treat! I also added a detoxification reaction to reduce the amount of toxin when cooked, might not work yet because I think griddles may not actually heat the food? ## Sound Effects Blob spores bursting and blobbernauts dying have sound effects. ## Why It's Good For The Game level 5 biohazard ## Changelog 🆑 image: blob mobs have been respectfully resprited. add: vat grown blob mobs can sometimes get born with a blob strain. add: blob spores drop spore sacks, crack them on the griddle. add: debris devourer mobs can now eat trash, sending it to the core, if there is one. add: vat grown blob spores are now sentient and evil. balance: blob spores now have much more concentrated smoke. balance: blob spores can ventcrawl. fix: regenerative materia and cryogenic poison strain blob tiles & nauts now inject chems again. sound: blob spores & blobbernaut now have death sound effects. /🆑
Unit Tests
What is unit testing?
Unit tests are automated code to verify that parts of the game work exactly as they should. For example, a test to make sure that the amputation surgery actually amputates the limb. These are ran every time a PR is made, and thus are very helpful for preventing bugs from cropping up in your code that would've otherwise gone unnoticed. For example, would you have thought to check that beach boys would still work the same after editing pizza? If you value your time, probably not.
On their most basic level, when UNIT_TESTS is defined, all subtypes of /datum/unit_test will have their Run proc executed. From here, if Fail is called at any point, then the tests will report as failed.
How do I write one?
- Find a relevant file.
All unit test related code is in code/modules/unit_tests. If you are adding a new test for a surgery, for example, then you'd open surgeries.dm. If a relevant file does not exist, simply create one in this folder, then #include it in _unit_tests.dm.
- Create the unit test.
To make a new unit test, you simply need to define a /datum/unit_test.
For example, let's suppose that we are creating a test to make sure a proc square correctly raises inputs to the power of two. We'd start with first:
/datum/unit_test/square/Run()
This defines our new unit test, /datum/unit_test/square. Inside this function, we're then going to run through whatever we want to check. Tests provide a few assertion functions to make this easy. For now, we're going to use TEST_ASSERT_EQUAL.
/datum/unit_test/square/Run()
TEST_ASSERT_EQUAL(square(3), 9, "square(3) did not return 9")
TEST_ASSERT_EQUAL(square(4), 16, "square(4) did not return 16")
As you can hopefully tell, we're simply checking if the output of square matches the output we are expecting. If the test fails, it'll report the error message given as well as whatever the actual output was.
- Run the unit test
Open code/_compile_options.dm and uncomment the following line.
//#define UNIT_TESTS //If this is uncommented, we do a single run though of the game setup and tear down process with unit tests in between
There are 3 ways to run unit tests
-
Run tgstation.dmb in Dream Daemon. Don't bother trying to connect, you won't need to. You'll be able to see the outputs of all the tests. You'll get to see which tests failed and for what reason. If they all pass, you're set!
-
Launch game from VS Code. Launch the game as normal & you will see the output of your unit tests in your fancy chat window. This is preferred as you can use the debugger to step through each line of your unit test & can use the games inbuilt debugging tools to further aid in testing
-
Use VS Code Tgstation Test Explorer Extension. This allows you to run tests without launching the game & can also run focused tests(either a single or a selected group)
How to think about tests
Unit tests exist to prevent bugs that would happen in a real game. Thus, they should attempt to emulate the game world wherever possible. For example, the quick swap sanity test emulates a real scenario of the bug it fixed occurring by creating a character and giving it real items. The unrecommended alternative would be to create special test-only items. This isn't a hard rule, the reagent method exposure tests create a test-only reagent for example, but do keep it in mind.
Unit tests should also be just that--testing units of code. For example, instead of having one massive test for reagents, there are instead several smaller tests for testing exposure, metabolization, etc.
The unit testing API
You can find more information about all of these from their respective doc comments, but for a brief overview:
/datum/unit_test - The base for all tests to be ran. Subtypes must override Run(). New() and Destroy() can be used for setup and teardown. To fail, use TEST_FAIL(reason).
/datum/unit_test/proc/allocate(type, ...) - Allocates an instance of the provided type with the given arguments. Is automatically destroyed when the test is over. Commonly seen in the form of var/mob/living/carbon/human/human = allocate(/mob/living/carbon/human/consistent).
TEST_FAIL(reason) - Marks a failure at this location, but does not stop the test.
TEST_ASSERT(assertion, reason) - Stops the unit test and fails if the assertion is not met. For example: TEST_ASSERT(powered(), "Machine is not powered").
TEST_ASSERT_NOTNULL(a, message) - Same as TEST_ASSERT, but checks if !isnull(a). For example: TEST_ASSERT_NOTNULL(myatom, "My atom was never set!").
TEST_ASSERT_NULL(a, message) - Same as TEST_ASSERT, but checks if isnull(a). If not, gives a helpful message showing what a was. For example: TEST_ASSERT_NULL(delme, "Delme was never cleaned up!").
TEST_ASSERT_EQUAL(a, b, message) - Same as TEST_ASSERT, but checks if a == b. If not, gives a helpful message showing what both a and b were. For example: TEST_ASSERT_EQUAL(2 + 2, 4, "The universe is falling apart before our eyes!").
TEST_ASSERT_NOTEQUAL(a, b, message) - Same as TEST_ASSERT_EQUAL, but reversed.
TEST_FOCUS(test_path) - Only run the test provided within the parameters. Useful for reducing noise. For example, if we only want to run our example square test, we can add TEST_FOCUS(/datum/unit_test/square). Should never be pushed in a pull request--you will be laughed at.
Final Notes
- Writing tests before you attempt to fix the bug can actually speed up development a lot! It means you don't have to go in game and folllow the same exact steps manually every time. This process is known as "TDD" (test driven development). Write the test first, make sure it fails, then start work on the fix/feature, and you'll know you're done when your tests pass. If you do try this, do make sure to confirm in a non-testing environment just to double check.
- Make sure that your tests don't accidentally call RNG functions like
prob. Since RNG is seeded during tests, you may not realize you have until someone else makes a PR and the tests fail! - Do your best not to change the behavior of non-testing code during tests. While it may sometimes be necessary in the case of situations such as the above, it is still a slippery slope that can lead to the code you're testing being too different from the production environment to be useful.