434e4e435e
## About The Pull Request  Pre-discussed with @Watermelon914, this PR removes Secondary & Final Objectives from all Traitors, rather than just midround ones. It also removes all of the surrounding supporting code. Randomly assigned Primary Objectives still exist, I just used the ability to rewrite mine to take the screenshot. In terms of final objectives, the surrounding items that were available still exist but don't necessarily have sources. If anyone has good ideas for readding these in some other form it can be done in future PRs. It also allows all traitors to buy the Contractor kit, previously limited to midround traitors which lacked secondary objectives, because now all traitors lack secondary objectives. This essentially limits all traitors to a maximum of 20 TC (16 if they spawn with an uplink implant). Currently I don't foresee that they strictly need any additional way of gaining TC during a round as 20 is quite sufficient, but it may take some time to adjust and get used to it after such a long time of having access to more. If we need to adjust the starting value or add a slow drip of more points over time or something, that can be done in followup PRs. This also removes the ability to recreate your uplink added by my beautiful wife in #74315 This was part of the progression traitor design document, but ultimately probably a bad idea as it essentially made traitors impossible to properly disarm. You will once more just need to carefully protect your uplink. **This does not remove the threat/progression system**. Like midround traitors, all Reputation requirements on gear are now simple timelocks, most of which will have elapsed by the time 30 minutes have passed. **Finally** this PR also adds Romerol to the traitor uplink for 25 TC and 30 minutes of reputation, as a treat (and because I removed the final objective that previously granted it). ## Why It's Good For The Game We've tried this system for a long time (3 years last month!) and while I think it had a lot of promise, enabled some cool moments, and also solved several of the problems it set out to solve, overall I think some of the behaviours it has encouraged in players have been overall negative for the game. While the _game systems_ are fine, even quite fun and cool (especially final objectives) I am of the opinion that having them in the game creates a net negative purely in the way that they react with players' _brains_, creating incentives towards behaviour we don't actually want people to pursue. While it's hard-to-impossible to prove any of this with hard data, there has been a prevailing feeling for some time among many (though certainly not all) people that the simple fact of _having_ a constant drip-feed of objective available to players leads directly to less interesting antagonist play. While certainly nobody is _forced_ to do secondary objectives you are directly and quite strongly rewarded for doing so, doing so efficiently, and doing so in a way which makes sure that nobody (alive) sees you do it. This leads to a tendency to play defensively and try to maximise the number of tasks you can complete in one round, which also has a knock-on effect of generally minimising the number of people you attempt to interact with in a round (unless you are killing them). Even people who _intend_ on doing some more interesting gimmick can fall into this trap, as "having more tools" is always useful for anyone who is intending on any kind of plan at all, but then executing on the secondary objectives again incentivises you to lay low, not interact with anyone, be efficient, and then reduces the time you are spending doing the thing that's your actual plan for the round. Removing the ever-present temptation to fish for extra TC leaves "doing whatever your actual plan is" as the sole thing to optimise. Final Objectives too have created unfortunate psychological effects between crewsided players and other antagonists. Because of the _threat_ (no matter how remote, Final Objectives have always been tuned to be appropriately rare) that leaving any antagonist alone will cause them to snowball by acquiring more power, it starts to feel foolish to respond to any threat with less than the maximum possible level of force even if they seem relatively innocuous in the moment. This even has an effect on other non-progression antagonists, as traitors are the most common antagonist type and how people treat them is going to be their default level of reaction to most other station threats. While there has always been the promise of expanding the system with novel and exciting objectives that leverage appearing mid-round to do something unique, we've taken very little advantage of that over time. Most objectives we have added that didn't boil down to "kill someone, with a twist" have been somewhat unsuccessful, serving either as ways to get yourself arrested and killed for no reason or ways to get free telecrystals by doing something the crew don't really care about stopping you from doing. The option still exists to add more roundstart objectives to traitors, if someone suddenly has a great idea that would fit in this space. The ideal outcome of making this change is a slight relaxation of crew attitude towards feeling like their only option after catching an antagonist that isn't sandbagging is to permanently remove them from the round (although it's fine to do this still in many scenarios), and a broadening of traitorous activity which is not purely focused on collecting as many checkboxes as possible and might give people more time to roleplay with other players, not worrying that this time could have been more efficiently spent pursuing a different secondary goal. I don't anticipate or desire that this will prevent traitors from killing anyone (or even stop them from killing people they don't have a specific objective to kill), I just want to remove the FOMO from people's minds. Also this gives us something to talk about at the coder townhall meeting on the 22nd. ## Changelog 🆑 del: Misplaced or stolen traitor uplinks can no longer be recreated using a radio code and special device, guard yours carefully or buy a backup implant. del: Roundstart traitors can no longer take on additional objectives in order to earn additional Telecrystals and fast-forward any unlock timers on items. They also cannot earn the ability to complete a Final Objective. balance: Roundstart traitors can now buy the Contractor Kit from their traitor uplink, rather than only midround traitors. add: Traitors can buy Romerol for 25 TC, after 30 minutes of time has passed in a round. /🆑
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.