031e483e4d
* New station trait job: Human AI (#81681) This PR does many things, I'll try to explain the basic/background stuff to the main thing first: 1. Adds a new remote that allows a human to function like an AI. It controls a fly that will fly around the station slowly, and when it reaches a machine then the person can interact with it as if they were an AI. This required changing a lot of silicon/AI checks with one that also checks for this remote, and some messing with shared ui state. 2. Moves req_access from the obj and bot to ``/atom/movable`` which lets it be shared between the two, no more copy-paste and one side lacking features/checks/signals the other has. 3. Adds a check for AI config for AI-related station traits, which was lacking prior Now for the good part... Adds a new station trait that replaces the AI with a Human. This person is equipped with an AI headset (including Binary), an advanced camera console, an omni door wand, the machine controller, and their laws. They are immune to the SAT's turrets (even if set to target borgs) and are slow outside of the SAT, mimicing the actions of the AI. They interact with the world through their advanced camera console, which allows them to do most AI stuff needed, and the holopad they can connect to without having to ring first (like Command can). They are given a paper with the laws they must follow, but since they are human they are able to bend it. Cyborgs that run the default lawset are "slaved" to them via an unremovable law 0, so the Human AI can bend the laws if they really need to (for their own survival n such), and make the cyborgs obey their commands above laws, but in general this shouldn't be a frequent occurrence. This does take into account the unique AI trait, so it's not guaranteed Asimov. When this station trait rolls, all Intellicards, AI uploads, and AI core boards are destroyed and are unresearchable. They can be spawned by admins in-game if necessary. Maybe in the future we can also exclude Oldstation from this but I haven't really decided. Extra perks: Human AI spawns with a Robotic voicebox (unless they are a body purist) and teleport blocking implant, so they can't use teleporters to bypass their on-station slowdown. They also have an infinite laser pointer that can be used to blind through their camera console. This is unfortunately nerfed from the recent borg balance PR that removed its stun. This was meant to be the alternative to no longer being able to permanently lock borgs down like AIs can (or more than one, for that matter). They aren't affected by Roburgers, Acid, and Fuel's toxicity. Bots salute them like they do Beepsky (which is now a trait) They spawn with SyndEye to replace the AI's tracking ability They do not have a bank account The machine remote has a little fly in it that flies to the machines it is pointed to, working as the arms and legs of the Human AI. It scans the machine and punches in the action the AI does, and is how the AI accesses basically anything. This fly slowly moves from one machine to the next, and can be recalled with Alt Click. It works on machines and bots. https://github.com/tgstation/tgstation/assets/53777086/e16509f8-8bed-42b5-9fbf-7e37165a11e8 I've seen a funny screenshot one day of a person replacing the AI by using a bunch of door remotes, camera console, crew monitoring console, and a few other things. I've been thinking about that for a few years and really wanted to make it official if not easier to make possible, because it is an incredibly funny interaction. This makes it a reality, and while they aren't as powerful as regular AIs, I think it makes for better and funnier in-game moments. With the same weight as Cargorilla (1), I hope this wouldn't be rolling too often and ruin rounds, but instead show off the different capabilities that Humans and AIs can do, to do the job of an AI. You win some you lose some. 🆑 JohnFulpWillard, Tattax add: Adds a new station trait job: The Human AI. /🆑 --------- Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> * Oh right * so this works * whoooops --------- Co-authored-by: John Willard <53777086+JohnFulpWillard@users.noreply.github.com> Co-authored-by: MrMelbert <51863163+MrMelbert@users.noreply.github.com> Co-authored-by: Useroth <37159550+Useroth@users.noreply.github.com> Co-authored-by: Pinta <68373373+softcerv@users.noreply.github.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.