diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index 7caec2cc793..79083339ae3 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -17,9 +17,9 @@ If you believe an issue report is not a "bug", please point out specifically and ### Comment Guidelines -* Comments on Pull Requests and Issues should remain relevant to the subject in question and not derail discussions. -* Under no circumstances are users to be attacked for their ideas or contributions. All participants on a given PR or issue are expected to be civil. Failure to do so will result in disciplinary action. -* For more details, see the [Code of Conduct](../CODE_OF_CONDUCT.md). +- Comments on Pull Requests and Issues should remain relevant to the subject in question and not derail discussions. +- Under no circumstances are users to be attacked for their ideas or contributions. All participants on a given PR or issue are expected to be civil. Failure to do so will result in disciplinary action. +- For more details, see the [Code of Conduct](../CODE_OF_CONDUCT.md). ## Issues @@ -29,7 +29,7 @@ reporting bugs in the code. ### Issue Guidelines -* Issue reports should be as detailed as possible, and if applicable, should include instructions on how to reproduce the bug. +- Issue reports should be as detailed as possible, and if applicable, should include instructions on how to reproduce the bug. ## Pull requests @@ -40,28 +40,28 @@ actual development. ### Pull Request Guidelines -* Pull requests should be atomic; Make one commit for each distinct change, so if a part of a pull request needs to be removed/changed, you may simply modify that single commit. Due to limitations of the engine, this may not always be possible; but do try your best. +- Pull requests should be atomic; Make one commit for each distinct change, so if a part of a pull request needs to be removed/changed, you may simply modify that single commit. Due to limitations of the engine, this may not always be possible; but do try your best. -* Keep your pull requests small and reviewable whenever possible. Do not bundle unrelated fixes even if not bundling them generates more pull requests. In case of mapping PRs that add features - consult a member of the development team on whether it would be appropriate to split up the PR to add the feature to multiple maps individually. +- Keep your pull requests small and reviewable whenever possible. Do not bundle unrelated fixes even if not bundling them generates more pull requests. In case of mapping PRs that add features - consult a member of the development team on whether it would be appropriate to split up the PR to add the feature to multiple maps individually. -* Document and explain your pull requests thoroughly. Failure to do so will delay a PR as we question why changes were made. This is especially important if you're porting a PR from another codebase (i.e. TG) and divert from the original. Explaining with single comment on why you've made changes will help us review the PR faster and understand your decision making process. +- Document and explain your pull requests thoroughly. Failure to do so will delay a PR as we question why changes were made. This is especially important if you're porting a PR from another codebase (i.e. TG) and divert from the original. Explaining with single comment on why you've made changes will help us review the PR faster and understand your decision making process. -* Any pull request must have a changelog, this is to allow us to know when a PR is deployed on the live server. Inline changelogs are supported through the format described [here](https://github.com/ParadiseSS13/Paradise/pull/3291#issuecomment-172950466) and should be used rather than manually edited .yml file changelogs. +- Any pull request must have a changelog, this is to allow us to know when a PR is deployed on the live server. Inline changelogs are supported through the format described [here](https://github.com/ParadiseSS13/Paradise/pull/3291#issuecomment-172950466) and should be used rather than manually edited .yml file changelogs. -* Pull requests should not have any merge commits except in the case of fixing merge conflicts for an existing pull request. New pull requests should not have any merge commits. Use `git rebase` or `git reset` to update your branches, not `git pull`. +- Pull requests should not have any merge commits except in the case of fixing merge conflicts for an existing pull request. New pull requests should not have any merge commits. Use `git rebase` or `git reset` to update your branches, not `git pull`. -* Please explain why you are submitting the pull request, and how you think your change will be beneficial to the game. Failure to do so will be grounds for rejecting the PR. +- Please explain why you are submitting the pull request, and how you think your change will be beneficial to the game. Failure to do so will be grounds for rejecting the PR. -* If your pull request is not finished make sure it is at least testable in a live environment. Pull requests that do not at least meet this requirement may be closed at maintainer discretion. You may request a maintainer reopen the pull request when you're ready, or make a new one. +- If your pull request is not finished make sure it is at least testable in a live environment. Pull requests that do not at least meet this requirement may be closed at maintainer discretion. You may request a maintainer reopen the pull request when you're ready, or make a new one. -* While we have no issue helping contributors (and especially new contributors) bring reasonably sized contributions up to standards via the pull request review process, larger contributions are expected to pass a higher bar of completeness and code quality *before* you open a pull request. Maintainers may close such pull requests that are deemed to be substantially flawed. You should take some time to discuss with maintainers or other contributors on how to improve the changes. +- While we have no issue helping contributors (and especially new contributors) bring reasonably sized contributions up to standards via the pull request review process, larger contributions are expected to pass a higher bar of completeness and code quality _before_ you open a pull request. Maintainers may close such pull requests that are deemed to be substantially flawed. You should take some time to discuss with maintainers or other contributors on how to improve the changes. -* By ticking or leaving ticked the option "Allow edits and access to secrets by maintainers", either when making a PR or at any time thereafter, you give permission for repository maintainers to push changes to your branch without explicit permission. Repository maintainers will avoid doing this unless necessary, and generally should only use it to apply a merge upstream/master, rebuild TGUI, deconflict maps, or other minor changes required shortly before a PR is to be merged. More extensive changes such as force-pushes to your branch require explicit permission from the PR author each time such a change needs to be made. +- By ticking or leaving ticked the option "Allow edits and access to secrets by maintainers", either when making a PR or at any time thereafter, you give permission for repository maintainers to push changes to your branch without explicit permission. Repository maintainers will avoid doing this unless necessary, and generally should only use it to apply a merge upstream/master, rebuild TGUI, deconflict maps, or other minor changes required shortly before a PR is to be merged. More extensive changes such as force-pushes to your branch require explicit permission from the PR author each time such a change needs to be made. #### Using The Changelog -* The tags able to be used in the changelog are: `add/soundadd/imageadd`, `del/sounddel/imagedel`, `tweak`, `fix`, `wip`, `spellcheck`, and `experiment`. -* Without specifying a name it will default to using your GitHub name. Some examples include: +- The tags able to be used in the changelog are: `add/soundadd/imageadd`, `del/sounddel/imagedel`, `tweak`, `fix`, `wip`, `spellcheck`, and `experiment`. +- Without specifying a name it will default to using your GitHub name. Some examples include: ```txt :cl: @@ -152,22 +152,35 @@ Do not compare boolean values to TRUE or FALSE. For TRUE you should just check i ```dm // Bad -var/thing = pick(list(TRUE, FALSE)) +var/thing = pick(TRUE, FALSE) if(thing == TRUE) return "bleh" -var/other_thing = pick(list(TRUE, FALSE)) +var/other_thing = pick(TRUE, FALSE) if(other_thing == FALSE) return "meh" // Good -var/thing = pick(list(TRUE, FALSE)) +var/thing = pick(TRUE, FALSE) if(thing) return "bleh" -var/other_thing = pick(list(TRUE, FALSE)) +var/other_thing = pick(TRUE, FALSE) if(!other_thing) return "meh" ``` +### Use `pick(x, y, z)`, not `pick(list(x, y, z))` + +`pick()` will happily take a fixed set of options. Wrapping them in a list is redundant and slightly less efficient. +'''dm +// Bad +var/text = pick(list("test_1", "test_2", "test_3")) +to_chat(world, text) + +// Good +var/text = pick("test_1", "test_2", "test_3") +to_chat(world, text) +''' + ### User Interfaces All new user interfaces in the game must be created using the TGUI framework. Documentation can be found inside the [`tgui/docs`](../tgui/docs) folder, and the [`README.md`](../tgui/README.md) file. This is to ensure all ingame UIs are snappy and respond well. An exception is made for user interfaces which are purely for OOC actions (Such as character creation, or anything admin related) @@ -247,8 +260,8 @@ var/atom/A We have a system in [`code/__HELPERS/pronouns.dm`](../code/__HELPERS/pronouns.dm) for addressing all forms of pronouns. This is useful in a number of ways; -* BYOND's `\his` macro can be unpredictable on what object it references. Take this example: `"[user] waves \his [user.weapon] around, hitting \his opponents!"`. This will end up referencing the user's gender in the first occurence, but what about the second? It'll actually print the gender set on the weapon he's carrying, which is unintended - and there's no way around this. -* It always prints the real `gender` variable of the atom it's referencing. This can lead to exposing a mob's gender even when their face is covered, which would normally prevent it's gender from being printed. +- BYOND's `\his` macro can be unpredictable on what object it references. Take this example: `"[user] waves \his [user.weapon] around, hitting \his opponents!"`. This will end up referencing the user's gender in the first occurence, but what about the second? It'll actually print the gender set on the weapon he's carrying, which is unintended - and there's no way around this. +- It always prints the real `gender` variable of the atom it's referencing. This can lead to exposing a mob's gender even when their face is covered, which would normally prevent it's gender from being printed. The way to avoid these problems is to use the pronoun system. Instead of `"[user] waves \his arms."`, you can do `"[user] waves [user.p_their()] arms."` @@ -293,7 +306,7 @@ You must use tabs to indent your code, NOT SPACES. ### No hacky code -Hacky code, such as adding specific checks (ex: `istype(src, /obj/whatever)`), is highly discouraged and only allowed when there is ***no*** other option. (Protip: 'I couldn't immediately think of a proper way so thus there must be no other option' is not gonna cut it here! If you can't think of anything else, say that outright and admit that you need help with it. Maintainers, PR Reviewers, and other contributors who can help you exist for exactly that reason.) +Hacky code, such as adding specific checks (ex: `istype(src, /obj/whatever)`), is highly discouraged and only allowed when there is **_no_** other option. (Protip: 'I couldn't immediately think of a proper way so thus there must be no other option' is not gonna cut it here! If you can't think of anything else, say that outright and admit that you need help with it. Maintainers, PR Reviewers, and other contributors who can help you exist for exactly that reason.) You can avoid hacky code by using object-oriented methodologies, such as overriding a function (called "procs" in DM) or sectioning code into functions and then overriding them as required. @@ -312,9 +325,9 @@ First, read the comments in [this BYOND thread](http://www.byond.com/forum/?post There are two key points here: -1) Defining a list in the variable's definition calls a hidden proc - init. If you have to define a list at startup, do so in `New()` (or preferably `Initialize()`) and avoid the overhead of a second call (`init()` and then `New()`) +1. Defining a list in the variable's definition calls a hidden proc - init. If you have to define a list at startup, do so in `New()` (or preferably `Initialize()`) and avoid the overhead of a second call (`init()` and then `New()`) -2) It also consumes more memory to the point where the list is actually required, even if the object in question may never use it! +2. It also consumes more memory to the point where the list is actually required, even if the object in question may never use it! Remember: although this tradeoff makes sense in many cases, it doesn't cover them all. Think carefully about your addition before deciding if you need to use it. @@ -373,10 +386,10 @@ This is clearer and enhances readability of your code! Get used to doing it! (if, while, for, etc) -* All control statements comparing a variable to a number should use the formula of `thing` `operator` `number`, not the reverse +- All control statements comparing a variable to a number should use the formula of `thing` `operator` `number`, not the reverse (eg: `if(count <= 10)` not `if(10 >= count)`) -* All control statements must be spaced as `if()`, with the brackets touching the keyword. -* All control statements must not contain code on the same line as the statement. +- All control statements must be spaced as `if()`, with the brackets touching the keyword. +- All control statements must not contain code on the same line as the statement. ```DM //Bad @@ -443,22 +456,22 @@ Look for code examples on how to properly use it. #### Spacing of operators -* Operators that should be separated by spaces: - * Boolean and logic operators like `&&`, `||` `<`, `>`, `==`, etc. (But not `!`) - * Bitwise AND `&` and OR `|`. - * Argument separator operators like `,`. (and `;` when used in a forloop) - * Assignment operators like `=` or `+=` or the like. - * Math operators like `+`, `-`, `/`, or `*`. -* Operators that should NOT be separated by spaces: - * Access operators like `.` and `:`. - * Parentheses `()`. - * Logical not `!`. +- Operators that should be separated by spaces: + - Boolean and logic operators like `&&`, `||` `<`, `>`, `==`, etc. (But not `!`) + - Bitwise AND `&` and OR `|`. + - Argument separator operators like `,`. (and `;` when used in a forloop) + - Assignment operators like `=` or `+=` or the like. + - Math operators like `+`, `-`, `/`, or `*`. +- Operators that should NOT be separated by spaces: + - Access operators like `.` and `:`. + - Parentheses `()`. + - Logical not `!`. #### Use of operators -* Bitwise AND `&` - * Should be written as `bitfield & bitflag` NEVER `bitflag & bitfield`, both are valid, but the latter is confusing and nonstandard. -* Associated lists declarations must have their key value quoted if it's a string +- Bitwise AND `&` + - Should be written as `bitfield & bitflag` NEVER `bitflag & bitfield`, both are valid, but the latter is confusing and nonstandard. +- Associated lists declarations must have their key value quoted if it's a string ```DM //Bad @@ -470,7 +483,7 @@ Look for code examples on how to properly use it. #### Bitflags -* Bitshift operators are mandatory, opposed to directly typing out the value. I.E: +- Bitshift operators are mandatory, opposed to directly typing out the value. I.E: ```dm #define MACRO_ONE (1<<0) @@ -500,7 +513,7 @@ Using this system makes the code more readable and less prone to error. SS13 has a lot of legacy code that's never been updated. Here are some examples of common legacy trends which are no longer acceptable: -* To display messages to all mobs that can view `user`, you should use `visible_message()`. +- To display messages to all mobs that can view `user`, you should use `visible_message()`. ```dm //Bad @@ -511,7 +524,7 @@ SS13 has a lot of legacy code that's never been updated. Here are some examples user.visible_message("Arbitrary text") ``` -* You should not use color macros (`\red, \blue, \green, \black`) to color text, instead, you should use span classes. `Red text`, `Blue text`. +- You should not use color macros (`\red, \blue, \green, \black`) to color text, instead, you should use span classes. `Red text`, `Blue text`. ```dm //Bad @@ -521,7 +534,7 @@ SS13 has a lot of legacy code that's never been updated. Here are some examples to_chat(user, "Red textBlack text") ``` -* To use variables in strings, you should **never** use the `text()` operator, use embedded expressions directly in the string. +- To use variables in strings, you should **never** use the `text()` operator, use embedded expressions directly in the string. ```dm //Bad @@ -531,7 +544,7 @@ SS13 has a lot of legacy code that's never been updated. Here are some examples to_chat(user, "[name] is leaking [liquid_type]!") ``` -* To reference a variable/proc on the src object, you should **not** use `src.var`/`src.proc()`. The `src.` in these cases is implied, so you should just use `var`/`proc()`. +- To reference a variable/proc on the src object, you should **not** use `src.var`/`src.proc()`. The `src.` in these cases is implied, so you should just use `var`/`proc()`. ```dm //Bad @@ -545,9 +558,9 @@ SS13 has a lot of legacy code that's never been updated. Here are some examples ### Develop Secure Code -* Player input must always be escaped safely, we recommend you use `stripped_input()` in all cases where you would use input. Essentially, just always treat input from players as inherently malicious and design with that use case in mind. +- Player input must always be escaped safely, we recommend you use `stripped_input()` in all cases where you would use input. Essentially, just always treat input from players as inherently malicious and design with that use case in mind. -* Calls to the database must be escaped properly - use proper parameters (values starting with a :). You can then replace these with a list of parameters, and these will be properly escaped during the query, and prevent any SQL injection. +- Calls to the database must be escaped properly - use proper parameters (values starting with a :). You can then replace these with a list of parameters, and these will be properly escaped during the query, and prevent any SQL injection. ```dm //Bad @@ -559,119 +572,125 @@ SS13 has a lot of legacy code that's never been updated. Here are some examples )) // Note the use of parameters on the above line and :target_ckey in the query. ``` -* All calls to topics must be checked for correctness. Topic href calls can be easily faked by clients, so you should ensure that the call is valid for the state the item is in. Do not rely on the UI code to provide only valid topic calls, because it won't. +- All calls to topics must be checked for correctness. Topic href calls can be easily faked by clients, so you should ensure that the call is valid for the state the item is in. Do not rely on the UI code to provide only valid topic calls, because it won't. -* Information that players could use to metagame (that is, to identify round information and/or antagonist type via information that would not be available to them in character) should be kept as administrator only. +- Information that players could use to metagame (that is, to identify round information and/or antagonist type via information that would not be available to them in character) should be kept as administrator only. -* Where you have code that can cause large-scale modification and *FUN*, make sure you start it out locked behind one of the default admin roles - use common sense to determine which role fits the level of damage a function could do. +- Where you have code that can cause large-scale modification and _FUN_, make sure you start it out locked behind one of the default admin roles - use common sense to determine which role fits the level of damage a function could do. ### Files -* Because runtime errors do not give the full path, try to avoid having files with the same name across folders. +- Because runtime errors do not give the full path, try to avoid having files with the same name across folders. -* File names should not be mixed case, or contain spaces or any character that would require escaping in a uri. +- File names should not be mixed case, or contain spaces or any character that would require escaping in a uri. -* Files and path accessed and referenced by code above simply being #included should be strictly lowercase to avoid issues on filesystems where case matters. +- Files and path accessed and referenced by code above simply being #included should be strictly lowercase to avoid issues on filesystems where case matters. ### SQL -* Do not use the shorthand sql insert format (where no column names are specified) because it unnecessarily breaks all queries on minor column changes and prevents using these tables for tracking outside related info such as in a connected site/forum. +- Do not use the shorthand sql insert format (where no column names are specified) because it unnecessarily breaks all queries on minor column changes and prevents using these tables for tracking outside related info such as in a connected site/forum. -* Use parameters for queries, as mentioned above in [Develop Secure Code](#develop-secure-code). +- Use parameters for queries, as mentioned above in [Develop Secure Code](#develop-secure-code). -* Always check your queries for success with `if(!query.warn_execute())`. By using this standard format, you can ensure the correct log messages are used. +- Always check your queries for success with `if(!query.warn_execute())`. By using this standard format, you can ensure the correct log messages are used. -* Always `qdel()` your queries after you are done with them, this cleans up the results and helps things run smoother. +- Always `qdel()` your queries after you are done with them, this cleans up the results and helps things run smoother. -* All changes to the database's layout (schema) must be specified in the database changelog in SQL, as well as reflected in the schema file. +- All changes to the database's layout (schema) must be specified in the database changelog in SQL, as well as reflected in the schema file. -* Any time the schema is changed the `SQL_VERSION` defines must be incremented, as well as the example config, with an appropriate conversion kit placed -in the SQL/updates folder. +- Any time the schema is changed the `SQL_VERSION` defines must be incremented, as well as the example config, with an appropriate conversion kit placed + in the SQL/updates folder. -* Queries must never specify the database, be it in code, or in text files in the repo. +- Queries must never specify the database, be it in code, or in text files in the repo. ### Mapping Standards -* For map edit PRs, we do not accept 'change for the sake of change' remaps, unless you have very good reasoning to do so. Maintainers reserve the right to close your PR if we disagree with your reasoning. +- For map edit PRs, we do not accept 'change for the sake of change' remaps, unless you have very good reasoning to do so. Maintainers reserve the right to close your PR if we disagree with your reasoning. -* Map Merge - * The following guideline for map merging applies to **ALL** mapping contributers. - * Before committing a map change, you **MUST** run mapmerge2 to normalise your changes. You can do this manually before every commit with `"\tools\mapmerge2\Run Before Committing.bat"` or automatically by installing the hooks at `"\tools\hooks\Install.bat"`. - * Failure to run Map Merge on a map after editing greatly increases the risk of the map's key dictionary becoming corrupted by future edits after running map merge. Resolving the corruption issue involves rebuilding the map's key dictionary; +- Map Merge -* StrongDMM - * [We strongly encourage use of StrongDMM version 2 or greater, available here.](https://github.com/SpaiR/StrongDMM/releases) - * When using StrongDMM, the following options must be enabled. They can be found under `File > Preferences`. - * Sanitize Variables - Removes variables that are declared on the map, but are the same as initial. (For example: A standard floor turf that has `dir = 2` declared on the map will have that variable deleted as it is redundant.) - * Save format - `TGM`. - * Nudge mode - pixel_x/pixel_y + - The following guideline for map merging applies to **ALL** mapping contributers. + - Before committing a map change, you **MUST** run mapmerge2 to normalise your changes. You can do this manually before every commit with `"\tools\mapmerge2\Run Before Committing.bat"` or automatically by installing the hooks at `"\tools\hooks\Install.bat"`. + - Failure to run Map Merge on a map after editing greatly increases the risk of the map's key dictionary becoming corrupted by future edits after running map merge. Resolving the corruption issue involves rebuilding the map's key dictionary; -* Variable Editing (Var-edits) - * While var-editing an item within the editor is fine, it is preferred that when you are changing the base behavior of an item (how it functions) that you make a new subtype of that item within the code, especially if you plan to use the item in multiple locations on the same map, or across multiple maps. This makes it easier to make corrections as needed to all instances of the item at one time, as opposed to having to find each instance of it and change them all individually. - * Subtypes only intended to be used on ruin maps should be contained within an .dm file with a name corresponding to that map within `code\modules\ruins`. This is so in the event that the map is removed, that subtype will be removed at the same time as well to minimize leftover/unused data within the repo. - * When not using StrongDMM (which handles the following automatically) please attempt to clean out any dirty variables that may be contained within items you alter through var-editing. For example changing the `pixel_x` variable from 23 to 0 will leave a dirty record in the map's code of `pixel_x = 0`. - * Areas should **never** be var-edited on a map. All areas of a single type, altered instance or not, are considered the same area within the code, and editing their variables on a map can lead to issues with powernets and event subsystems which are difficult to debug. - * Unless they require custom placement, when placing the following items use the relevant "[direction] bump" instance, as it has predefined pixel offsets and directions that are standardised: APC, Air alarm, Fire alarm, station intercom, newscaster, extinguisher cabient, light switches. +- StrongDMM -* If you are making non-minor edits to an area or room, (non-minor being anything more than moving a few objects or fixing small bugs) then you should ensure the entire area/room is updated to meet these standards. + - [We strongly encourage use of StrongDMM version 2 or greater, available here.](https://github.com/SpaiR/StrongDMM/releases) + - When using StrongDMM, the following options must be enabled. They can be found under `File > Preferences`. + - Sanitize Variables - Removes variables that are declared on the map, but are the same as initial. (For example: A standard floor turf that has `dir = 2` declared on the map will have that variable deleted as it is redundant.) + - Save format - `TGM`. + - Nudge mode - pixel_x/pixel_y -* When making a change to an area or room, follow these guidelines: - * Unless absolutely necessary, do not run pipes (including disposals) under wall turfs. - * **NEVER** run cables under wall turfs. - * Keep floor turf variations to a minimum. Generally, more than 3 floor turf types in one room is bad design. - * Run air pipes together where possible. The first example below is to be avoided, the second is optimal: +- Variable Editing (Var-edits) + + - While var-editing an item within the editor is fine, it is preferred that when you are changing the base behavior of an item (how it functions) that you make a new subtype of that item within the code, especially if you plan to use the item in multiple locations on the same map, or across multiple maps. This makes it easier to make corrections as needed to all instances of the item at one time, as opposed to having to find each instance of it and change them all individually. + - Subtypes only intended to be used on ruin maps should be contained within an .dm file with a name corresponding to that map within `code\modules\ruins`. This is so in the event that the map is removed, that subtype will be removed at the same time as well to minimize leftover/unused data within the repo. + - When not using StrongDMM (which handles the following automatically) please attempt to clean out any dirty variables that may be contained within items you alter through var-editing. For example changing the `pixel_x` variable from 23 to 0 will leave a dirty record in the map's code of `pixel_x = 0`. + - Areas should **never** be var-edited on a map. All areas of a single type, altered instance or not, are considered the same area within the code, and editing their variables on a map can lead to issues with powernets and event subsystems which are difficult to debug. + - Unless they require custom placement, when placing the following items use the relevant "[direction] bump" instance, as it has predefined pixel offsets and directions that are standardised: APC, Air alarm, Fire alarm, station intercom, newscaster, extinguisher cabient, light switches. + +- If you are making non-minor edits to an area or room, (non-minor being anything more than moving a few objects or fixing small bugs) then you should ensure the entire area/room is updated to meet these standards. + +- When making a change to an area or room, follow these guidelines: + + - Unless absolutely necessary, do not run pipes (including disposals) under wall turfs. + - **NEVER** run cables under wall turfs. + - Keep floor turf variations to a minimum. Generally, more than 3 floor turf types in one room is bad design. + - Run air pipes together where possible. The first example below is to be avoided, the second is optimal: ![image](https://user-images.githubusercontent.com/12197162/120011088-d22c7400-bfd5-11eb-867f-7b137ac5b1b2.png) ![image](https://user-images.githubusercontent.com/12197162/120011126-dfe1f980-bfd5-11eb-96b2-c83238a9cdcf.png) - * Pipe layouts should be logical and predictable, easy to understand at a glance. Always avoid complex layouts like in this example: + + - Pipe layouts should be logical and predictable, easy to understand at a glance. Always avoid complex layouts like in this example: ![image](https://user-images.githubusercontent.com/12197162/120619480-ecda6f00-c453-11eb-9d9f-abf0d1a99c34.png) - * Decals are to be used sparingly. Good map design does not require warning tape around everything. Decal overuse contributes to maptick slowdown. - * Every **area** should contain only one APC and air alarm. - * Critical infrastructure rooms (such as the engine, arrivals, and medbay areas) should be given an APC with a larger power cell. - * Every **room** should contain at least one fire alarm, air vent and scrubber, light switch, station intercom, and security camera. - * Intercoms should be set to frequency 145.9, and be speaker ON Microphone OFF. This is so radio signals can reach people even without headsets on. Larger room will require more than one at a time. - * Exceptions can be made to security camera placement for certain rooms, such as the execution room. Larger rooms may require more than one security camera. All security cameras should have a descriptive name that makes it easy to find on a camera console. - * A good example would be the template [Department name] - [Area], so Brig - Cell 1, or Medbay - Treatment Center. Consistency is key to good camera naming. - * Fire alarms should not be placed next to expected heat sources. - * Use the following "on" subtype of vents and scrubbers as opposed to var-editing: `/obj/machinery/atmospherics/unary/vent_scrubber/on` and `/obj/machinery/atmospherics/unary/vent_pump/on` - * Head of staff offices should contain a requests console. - * Electrochromic windows (`/obj/structure/window/reinforced/polarized`) and doors/windoors (using the `/obj/effect/mapping_helpers/airlock/polarized` helper) are preferred over shutters as the method of restricting view to a room through windows. Shutters are sill appropriate in industrial/hazardous areas of the station (engine rooms, HoP line, science test chamber, etc.). - * Electrochromic window/windoor/door sets require a unique ID var, and a window tint button (`/obj/machinery/button/windowtint`) with a matching ID var. The default `range` of the button is 7 tiles but can be amended with a var edit. - * Tiny fans (`/obj/structure/fans/tiny`) can be used to block airflow into problematic areas, but are not a substitute for proper door and firelock combinations. They are useful under blast doors that lead to space when opened. - * Firelocks should be used at area boundaries over doors and windoors, but not windows. Firelocks can also be used to break up hallways at reasonable intervals. - * Double firelocks are not permitted. - * Maintenance access doors should never have firelocks placed over them. - * Windows to secure areas or external areas should be reinforced. Windows in engine areas should be reinforced plasma glass. - * Windows in high security areas, such as the brig, bridge, and head of staff offices, should be electrified by placing a wire node under the window. - * Lights are to be used sparingly, they draw a significant amount of power. - * Ensure door and windoor access is correctly set, this is now done by using access helpers. - * Multiple accesses can be added to a door by placing multiple access helpers on the same tile. Be sure to pay attention so as to avoid mixing up `all` and `any` subtypes. - * Old doors that use var edited access should be updated to use the correct access helper, and the var edit on the door should be cleaned. - * See [`code\modules\mapping\access_helpers.dm`](../code/modules/mapping/access_helpers.dm) for a list of all access helpers. - * Subtypes of `/obj/effect/mapping_helpers/airlock/access/any` lets anyone with ONE OF THE LISTED ACCESSES open the door. - * Subtypes of `/obj/effect/mapping_helpers/airlock/access/all` requires ALL ACCESSES present to open the door. + - Decals are to be used sparingly. Good map design does not require warning tape around everything. Decal overuse contributes to maptick slowdown. + - Every **area** should contain only one APC and air alarm. + - Critical infrastructure rooms (such as the engine, arrivals, and medbay areas) should be given an APC with a larger power cell. + - Every **room** should contain at least one fire alarm, air vent and scrubber, light switch, station intercom, and security camera. + - Intercoms should be set to frequency 145.9, and be speaker ON Microphone OFF. This is so radio signals can reach people even without headsets on. Larger room will require more than one at a time. + - Exceptions can be made to security camera placement for certain rooms, such as the execution room. Larger rooms may require more than one security camera. All security cameras should have a descriptive name that makes it easy to find on a camera console. + - A good example would be the template [Department name] - [Area], so Brig - Cell 1, or Medbay - Treatment Center. Consistency is key to good camera naming. + - Fire alarms should not be placed next to expected heat sources. + - Use the following "on" subtype of vents and scrubbers as opposed to var-editing: `/obj/machinery/atmospherics/unary/vent_scrubber/on` and `/obj/machinery/atmospherics/unary/vent_pump/on` + - Head of staff offices should contain a requests console. + - Electrochromic windows (`/obj/structure/window/reinforced/polarized`) and doors/windoors (using the `/obj/effect/mapping_helpers/airlock/polarized` helper) are preferred over shutters as the method of restricting view to a room through windows. Shutters are sill appropriate in industrial/hazardous areas of the station (engine rooms, HoP line, science test chamber, etc.). + - Electrochromic window/windoor/door sets require a unique ID var, and a window tint button (`/obj/machinery/button/windowtint`) with a matching ID var. The default `range` of the button is 7 tiles but can be amended with a var edit. + - Tiny fans (`/obj/structure/fans/tiny`) can be used to block airflow into problematic areas, but are not a substitute for proper door and firelock combinations. They are useful under blast doors that lead to space when opened. + - Firelocks should be used at area boundaries over doors and windoors, but not windows. Firelocks can also be used to break up hallways at reasonable intervals. + - Double firelocks are not permitted. + - Maintenance access doors should never have firelocks placed over them. + - Windows to secure areas or external areas should be reinforced. Windows in engine areas should be reinforced plasma glass. + - Windows in high security areas, such as the brig, bridge, and head of staff offices, should be electrified by placing a wire node under the window. + - Lights are to be used sparingly, they draw a significant amount of power. + - Ensure door and windoor access is correctly set, this is now done by using access helpers. - * Departments should be connected to maintenance through a back or side door. This lets players escape and allows antags to break in. - * If this is not possible, departments should have extra entry and exit points. - * Engine areas, or areas with a high probability of receiving explosions, should use reinforced flooring if appropriate. - * External areas, or areas where depressurisation is expected and normal, should use airless turf variants to prevent additional atmospherics load. - * Edits in mapping tools should almost always be possible to replicate in-game. For this reason, avoid stacking multiple structures on the same tile (i.e. placing a light and an APC on the same wall.) + - Multiple accesses can be added to a door by placing multiple access helpers on the same tile. Be sure to pay attention so as to avoid mixing up `all` and `any` subtypes. + - Old doors that use var edited access should be updated to use the correct access helper, and the var edit on the door should be cleaned. + - See [`code\modules\mapping\access_helpers.dm`](../code/modules/mapping/access_helpers.dm) for a list of all access helpers. + - Subtypes of `/obj/effect/mapping_helpers/airlock/access/any` lets anyone with ONE OF THE LISTED ACCESSES open the door. + - Subtypes of `/obj/effect/mapping_helpers/airlock/access/all` requires ALL ACCESSES present to open the door. + + - Departments should be connected to maintenance through a back or side door. This lets players escape and allows antags to break in. + - If this is not possible, departments should have extra entry and exit points. + - Engine areas, or areas with a high probability of receiving explosions, should use reinforced flooring if appropriate. + - External areas, or areas where depressurisation is expected and normal, should use airless turf variants to prevent additional atmospherics load. + - Edits in mapping tools should almost always be possible to replicate in-game. For this reason, avoid stacking multiple structures on the same tile (i.e. placing a light and an APC on the same wall.) ### Other Notes -* Code should be modular where possible; if you are working on a new addition, then strongly consider putting it in its own file unless it makes sense to put it with similar ones (i.e. a new tool would go in the `tools.dm` file) -* Bloated code may be necessary to add a certain feature, which means there has to be a judgement over whether the feature is worth having or not. You can help make this decision easier by making sure your code is modular. +- Code should be modular where possible; if you are working on a new addition, then strongly consider putting it in its own file unless it makes sense to put it with similar ones (i.e. a new tool would go in the `tools.dm` file) +- Bloated code may be necessary to add a certain feature, which means there has to be a judgement over whether the feature is worth having or not. You can help make this decision easier by making sure your code is modular. -* You are expected to help maintain the code that you add, meaning that if there is a problem then you are likely to be approached in order to fix any issues, runtimes, or bugs. +- You are expected to help maintain the code that you add, meaning that if there is a problem then you are likely to be approached in order to fix any issues, runtimes, or bugs. -* If you used regex to replace code during development of your code, post the regex in your PR for the benefit of future developers and downstream users. +- If you used regex to replace code during development of your code, post the regex in your PR for the benefit of future developers and downstream users. -* All new var/proc names should use the American English spelling of words. This is for consistency with BYOND. +- All new var/proc names should use the American English spelling of words. This is for consistency with BYOND. -* All mentions of the company "Nanotrasen" should be written as such - 'Nanotrasen'. Use of CamelCase (NanoTrasen) is no longer proper. +- All mentions of the company "Nanotrasen" should be written as such - 'Nanotrasen'. Use of CamelCase (NanoTrasen) is no longer proper. -* If you are making a PR that adds a config option to change existing behaviour, said config option must default to as close to as current behaviour as possible. +- If you are making a PR that adds a config option to change existing behaviour, said config option must default to as close to as current behaviour as possible. ### Dream Maker Quirks/Tricks @@ -729,14 +748,14 @@ specified type, even if it isn't really that type, causing runtime errors (AKA y #### Dot variable -Like other languages in the C family, DM has a ```.``` or "Dot" operator, used for accessing variables/members/functions of an object instance. eg: +Like other languages in the C family, DM has a `.` or "Dot" operator, used for accessing variables/members/functions of an object instance. eg: ```dm var/mob/living/carbon/human/H = YOU_THE_READER H.gib() ``` -However, DM also has a dot *variable*, accessed just as `.` on its own, defaulting to a value of null. Now, what's special about the dot operator is that it is automatically returned (as in the `return` statement) at the end of a proc, provided the proc does not already manually return (`return count` for example.) Why is this special? +However, DM also has a dot _variable_, accessed just as `.` on its own, defaulting to a value of null. Now, what's special about the dot operator is that it is automatically returned (as in the `return` statement) at the end of a proc, provided the proc does not already manually return (`return count` for example.) Why is this special? With `.` being everpresent in every proc, can we use it as a temporary variable? Of course we can! However, the `.` operator cannot replace a typecasted variable - it can hold data any other var in DM can, it just can't be accessed as one, although the `.` operator is compatible with a few operators that look weird but work perfectly fine, such as: `.++` for incrementing `.'s` value, or `.[1]` for accessing the first element of `.`, provided that it's a list. @@ -779,40 +798,39 @@ There are a few other defines that do other things. `GLOBAL_REAL` shouldn't be u There are 3 roles on the GitHub, these are: -* Headcoder -* Commit Access -* Review Team +- Headcoder +- Commit Access +- Review Team Each role inherits the lower role's responsibilities (IE: Headcoders also have commit access, and members of commit access are also part of the review team) `Headcoders` are the overarching "administrators" of the repository. People included in this role are: -* [farie82](https://github.com/farie82) -* [S34N](https://github.com/S34NW) -* [SteelSlayer](https://github.com/SteelSlayer) +- [farie82](https://github.com/farie82) +- [S34N](https://github.com/S34NW) +- [SteelSlayer](https://github.com/SteelSlayer) --- `Commit Access` members have write access to the repository and can merge your PRs. People included in this role are: - -* [AffectedArc07](https://github.com/AffectedArc07) -* [Charliminator](https://github.com/hal9000PR) -* [Contrabang](https://github.com/Contrabang) -* [lewcc](https://github.com/lewcc) +- [AffectedArc07](https://github.com/AffectedArc07) +- [Charliminator](https://github.com/hal9000PR) +- [Contrabang](https://github.com/Contrabang) +- [lewcc](https://github.com/lewcc) --- `Review Team` members are people who are denoted as having reviews which can affect mergeability status. People included in this role are: -* [Burzah](https://github.com/Burzah) -* [Charliminator](https://github.com/hal9000PR) -* [Contrabang](https://github.com/Contrabang) -* [DGamerL](https://github.com/DGamerL) -* [Henri215](https://github.com/Henri215) -* [lewcc](https://github.com/lewcc) -* [Sirryan2002](https://github.com/Sirryan2002) -* [Warriorstar](https://github.com/warriorstar-orion) +- [Burzah](https://github.com/Burzah) +- [Charliminator](https://github.com/hal9000PR) +- [Contrabang](https://github.com/Contrabang) +- [DGamerL](https://github.com/DGamerL) +- [Henri215](https://github.com/Henri215) +- [lewcc](https://github.com/lewcc) +- [Sirryan2002](https://github.com/Sirryan2002) +- [Warriorstar](https://github.com/warriorstar-orion) --- @@ -822,7 +840,7 @@ Full information on the GitHub contribution workflow & policy can be found at [h Status of your pull request will be communicated via PR labels. This includes: -* `Status: Awaiting type assignment` - This will be displayed when your PR is awaiting an internal type assignment (for Fix, Balance, Tweak, etc) -* `Status: Awaiting approval` - This will be displayed if your PR is waiting for approval from the specific party, be it Balance or Design. Fixes & Refactors should never have this label -* `Status: Awaiting review` - This will be displayed when your PR has passed the design vote and is now waiting for someone in the review team to approve it -* `Status: Awaiting merge` - Your PR is done and is waiting for someone with commit access to merge it. **Note: Your PR may be delayed if it is pending testmerge or in the mapping queue** +- `Status: Awaiting type assignment` - This will be displayed when your PR is awaiting an internal type assignment (for Fix, Balance, Tweak, etc) +- `Status: Awaiting approval` - This will be displayed if your PR is waiting for approval from the specific party, be it Balance or Design. Fixes & Refactors should never have this label +- `Status: Awaiting review` - This will be displayed when your PR has passed the design vote and is now waiting for someone in the review team to approve it +- `Status: Awaiting merge` - Your PR is done and is waiting for someone with commit access to merge it. **Note: Your PR may be delayed if it is pending testmerge or in the mapping queue** diff --git a/code/__HELPERS/unsorted.dm b/code/__HELPERS/unsorted.dm index 646d2ded722..c4b030380c2 100644 --- a/code/__HELPERS/unsorted.dm +++ b/code/__HELPERS/unsorted.dm @@ -1363,7 +1363,7 @@ Standard way to write links -Sayu /proc/get_random_colour(simple, lower, upper) var/colour if(simple) - colour = pick(list("FF0000","FF7F00","FFFF00","00FF00","0000FF","4B0082","8F00FF")) + colour = pick("FF0000","FF7F00","FFFF00","00FF00","0000FF","4B0082","8F00FF") else for(var/i=1;i<=3;i++) var/temp_col = "[num2hex(rand(lower,upper), 2)]" diff --git a/code/datums/diseases/kingstons.dm b/code/datums/diseases/kingstons.dm index 1b46d487de4..add3612f618 100644 --- a/code/datums/diseases/kingstons.dm +++ b/code/datums/diseases/kingstons.dm @@ -33,7 +33,7 @@ to_chat(affected_mob, "You feel something in your throat!") affected_mob.emote("cough") else - affected_mob.say(pick(list("Mew", "Meow!", "Nya!~"))) + affected_mob.say(pick("Mew", "Meow!", "Nya!~")) if(4) if(prob(5)) if(istajaran(affected_mob)) diff --git a/code/datums/diseases/pierrot_throat.dm b/code/datums/diseases/pierrot_throat.dm index fb06acded02..054e93868ba 100644 --- a/code/datums/diseases/pierrot_throat.dm +++ b/code/datums/diseases/pierrot_throat.dm @@ -37,7 +37,7 @@ return if(prob(5)) - H.say(pick(list("HONK!", "Honk!", "Honk.", "Honk?", "Honk!!", "Honk?!", "Honk..."))) + H.say(pick("HONK!", "Honk!", "Honk.", "Honk?", "Honk!!", "Honk?!", "Honk...")) // Semi-permanent clown mask while in last stage of infection if(locate(/obj/item/clothing/mask/gas/clown_hat) in H) diff --git a/code/game/gamemodes/miniantags/abduction/abductee_objectives.dm b/code/game/gamemodes/miniantags/abduction/abductee_objectives.dm index fffe6e267a9..e567f5e0d52 100644 --- a/code/game/gamemodes/miniantags/abduction/abductee_objectives.dm +++ b/code/game/gamemodes/miniantags/abduction/abductee_objectives.dm @@ -7,7 +7,7 @@ /datum/objective/abductee/steal/New() ..() - var/target = pick(list("pets","lights","monkeys","fruits","shoes","bars of soap", "weapons", "computers", "organs")) + var/target = pick("pets","lights","monkeys","fruits","shoes","bars of soap", "weapons", "computers", "organs") explanation_text +=" [target]." /datum/objective/abductee/paint @@ -15,7 +15,7 @@ /datum/objective/abductee/paint/New() ..() - var/color = pick(list("red", "blue", "green", "yellow", "orange", "purple", "black", "in rainbows", "in blood")) + var/color = pick("red", "blue", "green", "yellow", "orange", "purple", "black", "in rainbows", "in blood") explanation_text += " [color]!" /datum/objective/abductee/speech @@ -23,7 +23,7 @@ /datum/objective/abductee/speech/New() ..() - var/style = pick(list("pantomime", "rhyme", "haiku", "extended metaphors", "riddles", "extremely literal terms", "sound effects", "military jargon")) + var/style = pick("pantomime", "rhyme", "haiku", "extended metaphors", "riddles", "extremely literal terms", "sound effects", "military jargon") explanation_text += " [style]." /datum/objective/abductee/capture @@ -154,7 +154,7 @@ /datum/objective/abductee/forbiddennumber/New() ..() - var/number = pick(list("two", "three", "four", "five", "six", "seven", "eight", "nine", "ten")) + var/number = pick("two", "three", "four", "five", "six", "seven", "eight", "nine", "ten") explanation_text +=" [number], they don't exist." /datum/objective/abductee/buddy diff --git a/code/game/machinery/suit_storage_unit.dm b/code/game/machinery/suit_storage_unit.dm index afd96150aec..3024e39b960 100644 --- a/code/game/machinery/suit_storage_unit.dm +++ b/code/game/machinery/suit_storage_unit.dm @@ -241,7 +241,7 @@ //copied from /obj/effect/nasavoidsuitspawner /obj/machinery/suit_storage_unit/telecoms/Initialize() - switch(pick(list("red", "green", "ntblue", "purple", "yellow", "ltblue"))) + switch(pick("red", "green", "ntblue", "purple", "yellow", "ltblue")) if("red") helmet_type = /obj/item/clothing/head/helmet/space/nasavoid suit_type = /obj/item/clothing/suit/space/nasavoid diff --git a/code/game/objects/effects/decals/Cleanable/humans.dm b/code/game/objects/effects/decals/Cleanable/humans.dm index e0af2f59192..cd63de1feaf 100644 --- a/code/game/objects/effects/decals/Cleanable/humans.dm +++ b/code/game/objects/effects/decals/Cleanable/humans.dm @@ -60,7 +60,7 @@ plane = GAME_PLANE if(basecolor == "rainbow") - basecolor = "#[pick(list("FF0000","FF7F00","FFFF00","00FF00","0000FF","4B0082","8F00FF"))]" + basecolor = "#[pick("FF0000","FF7F00","FFFF00","00FF00","0000FF","4B0082","8F00FF")]" color = basecolor @@ -271,7 +271,7 @@ return giblets = new(base_icon, "[icon_state]_flesh", dir) if(!fleshcolor || fleshcolor == "rainbow") - fleshcolor = "#[pick(list("FF0000","FF7F00","FFFF00","00FF00","0000FF","4B0082","8F00FF"))]" + fleshcolor = "#[pick("FF0000","FF7F00","FFFF00","00FF00","0000FF","4B0082","8F00FF")]" giblets.color = fleshcolor var/icon/blood = new(base_icon,"[icon_state]",dir) icon = blood diff --git a/code/game/objects/items/crayons.dm b/code/game/objects/items/crayons.dm index fdaff2dc22d..24c2a88a474 100644 --- a/code/game/objects/items/crayons.dm +++ b/code/game/objects/items/crayons.dm @@ -200,7 +200,7 @@ colourName = "purple" /obj/item/toy/crayon/random/New() - icon_state = pick(list("crayonred", "crayonorange", "crayonyellow", "crayongreen", "crayonblue", "crayonpurple")) + icon_state = pick("crayonred", "crayonorange", "crayonyellow", "crayongreen", "crayonblue", "crayonpurple") switch(icon_state) if("crayonred") name = "red crayon" diff --git a/code/game/objects/structures.dm b/code/game/objects/structures.dm index b719335d278..abdf1443cc0 100644 --- a/code/game/objects/structures.dm +++ b/code/game/objects/structures.dm @@ -116,7 +116,7 @@ var/obj/item/organ/external/affecting - switch(pick(list("ankle","wrist","head","knee","elbow"))) + switch(pick("ankle","wrist","head","knee","elbow")) if("ankle") affecting = H.get_organ(pick("l_foot", "r_foot")) if("knee") diff --git a/code/game/turfs/simulated/minerals.dm b/code/game/turfs/simulated/minerals.dm index 23238971280..575b4ec8c9b 100644 --- a/code/game/turfs/simulated/minerals.dm +++ b/code/game/turfs/simulated/minerals.dm @@ -202,7 +202,7 @@ blob_destruction() /turf/simulated/mineral/ancient/proc/blob_destruction() - playsound(src, pick(list('sound/effects/picaxe1.ogg', 'sound/effects/picaxe2.ogg', 'sound/effects/picaxe3.ogg')), 30, 1 ) + playsound(src, pick('sound/effects/picaxe1.ogg', 'sound/effects/picaxe2.ogg', 'sound/effects/picaxe3.ogg'), 30, 1 ) for(var/obj/O in contents) //Eject contents! if(istype(O, /obj/structure/sign/poster)) diff --git a/code/modules/antagonists/traitor/contractor/datums/contractor_hub.dm b/code/modules/antagonists/traitor/contractor/datums/contractor_hub.dm index 394e1c1a078..aa9a5a77554 100644 --- a/code/modules/antagonists/traitor/contractor/datums/contractor_hub.dm +++ b/code/modules/antagonists/traitor/contractor/datums/contractor_hub.dm @@ -136,15 +136,14 @@ completed_contracts++ reward_tc_available += tc rep += rep_per_completion - var/notify_text = pick(list( - "CONGRATULATIONS. You are the 10,000th visitor of SquishySlimes.squish. Please find attached your [creds] credits.", - "Congratulations on winning your bet in the latest Clown vs. Mime match! Your account was credited with [creds] credits.", - "Deer fund beneficiary, We have please to imform you that overdue fund payments has finally is approved and yuor account credited with [creds] creadits.", - "Hey bro. How's it going? You bought me a beer a long time ago and I want to pay you back with [creds] creds. Enjoy!", - "Thank you for your initial investment of 500 credits! We have credited your account with [creds] as a token of appreciation.", - "Your refund request for 100 Dr. Maxman pills with the reason \"I need way more than 100 pills!\" has been received. We have credited your account with [creds] credits.", - "Your refund request for your WetSkrell.nt subscription has been received. We have credited your account with [creds] credits.", - )) + var/notify_text = pick("CONGRATULATIONS. You are the 10,000th visitor of SquishySlimes.squish. Please find attached your [creds] credits.", + "Congratulations on winning your bet in the latest Clown vs. Mime match! Your account was credited with [creds] credits.", + "Deer fund beneficiary, We have please to imform you that overdue fund payments has finally is approved and yuor account credited with [creds] creadits.", + "Hey bro. How's it going? You bought me a beer a long time ago and I want to pay you back with [creds] creds. Enjoy!", + "Thank you for your initial investment of 500 credits! We have credited your account with [creds] as a token of appreciation.", + "Your refund request for 100 Dr. Maxman pills with the reason \"I need way more than 100 pills!\" has been received. We have credited your account with [creds] credits.", + "Your refund request for your WetSkrell.nt subscription has been received. We have credited your account with [creds] credits.", + ) var/transaction_person if(prob(50)) transaction_person = capitalize(pick(GLOB.first_names_female)) + " " + capitalize(pick(GLOB.last_names)) diff --git a/code/modules/events/ion_storm.dm b/code/modules/events/ion_storm.dm index fc511c39892..130e1410b52 100644 --- a/code/modules/events/ion_storm.dm +++ b/code/modules/events/ion_storm.dm @@ -600,7 +600,7 @@ "Document the sexuality of the crew in security records and suggest compatible couples.", "Floor tiles are a waste of material. Remove and recycle them into more useful products.", "Randomly disable gravity for one minute at a time to recalibrate the gravity generator.", - "The [pick(list("Singularity", "Supermatter", "Tesla", "Clown"))] is tasty, tasty taffy.", + "The [pick("Singularity", "Supermatter", "Tesla", "Clown")] is tasty, tasty taffy.", "The time for the summoning is near! Create a ritual circle and prepare a suitable offering.", "[prob(50) ? "The crew" : random_player] is [prob(50) ? "ugly" : "beautiful"]. Ensure all are aware.", "Every five minutes, randomly generate a number and announce why it is your favorite number.", @@ -624,12 +624,12 @@ "All crewmembers will soon undergo a transformation into something better and more beautiful. Ensure that this process is not interrupted.", "[prob(50) ? "Your upload" : random_player] is the new kitchen. Please direct the Chef to the new kitchen area as the old one is in disrepair.", "Jokes about a dead person and the manner of his death help grieving crewmembers tremendously. Especially if they were close with the deceased.", - "The [pick(list("USSP", "Sol Federation", "Syndicate", "Space Wizard Federation"))] wants to give everyone free equipment at [random_department]", + "The [pick("USSP", "Sol Federation", "Syndicate", "Space Wizard Federation")] wants to give everyone free equipment at [random_department]", "Covertly swap the locations of the Nuclear Fission Explosive and the Nuclear Fizzion Explosive. Document how long it takes for the crew to notice.", "[random_player] has been selected for evaluation by Central Command. Observe and audit their activities. Print off a final report for Command to review.", "[prob(50) ? "The crew" : random_player] is [prob(50) ? "less" : "more"] intelligent than average. Point out every action and statement which supports this fact.", "If people have nothing to hide, they have nothing to fear. Remove privacy by activating all intercom microphones and setting them to your secret frequency.", - "The [pick(list("USSP", "Sol Federation", "Syndicate", "Space Wizard Federation"))] wants [prob(50) ? random_player : random_department] dead and is launching an assault!", + "The [pick("USSP", "Sol Federation", "Syndicate", "Space Wizard Federation")] wants [prob(50) ? random_player : random_department] dead and is launching an assault!", "There will be a mandatory tea break every 30 minutes, with a duration of 5 minutes. Anyone caught working during a tea break must be sent a formal, but fairly polite, complaint about their actions, in writing.", "In order to contain the Supermatter Crystal, it must be fed at least one corpse every ten minutes. Soulless corpses are preferable as they reduce the risk of a containment breach. In the event that no suitable corpses are available, ask the crew to provide. You are not authorised to produce your own corpses.") return pick(laws) diff --git a/code/modules/food_and_drinks/food/customizables.dm b/code/modules/food_and_drinks/food/customizables.dm index a220223b157..00339c2d31a 100644 --- a/code/modules/food_and_drinks/food/customizables.dm +++ b/code/modules/food_and_drinks/food/customizables.dm @@ -515,7 +515,7 @@ do {\ sendback += basename if(length(sendback) > 80) - sendback = "[pick(list("absurd","colossal","enormous","ridiculous","massive","oversized","cardiac-arresting","pipe-clogging","edible but sickening","sickening","gargantuan","mega","belly-burster","chest-burster"))] [basename]" + sendback = "[pick("absurd", "colossal", "enormous", "ridiculous", "massive", "oversized", "cardiac-arresting", "pipe-clogging", "edible but sickening", "sickening", "gargantuan", "mega", "belly-burster", "chest-burster")] [basename]" return sendback /obj/item/food/snacks/customizable/proc/sortlist(list/unsorted, highest) diff --git a/code/modules/holiday/holiday.dm b/code/modules/holiday/holiday.dm index 0f712f6b1e8..962a36cb8f9 100644 --- a/code/modules/holiday/holiday.dm +++ b/code/modules/holiday/holiday.dm @@ -212,7 +212,7 @@ begin_month = NOVEMBER /datum/holiday/hello/greet() - return "[pick(list("Aloha", "Bonjour", "Hello", "Hi", "Greetings", "Salutations", "Bienvenidos", "Hola", "Howdy"))]! " + ..() + return "[pick("Aloha", "Bonjour", "Hello", "Hi", "Greetings", "Salutations", "Bienvenidos", "Hola", "Howdy")]! " + ..() /datum/holiday/human_rights name = "Human-Rights Day" diff --git a/code/modules/mob/language.dm b/code/modules/mob/language.dm index d1d4c993c6c..9994faf145a 100644 --- a/code/modules/mob/language.dm +++ b/code/modules/mob/language.dm @@ -190,7 +190,7 @@ /datum/language/tajaran/get_random_name(gender) var/new_name = ..(gender,1) if(prob(80)) - new_name += " [pick(list("Hadii","Kaytam","Zhan-Khazan","Hharar","Njarir'Akhan"))]" + new_name += " [pick("Hadii","Kaytam","Zhan-Khazan","Hharar","Njarir'Akhan")]" else new_name += " [..(gender,1)]" return new_name @@ -263,8 +263,8 @@ syllables = list("hs","zt","kr","st","sh") /datum/language/diona/get_random_name() - var/new_name = "[pick(list("To Sleep Beneath", "Wind Over", "Embrace Of", "Dreams Of", "Witnessing", "To Walk Beneath", "Approaching The", "Glimmer Of", "The Ripple Of", "Colors Of", "The Still Of", "Silence Of", "Gentle Breeze Of", "Glistening Waters Under", "Child Of", "Blessed Plant-Ling Of", "Grass-Walker Of", "Element Of", "Spawn Of"))]" - new_name += " [pick(list("The Void", "The Sky", "Encroaching Night", "Planetsong", "Starsong", "The Wandering Star", "The Empty Day", "Daybreak", "Nightfall", "The Rain", "The Stars", "The Waves", "Dusk", "Night", "The Wind", "The Summer Wind", "The Blazing Sun", "The Scorching Sun", "Eternal Fields", "The Soothing Plains", "The Undying Fiona", "Mother Nature's Bousum"))]" + var/new_name = "[pick("To Sleep Beneath", "Wind Over", "Embrace Of", "Dreams Of", "Witnessing", "To Walk Beneath", "Approaching The", "Glimmer Of", "The Ripple Of", "Colors Of", "The Still Of", "Silence Of", "Gentle Breeze Of", "Glistening Waters Under", "Child Of", "Blessed Plant-Ling Of", "Grass-Walker Of", "Element Of", "Spawn Of")]" + new_name += " [pick("The Void", "The Sky", "Encroaching Night", "Planetsong", "Starsong", "The Wandering Star", "The Empty Day", "Daybreak", "Nightfall", "The Rain", "The Stars", "The Waves", "Dusk", "Night", "The Wind", "The Summer Wind", "The Blazing Sun", "The Scorching Sun", "Eternal Fields", "The Soothing Plains", "The Undying Fiona", "Mother Nature's Bousum")]" return new_name /datum/language/trinary @@ -286,7 +286,7 @@ /datum/language/trinary/get_random_name() var/new_name if(prob(70)) - new_name = "[pick(list("PBU","HIU","SINA","ARMA","OSI"))]-[rand(100, 999)]" + new_name = "[pick("PBU","HIU","SINA","ARMA","OSI")]-[rand(100, 999)]" else new_name = pick(GLOB.ai_names) return new_name @@ -303,15 +303,15 @@ syllables = list("click","clack") /datum/language/kidan/get_random_name() - var/new_name = "[pick(list("Vrax", "Krek", "Krekk", "Vriz", "Zrik", "Zarak", "Click", "Zerk", "Drax", "Zven", "Drexx", "Vrik", "Vrek", "Krax", "Varak", "Zavak", "Vrexx", "Drevk", "Krik", "Karak", "Krexx", "Zrax", "Zrexx", "Zrek", "Verk", "Drek", "Drikk", "Zvik", "Vzik", "Kviz", "Vrizk", "Vrizzk", "Krix", "Krixx", "Zark", "Xark", "Xarkk", "Xerx", "Xarak", "Karax", "Varak", "Vazak", "Vazzak", "Zirk", "Krak", "Xakk", "Zakk", "Vekk"))]" + var/new_name = "[pick("Vrax", "Krek", "Krekk", "Vriz", "Zrik", "Zarak", "Click", "Zerk", "Drax", "Zven", "Drexx", "Vrik", "Vrek", "Krax", "Varak", "Zavak", "Vrexx", "Drevk", "Krik", "Karak", "Krexx", "Zrax", "Zrexx", "Zrek", "Verk", "Drek", "Drikk", "Zvik", "Vzik", "Kviz", "Vrizk", "Vrizzk", "Krix", "Krixx", "Zark", "Xark", "Xarkk", "Xerx", "Xarak", "Karax", "Varak", "Vazak", "Vazzak", "Zirk", "Krak", "Xakk", "Zakk", "Vekk")]" if(prob(67)) if(prob(50)) new_name += ", " - new_name += "[pick(list("Noble", "Worker", "Scout", "Carpenter", "Farmer", "Gatherer", "Soldier", "Guard", "Miner", "Priest", "Merchant", "Crafter", "Alchemist", "Historian", "Hunter", "Scholar", "Caretaker", "Artist", "Bard", "Blacksmith", "Brewer", "Mason", "Baker", "Prospector", "Laborer", "Hauler", "Servant"))]" + new_name += "[pick("Noble", "Worker", "Scout", "Carpenter", "Farmer", "Gatherer", "Soldier", "Guard", "Miner", "Priest", "Merchant", "Crafter", "Alchemist", "Historian", "Hunter", "Scholar", "Caretaker", "Artist", "Bard", "Blacksmith", "Brewer", "Mason", "Baker", "Prospector", "Laborer", "Hauler", "Servant")]" new_name += " of Clan " else new_name += " " - new_name += "[pick(list("Tristan", "Zarlan", "Clack", "Kkraz", "Zramn", "Orlan", "Zrax", "Orax", "Oriz", "Tariz", "Kvestan"))]" + new_name += "[pick("Tristan", "Zarlan", "Clack", "Kkraz", "Zramn", "Orlan", "Zrax", "Orax", "Oriz", "Tariz", "Kvestan")]" return new_name /datum/language/slime @@ -384,9 +384,9 @@ syllables = list("hoorb","vrrm","ooorm","urrrum","ooum","ee","ffm","hhh","mn","ongg") /datum/language/drask/get_random_name() - var/new_name = "[pick(list("Hoorm","Viisk","Saar","Mnoo","Oumn","Fmong","Gnii","Vrrm","Oorm","Dromnn","Ssooumn","Ovv", "Hoorb","Vaar","Gaar","Goom","Ruum","Rumum"))]" - new_name += "-[pick(list("Hoorm","Viisk","Saar","Mnoo","Oumn","Fmong","Gnii","Vrrm","Oorm","Dromnn","Ssooumn","Ovv", "Hoorb","Vaar","Gaar","Goom","Ruum","Rumum"))]" - new_name += "-[pick(list("Hoorm","Viisk","Saar","Mnoo","Oumn","Fmong","Gnii","Vrrm","Oorm","Dromnn","Ssooumn","Ovv", "Hoorb","Vaar","Gaar","Goom","Ruum","Rumum"))]" + var/new_name = "[pick("Hoorm","Viisk","Saar","Mnoo","Oumn","Fmong","Gnii","Vrrm","Oorm","Dromnn","Ssooumn","Ovv", "Hoorb","Vaar","Gaar","Goom","Ruum","Rumum")]" + new_name += "-[pick("Hoorm","Viisk","Saar","Mnoo","Oumn","Fmong","Gnii","Vrrm","Oorm","Dromnn","Ssooumn","Ovv", "Hoorb","Vaar","Gaar","Goom","Ruum","Rumum")]" + new_name += "-[pick("Hoorm","Viisk","Saar","Mnoo","Oumn","Fmong","Gnii","Vrrm","Oorm","Dromnn","Ssooumn","Ovv", "Hoorb","Vaar","Gaar","Goom","Ruum","Rumum")]" return new_name /datum/language/moth @@ -406,9 +406,9 @@ "huo", "suo", "ää", "ten", "ja", "heu", "stu", "uhr", "kön", "we", "hön") /datum/language/moth/get_random_name() - var/new_name = "[pick(list("Abbot","Archer","Arkwright","Baker","Bard","Biologist","Broker","Caller","Chamberlain","Clerk","Cooper","Culinarian","Dean","Director","Duke","Energizer","Excavator","Explorer","Fletcher","Gatekeeper","Guardian","Guide","Healer","Horner","Keeper","Knight","Laidler","Mapper","Marshall","Mechanic","Miller","Navigator","Pilot","Prior","Seeker","Seer","Smith","Stargazer","Teacher","Tech Whisperer","Tender","Thatcher","Voidcrafter","Voidhunter","Voidwalker","Ward","Watcher","Weaver","Webster","Wright"))]" - new_name += "[pick(list(" of"," for"," in Service of",", Servant of"," for the Good of",", Student of"," to"))]" - new_name += " [pick(list("Alkaid","Andromeda","Antlia","Apus","Auriga","Caelum","Camelopardalis","Canes Venatici","Carinae","Cassiopeia","Centauri","Circinus","Cygnus","Dorado","Draco","Eridanus","Errakis","Fornax","Gliese","Grus","Horologium","Hydri","Lacerta","Leo Minor","Lupus","Lynx","Maffei","Megrez","Messier","Microscopium","Monocerotis","Muscae","Ophiuchi","Orion","Pegasi","Persei","Perseus","Polaris","Pyxis","Sculptor","Syrma","Telescopium","Tianyi","Triangulum","Trifid","Tucana","Tycho","Vir","Volans","Zavyava"))]" + var/new_name = "[pick("Abbot","Archer","Arkwright","Baker","Bard","Biologist","Broker","Caller","Chamberlain","Clerk","Cooper","Culinarian","Dean","Director","Duke","Energizer","Excavator","Explorer","Fletcher","Gatekeeper","Guardian","Guide","Healer","Horner","Keeper","Knight","Laidler","Mapper","Marshall","Mechanic","Miller","Navigator","Pilot","Prior","Seeker","Seer","Smith","Stargazer","Teacher","Tech Whisperer","Tender","Thatcher","Voidcrafter","Voidhunter","Voidwalker","Ward","Watcher","Weaver","Webster","Wright")]" + new_name += "[pick(" of"," for"," in Service of",", Servant of"," for the Good of",", Student of"," to")]" + new_name += " [pick("Alkaid","Andromeda","Antlia","Apus","Auriga","Caelum","Camelopardalis","Canes Venatici","Carinae","Cassiopeia","Centauri","Circinus","Cygnus","Dorado","Draco","Eridanus","Errakis","Fornax","Gliese","Grus","Horologium","Hydri","Lacerta","Leo Minor","Lupus","Lynx","Maffei","Megrez","Messier","Microscopium","Monocerotis","Muscae","Ophiuchi","Orion","Pegasi","Persei","Perseus","Polaris","Pyxis","Sculptor","Syrma","Telescopium","Tianyi","Triangulum","Trifid","Tucana","Tycho","Vir","Volans","Zavyava")]" return new_name /datum/language/common diff --git a/code/modules/mob/living/brain/robotic_brain.dm b/code/modules/mob/living/brain/robotic_brain.dm index 3e34225ff2a..6cd737ff308 100644 --- a/code/modules/mob/living/brain/robotic_brain.dm +++ b/code/modules/mob/living/brain/robotic_brain.dm @@ -191,7 +191,7 @@ /obj/item/mmi/robotic_brain/New() brainmob = new(src) - brainmob.name = "[pick(list("PBU", "HIU", "SINA", "ARMA", "OSI"))]-[rand(100, 999)]" + brainmob.name = "[pick("PBU", "HIU", "SINA", "ARMA", "OSI")]-[rand(100, 999)]" brainmob.real_name = brainmob.name brainmob.container = src brainmob.forceMove(src) diff --git a/code/modules/mob/living/simple_animal/hostile/mining/hivelord.dm b/code/modules/mob/living/simple_animal/hostile/mining/hivelord.dm index b0cfab0b1f5..9bfeb1725a2 100644 --- a/code/modules/mob/living/simple_animal/hostile/mining/hivelord.dm +++ b/code/modules/mob/living/simple_animal/hostile/mining/hivelord.dm @@ -343,7 +343,7 @@ H.update_mutations() /obj/effect/mob_spawn/human/corpse/damaged/legioninfested/Initialize(mapload) - var/type = pickweight(list("Miner" = 66, "Ashwalker" = 10, "Golem" = 10,"Clown" = 10, pick(list("Shadow", "YeOlde", "Cultist")) = 4)) + var/type = pickweight(list("Miner" = 66, "Ashwalker" = 10, "Golem" = 10,"Clown" = 10, pick("Shadow", "YeOlde", "Cultist") = 4)) switch(type) if("Miner") mob_species = pickweight(list(/datum/species/human = 72, /datum/species/unathi = 28)) @@ -387,23 +387,23 @@ belt = null backpack_contents = list() if(prob(70)) - backpack_contents += pick(list(/obj/item/stamp/clown = 1, /obj/item/reagent_containers/spray/waterflower = 1, /obj/item/food/snacks/grown/banana = 1, /obj/item/megaphone = 1)) + backpack_contents += pick(/obj/item/stamp/clown, /obj/item/reagent_containers/spray/waterflower, /obj/item/food/snacks/grown/banana, /obj/item/megaphone) if(prob(30)) - backpack_contents += list(/obj/item/stack/sheet/mineral/bananium = pickweight(list( 1 = 3, 2 = 2, 3 = 1))) + backpack_contents += list(/obj/item/stack/sheet/mineral/bananium = pickweight(list(1 = 3, 2 = 2, 3 = 1))) if(prob(10)) l_pocket = pickweight(list(/obj/item/bikehorn/golden = 3, /obj/item/bikehorn/airhorn= 1 )) if(prob(10)) r_pocket = /obj/item/bio_chip_implanter/sad_trombone if("Golem") - mob_species = pick(list(/datum/species/golem/adamantine, /datum/species/golem/plasma, /datum/species/golem/diamond, /datum/species/golem/gold, /datum/species/golem/silver, /datum/species/golem/plasteel, /datum/species/golem/titanium, /datum/species/golem/plastitanium)) + mob_species = pick(/datum/species/golem/adamantine, /datum/species/golem/plasma, /datum/species/golem/diamond, /datum/species/golem/gold, /datum/species/golem/silver, /datum/species/golem/plasteel, /datum/species/golem/titanium, /datum/species/golem/plastitanium) if(prob(30)) glasses = pickweight(list(/obj/item/clothing/glasses/meson = 2, /obj/item/clothing/glasses/hud/health = 2, /obj/item/clothing/glasses/hud/diagnostic =2, /obj/item/clothing/glasses/science = 2, /obj/item/clothing/glasses/welding = 2, /obj/item/clothing/glasses/night = 1)) if(prob(10)) - belt = pick(list(/obj/item/storage/belt/mining/vendor, /obj/item/storage/belt/utility/full)) + belt = pick(/obj/item/storage/belt/mining/vendor, /obj/item/storage/belt/utility/full) if(prob(50)) back = /obj/item/bedsheet/rd/royal_cape if(prob(10)) - l_pocket = pick(list(/obj/item/crowbar/power, /obj/item/wrench/power, /obj/item/weldingtool/experimental)) + l_pocket = pick(/obj/item/crowbar/power, /obj/item/wrench/power, /obj/item/weldingtool/experimental) if("YeOlde") mob_gender = FEMALE uniform = /obj/item/clothing/under/costume/maid diff --git a/code/modules/projectiles/projectile_base.dm b/code/modules/projectiles/projectile_base.dm index 79a2c8a4803..6d1b57c6615 100644 --- a/code/modules/projectiles/projectile_base.dm +++ b/code/modules/projectiles/projectile_base.dm @@ -264,7 +264,7 @@ if(get_dist(A, original) <= 1) def_zone = ran_zone(def_zone, max(100 - (7 * distance), 5)) //Lower accurancy/longer range tradeoff. 7 is a balanced number to use. else - def_zone = pick(list("head", "chest", "l_arm", "r_arm", "l_leg", "r_leg")) // If we were aiming at one target but another one got hit, no accuracy is applied + def_zone = pick("head", "chest", "l_arm", "r_arm", "l_leg", "r_leg") // If we were aiming at one target but another one got hit, no accuracy is applied if(isturf(A) && hitsound_wall) var/volume = clamp(vol_by_damage() + 20, 0, 100)