39a2434c06
## About The Pull Request Reworks the Voidwalker into a basic mob, including a lot of the balance and mechanics! Old (left), new (right)  https://github.com/user-attachments/assets/22d6138f-11aa-4f7a-8600-2565e6578bcf (little outdated) https://youtu.be/cp1E3qPJGX4 (high res mirror) **🟨Voidwalker mob changes🟨** No longer a human species and no more void eater. Instead deals damage by simple unarmed attacks. Instead of dealing brute, the voidwalker does oxygen damage (4-5 hits to knock out) with left-click, and slight brute on right click. Non-human mobs automatically take brute damage instead of oxygen damage. 150 HP 33% burn armor Yes it has hands, but it can only pick up and drop stuff **🟨Window phase🟨**  Instead of needing to smash a window with the void eater, moving through windows simply leaves them passable for 5 seconds. Makes kidnapping a lot easier, but also makes it easier for people to chase you People who used the voided skull also leave windows passable for a short bit. **🟩Cosmic Charge🟩** Standard charge ability, but only lets you charge towards space and works while dragging people **🟩The Vomitwalker🟩** People you kidnapped now occasionally do the nebula vomit, which voidwalkers can use to dive from and into  Diving into it is very fast but also removes the nebula vomit. You can also kidnap people into the vomit (this doesn't remove the vomit). There is also a little UI for tracking this. Clicking it while in space dive teleports you to the next nebula vomit, if there are any.  **🟨Voided people changes🟨** Kidnapped people and people that used the cosmic skull are no longer muted, but take 10% extra brute and occasionally leave behind glass shards when taking a lot of damage. Are no longer obliterated on a second encounter with voidwalkers. Voidwalkers can't hurt people they've already voided (unless they really want to), but instead just knock them out for 30s Also the kidnapped do space vomit as I said earlier. **🟩Sunwalker🟩** Voidwalker variant made for pure murderbone. Has no camo and kindap mechanics, but has a fiery charge, loads of damage and area igniting and people ignition. It's admin, but I might change this later once I've had some more time to think about it.  Other changes: - Voidwindows no longer need to be space adjacent - Unsettle works faster but can't be used in combat anymore - Space camo now grants complete space invisibility - Makes a lot of aspects easily moddable, so we can easily mod it into a moistwalker in-game - Taking a cosmic skull when you already used one gives you the old voidwalker void eater arm. Additional uses just gives you more void eater arms until you run out of hands - I definitely forgot a lot more - I made a cool voidwalker hud! It even has a unique space camo toggle ## Why It's Good For The Game <details> <summary>Lot of text</summary> Voidwalker was basically a snowflaked toghether human species because I didn't know how to sprite, but I was able to work with species and visual effects. Then I realized I can just commission sprites! This also let me just cut out a lot of the snowflake code, because it's no longer a human so half the things I didn't want them to be able to do, they just literally cannot do. Voidwalkers were in a bit of strange spot with kidnapping? There was essentially no incentive, other than "smash spaceman = funny". They also had issues doing, anything? There's surprisingly little space on a space station, especially maps such as tram. Making the voided victims have nebula vomit gives the voidwalker a reason to WANT to kidnap, by giving them a way to appear basically anywhere on the station. I don't think it's too overpowered. Voided people don't vomit that much, it's easily cleanable and diving into it removes them, so they're limited usability. Replacing the brute damage with oxygen damage also kinda... just makes sense? I seriously contemplated letting them do stamina damage for the first iteration, but opted not to do it because stamina damage has so many hooks attached. Oxygen damage doesn't! It's also just incredibly thematic, let's them bypass most armor and makes them more suited to non-letha kidnappings. Space camo making them completely invisible was also long overdue. It was literally just urging people to turn up their gamma and turn down their parallax settings. I thought it was an interesting mechanic, but it's just straight up unfair and doesn't belong in a multiplayer game. They now more frequently leave behind little glass shards, leave particles from nebula vomit they leave from and have more unique sound effects, so attentive (and lucky) people can still deduce if an area is safe-ish. I removed being able to shatter voided people because the mechanic was deeply misunderstood. It was intended to give them a means of removing people if they kept incessently bothering the voidwalker, but people went out of their way to use this to roundremove people they had already voided. The 30s sleep conveys my intention a lot better, and fits better now that the voidwalker benefits from having as many voided people vomitting all over the place. The cosmic charge gives them some much needed survivability. My experiences (in observing voidwalkers, I can never get the roll ;_;) is that they're constantly one mistake away from complete obliteration. The cosmic charge let's them get out quick despite their slow movement speed in gravity. It also makes them stronger when fighting in space. They got 33% burn armor so it's a tiny bit harder to wipe them away in a single laser salvo, while still giving people ample opportunity to fight them off . Also they're like glass or something so it fits thematically. I gave them hands because I thought it was cool, might be a mistake idk </details> ## Changelog 🆑 Time-Green, INFRARED_BACON add: Voidwalker has been throughly reworked! Now you are even less safe! admin: Adds admin-only Sunwalker mob fix: Unsettle doesnt work on yourself anymore fix: Space camo doesnt stop bobbing anymore fix: Voidwalker windows now recharge on kidnap runtime: Fixes healthanalyzers runtiming when scanning mobs without reagent holders /🆑
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.