89cf4c7787
## The Voidwalker Adds a new antagonist, the Voidwalker! It's a rare antag that spawns in space when there's at least 40 people Design doc is here: https://hackmd.io/jE4YScP8RPykXo37rTBV2Q (there's some deviations) No biddle ## Summary Spooky space antag that moves around space, ambushing people either in space or near space. They can move through glass, have an ability to stamina drain you if they remain in your vision for 8 seconds, can temporarily remove glass windows to drag you through them and deal ~~stamina damage~~ incredibly violence. Upon being taken, they can be kidnapped and cursed, muting and pacifying the person and sending them to the void. ## Passive   Passive abilities: - Permanent space flight and indoor flight - Space regen - Slowdown when in gravity - Space camo (very low alpha when in space - Can freely move through unshocked glass - Mute, but can hear all station frequencies (excluding binary) - Will quickly die when on planets or moons (obviously can't roll on icebox) - 10 brute armor and 20 burn armor. They can't wear any form of armor and don't have any get out of jail free cards, so I think it'll help with their survivability a slight bit ## Abilities **Void eater:** Literally just a light-eater but instead of eating light it instantly shatters windows, but restores them after a few seconds **Space Dive:** New ability that lets you move under the station with a 2 second do_after, so they can still get to closed of space spots without being as annoying as heretic space shift **Unsettle:** Remain in view of the target for 8 seconds to give them a short stun, slurring and 80 stamina damage, but announce your presence and location to them. Both you and your target can move, as long as you remain in their view. **Space Kidnap:** When your target is incapacitated and in space, you can drag them into the cosmic void. They'll be returned cursed after undergoing a sort of reverse heretic sacrifice (more on that in the next section). [Showcase of all the above abilities!](https://youtu.be/NJ01H28PV9w) ## Voided Crew A brain trauma received when you get kidnapped. While under it's influence, you are muted and pacified. You will die in planetary gravity and cannot enter space.  It can be cured with a lobotomy or by dying in planetary gravity. You get warned to avoid the Voidwalker. The voidwalker now does extra damage and gets the option to glass gib you if you die, leaving just a brain ## Loot On death, the Voidwalker shatters into glass and drops a cosmic skull. Looking into the skull gives you a stable version of the Voided brain trauma. It doesn't give you pacifism and doesn't ban you from space. It also makes you space immune and gives you the ability to walk through unshocked glass after 2 seconds do_after. Sprites for the cosmic skull by Justice12354 and Rex9001! I'll throw up a video showcasing death and their sprites on Sunday ## Why It's Good For The Game We don't have any space centered antagonists. The closest we have are Space Dragons, but they have to go deep into the station anyway. I'm also quite fond of simpler antagonists, like revenant and nightmare. Give people the tools, and they'll make the fun themselves. I've been comparing the Voidwalker with the Nightmare. Both are goalles, simple antagonists, but where the Nightmare's gimmick is darkness, the Voidwalker's gimmick is space. They also get a dark tentacle arm so they can murderize people, but it only gets them to crit. After that they can drag people into the "void" to kidnap them. This is mostly to encourage the Voidwalker not to just space them cause that's kinda lame. They still can though, just in-case it would be very funny ## Changelog 🆑 Time-Green, Justice12354, Rex9001 add: Adds the Voidwalker, a new rare space based midround antagonist! code: Adds the ability to texture limbs and bodypart_overlays Sprite: Cosmic skull sprites by Justice12354 and Rex9001 /🆑 - [x] Add a better kidnapping mechanic, instead of just teleporting someone to a station turf - [x] Add an armblade or weapon or something, unarmed combat is kinda ass for this - [x] Fix the antag preview not rendering textures - [x] Prevent them from space phasing when in combat so they can actually be killed in space combat, even if really fucking hard - [x] Nerf visibility for people with space parallax disabled, probably also something to improve camo with colored parallax - [x] Replace the stamina damage stuff - [x] Cool rework of space phase idea I have - [x] Update/implement vidual effects - [x] Implement names ## Considerations There's a few things that I might change or implement later, depending on how it actually plays. It's a space focused antag, but there might not be enough people near space in a given round. An ability to let them "capture" area's or let them turn into a meteor or something might be needed later if they turn out to be too passive. They might also be _too_ oppressive in space. I designed them for near-space combat, but may've made them insanely overpowered in in raw space combat. Probably wont do biddle, but might add more powers that you can reroll every few minutes or something (like blob). Either wat it wont be this PR --------- Co-authored-by: carlarctg <53100513+carlarctg@users.noreply.github.com> Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: Jacquerel <hnevard@gmail.com>
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
Then, 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!
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.