8fa6242c66
## About The Pull Request The high luminosity eyes item was extremely out of date, broken, and full of copy paste code from atom lighting. Which is a shame because they were cool. On top of all that it was using a special light effect that was not very performant. I got rid of all that, hooked it into atom lighting as a new light type, and gave it a new TGUI as well because the old ui prompts were not great either. You can now pick a color at random if you want. You can also set the color and range before surgically implanting them. No more being forced to go through the color picker when you just want to change the range. Functionally they should pretty much should be the same as before with some bonus features (see below).  Closes https://github.com/tgstation/tgstation/issues/61041 Closes https://github.com/Skyrat-SS13/Skyrat-tg/issues/14685 This is 100% completed. I just finished fixing the slight translation bug when going from 0->1 range (see above gif) and that was the last thing on my bucket list. I happy enough with this at this point in time. --- EDIT: I have decided to add in one last new feature, and that is... independent settings for eye color. <details> <summary>You can now set eye color independently if you wish</summary>  </details> The eye color does not modify the light color in any way when set in this manner, but it can be used for cosmetic purposes. Kind of makes the item more like cybereyes from cyberpunk, which I think are pretty neat! </details> ### What I've done, in more detail: - refactored high luminosity eyes so they use the atom lighting system instead of the way they were doing it before - the new light type, `MOVABLE_LIGHT_BEAM` behaves similarly to directional lights, with some slight differences. it reuses the same lighting overlay sprites but scales them vertically to produce a more focused effect. The result can be seen above. This is in contrast to the old way, which spawned `range` number of individual 32x32 overlays and moved them around. This way should perform better as well as be more maintainable. - added a new TGUI interface for high luminosity eyes with buttons for range, a text field for a color hex, a color picker and randomizer - made the eye overlay emissive when the light is turned on - range goes from 0 to 5. at range 0, the light overlay is turned off and you are left with just the emissive eyes. - added a cosmetic functionality to this item that lets you change the color of your eyes independently of the lighting (and each other) - fixed a bug with directional flashlights sometimes not updating their lighting overlay if you pick them up without changing your direction --- ### Other Misc Fixes Being able to dynamically set range back and forth exposed some logic issues that had existed with directional light overlays and I have fixed those. That is why there are some edits in that file that may not appear readily obvious why they are there. Apart from that, two other bugs that come to mind: 1) eye code was supposed to keep track of the eye color you had before you got new eyes, but it was overwriting that every time you ran refresh(). 2) lighting was supposed to be turning off the light when range is set to 0, but it was not doing that properly. And of course besides that, there may have been a few instances of finding typos/tidying up code ## Why It's Good For The Game The code for this was like 6 years old and in desperate need of updating. Now it works, and has a nicer UI. ## Changelog 🆑 fix: high luminosity eyes light overlays now follow the user correctly qol: high luminosity eyes now have a tgui menu so you no longer have to go through the color picker every time you want to change the range. they also have a new setting that lets you change the color of your eyes independently of the light color. You can now have cybernetic heterochromia if you want fix: directional flashlights when picked up will now always update their cast light direction correctly no matter what dir you are facing refactor: refactors high luminosity eye code to better make use of the atom lighting system, adding a new light type 'MOVABLE_LIGHT_BEAM' /🆑
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.