From f8d9b0466025750c605db55d5d799117d8636cb8 Mon Sep 17 00:00:00 2001 From: S34N <12197162+S34NW@users.noreply.github.com> Date: Fri, 28 May 2021 17:37:03 +0100 Subject: [PATCH 01/13] Proposed changes to mapping guidelines --- .github/CONTRIBUTING.md | 34 +++++++++++++++++++++++++++++++++- 1 file changed, 33 insertions(+), 1 deletion(-) diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index b96dee5c47b..12e0936ca42 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -482,9 +482,14 @@ in the SQL/updates folder. ### Mapping Standards * Map Merge - * You MUST run Map Merge prior to opening your PR when updating existing maps to minimize the change differences (even when using third party mapping programs such as FastDMM.) + * You **MUST** run Map Merge prior to opening your PR when updating existing maps to minimize the change differences (even when using third party mapping programs such as FastDMM.) * Failure to run Map Merge on a map after using third party mapping programs (such as FastDMM) 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; + +* StrongDMM + * When using StrongDMM, the following options **MUST** be enabled to avoid file bloat: + * Sanitize Variables + * Clean Unused Keys * Variable Editing (Var-edits) * While var-editing an item within the editor is perfectly 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. @@ -492,6 +497,33 @@ in the SQL/updates folder. * Please attempt to clean out any dirty variables that may be contained within items you alter through var-editing. For example, due to how DM functions, changing the `pixel_x` variable from 23 to 0 will leave a dirty record in the map's code of `pixel_x = 0`. Likewise this can happen when changing an item's icon to something else and then back. This can lead to some issues where an item's icon has changed within the code, but becomes broken on the map due to it still attempting to use the old entry. * Areas should not be var-edited on a map to change it's name or attributes. All areas of a single type and it's altered instances 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. +* If you are making non-minor edits to an area or room, (non-minor being more than moving a few objects or fixing bugs) then you should ensure the entire area/room meets 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) + * 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. + * Every **room** should contain at least one fire alarm, air vent, and air scrubber. + * 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``` + * Firelocks should be used at area boundaries over doors and windows. Firelocks can also be used to break up hallways at reasonable intervals. + * Double firelocks are to be avoided unless absolutely necessary. + * Maintenance access doors should not have firelocks placed over them. + * Windows to secure areas or external areas should be reinforced. Windows in the engine areas should be reinforced plasma glass. + * 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, these are handled by the variables `req_access_txt` and `req_one_access_txt`. Public doors should have both of these values as `"0"`. For a list of access values, see `code\__DEFINES\access.dm`. + * Always use numerical values encased in quotes for these variables. Multiple access values can be defined by separating them with a `;`, for example: `"28;31"` for kitchen AND cargo access. + * req_access_txt requires ALL LISTED ACCESSES to open the door, while req_one_access_txt lets anyone with ONE OF THE LISTED ACCESSES 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. + + + ### 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) From 8f995942b3d22684ed142346780659b7ca501b5e Mon Sep 17 00:00:00 2001 From: S34N <12197162+S34NW@users.noreply.github.com> Date: Fri, 28 May 2021 17:51:58 +0100 Subject: [PATCH 02/13] additions --- .github/CONTRIBUTING.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index 12e0936ca42..6487f06cfc5 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -497,7 +497,7 @@ in the SQL/updates folder. * Please attempt to clean out any dirty variables that may be contained within items you alter through var-editing. For example, due to how DM functions, changing the `pixel_x` variable from 23 to 0 will leave a dirty record in the map's code of `pixel_x = 0`. Likewise this can happen when changing an item's icon to something else and then back. This can lead to some issues where an item's icon has changed within the code, but becomes broken on the map due to it still attempting to use the old entry. * Areas should not be var-edited on a map to change it's name or attributes. All areas of a single type and it's altered instances 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. -* If you are making non-minor edits to an area or room, (non-minor being more than moving a few objects or fixing bugs) then you should ensure the entire area/room meets these standards. +* 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 meets 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. @@ -507,9 +507,13 @@ in the SQL/updates folder. * ![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) * 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. - * Every **room** should contain at least one fire alarm, air vent, and air scrubber. + * Critical infrastructure rooms, such as the engine, should be given an APC with a larger power cell. + * Every **room** should contain at least one fire alarm, air vent, air 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. * 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 rooms should contain a requests console. * Firelocks should be used at area boundaries over doors and windows. Firelocks can also be used to break up hallways at reasonable intervals. * Double firelocks are to be avoided unless absolutely necessary. * Maintenance access doors should not have firelocks placed over them. @@ -521,6 +525,8 @@ in the SQL/updates folder. * req_access_txt requires ALL LISTED ACCESSES to open the door, while req_one_access_txt lets anyone with ONE OF THE LISTED ACCESSES 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 being exploded, should use reinforced flooring where appropriate. + * External areas, or areas where depressurisation is expected and normal, should use airless turf variants to prevent additional atmospherics load. From 48ee5418f266a3b3a05baef9e1af44576c4fabab Mon Sep 17 00:00:00 2001 From: S34N <12197162+S34NW@users.noreply.github.com> Date: Fri, 28 May 2021 18:26:36 +0100 Subject: [PATCH 03/13] add explanations to SDMM preferences. --- .github/CONTRIBUTING.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index 6487f06cfc5..ee40bef96f5 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -487,9 +487,9 @@ in the SQL/updates folder. becoming corrupted by future edits after running map merge. Resolving the corruption issue involves rebuilding the map's key dictionary; * StrongDMM - * When using StrongDMM, the following options **MUST** be enabled to avoid file bloat: - * Sanitize Variables - * Clean Unused Keys + * When using StrongDMM, the following options **MUST** be enabled to avoid file bloat. They can be found under `File > Preferences > Save Options` in SDMM. + * Sanitize Variables - Removes variables that are declared on the map, but are the same as default. (For example: A standard floor turf that has dir = 2 declared on the map will have that variable deleted as it is redundant.) + * Clean Unused Keys - Removes content tile keys that are no longer used on the map, usually leftover keys from deletions or edits. * Variable Editing (Var-edits) * While var-editing an item within the editor is perfectly 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. From 7fce80cb27be55eb2e5027dcf37965743cc39792 Mon Sep 17 00:00:00 2001 From: S34N <12197162+S34NW@users.noreply.github.com> Date: Thu, 3 Jun 2021 10:13:30 +0100 Subject: [PATCH 04/13] complex pipe layouts begone --- .github/CONTRIBUTING.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index ee40bef96f5..90063d1356d 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -504,7 +504,12 @@ in the SQL/updates folder. * 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) + + ![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: + + ![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, should be given an APC with a larger power cell. From 41f17f47295ed4cfbd71aac1ee8d06d0b6a8caea Mon Sep 17 00:00:00 2001 From: S34N <12197162+S34NW@users.noreply.github.com> Date: Thu, 3 Jun 2021 10:48:47 +0100 Subject: [PATCH 05/13] update --- .github/CONTRIBUTING.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index 90063d1356d..8817684314f 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -518,20 +518,22 @@ in the SQL/updates folder. * 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. * 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 rooms should contain a requests console. + * Head of staff officers should contain a requests console. * Firelocks should be used at area boundaries over doors and windows. Firelocks can also be used to break up hallways at reasonable intervals. * Double firelocks are to be avoided unless absolutely necessary. * Maintenance access doors should not have firelocks placed over them. - * Windows to secure areas or external areas should be reinforced. Windows in the engine areas should be reinforced plasma glass. - * High security areas, such as the brig, bridge, and head of staff offices should be electrified by placing a wire node under the window. + * 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, these are handled by the variables `req_access_txt` and `req_one_access_txt`. Public doors should have both of these values as `"0"`. For a list of access values, see `code\__DEFINES\access.dm`. * Always use numerical values encased in quotes for these variables. Multiple access values can be defined by separating them with a `;`, for example: `"28;31"` for kitchen AND cargo access. * req_access_txt requires ALL LISTED ACCESSES to open the door, while req_one_access_txt lets anyone with ONE OF THE LISTED ACCESSES 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 being exploded, should use reinforced flooring where appropriate. + * 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 generally 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.) + * From 9a192fb332390b743f55cf0d8c00474ab1c097a4 Mon Sep 17 00:00:00 2001 From: S34N <12197162+S34NW@users.noreply.github.com> Date: Thu, 3 Jun 2021 10:49:30 +0100 Subject: [PATCH 06/13] Update CONTRIBUTING.md --- .github/CONTRIBUTING.md | 1 - 1 file changed, 1 deletion(-) diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index 8817684314f..9a15ee7116a 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -533,7 +533,6 @@ in the SQL/updates folder. * 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 generally 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.) - * From ad9d1c68514b6af83c542079dd858c2fb37e7828 Mon Sep 17 00:00:00 2001 From: S34N <12197162+S34NW@users.noreply.github.com> Date: Thu, 3 Jun 2021 23:50:17 +0100 Subject: [PATCH 07/13] Apply suggestions from code review Co-authored-by: SabreML <57483089+SabreML@users.noreply.github.com> --- .github/CONTRIBUTING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index 9a15ee7116a..cffdba503aa 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -513,7 +513,7 @@ in the SQL/updates folder. * 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, should be given an APC with a larger power cell. - * Every **room** should contain at least one fire alarm, air vent, air scrubber, light switch, station intercom, and security camera. + * 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. * Fire alarms should not be placed next to expected heat sources. @@ -525,7 +525,7 @@ in the SQL/updates folder. * 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, these are handled by the variables `req_access_txt` and `req_one_access_txt`. Public doors should have both of these values as `"0"`. For a list of access values, see `code\__DEFINES\access.dm`. + * Ensure door and windoor access is correctly set, these are handled by the variables `req_access_txt` and `req_one_access_txt`. Public doors should have both of these values as `"0"`. For a list of access values, see [`code\__DEFINES\access.dm`](code/__DEFINES/access.dm). * Always use numerical values encased in quotes for these variables. Multiple access values can be defined by separating them with a `;`, for example: `"28;31"` for kitchen AND cargo access. * req_access_txt requires ALL LISTED ACCESSES to open the door, while req_one_access_txt lets anyone with ONE OF THE LISTED ACCESSES 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. From 7ff9d01c76020094f0d1cca5c97b5097b4f9a0f8 Mon Sep 17 00:00:00 2001 From: S34N <12197162+S34NW@users.noreply.github.com> Date: Mon, 28 Jun 2021 14:45:06 +0100 Subject: [PATCH 08/13] SDMM map merge info --- .github/CONTRIBUTING.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index cffdba503aa..13aaf1140f8 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -482,6 +482,7 @@ in the SQL/updates folder. ### Mapping Standards * Map Merge + * The following guideline for map merging applies to people who are **NOT** using StrongDMM, please see the StrongDMM section if you are. * You **MUST** run Map Merge prior to opening your PR when updating existing maps to minimize the change differences (even when using third party mapping programs such as FastDMM.) * Failure to run Map Merge on a map after using third party mapping programs (such as FastDMM) 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; @@ -490,6 +491,7 @@ in the SQL/updates folder. * When using StrongDMM, the following options **MUST** be enabled to avoid file bloat. They can be found under `File > Preferences > Save Options` in SDMM. * Sanitize Variables - Removes variables that are declared on the map, but are the same as default. (For example: A standard floor turf that has dir = 2 declared on the map will have that variable deleted as it is redundant.) * Clean Unused Keys - Removes content tile keys that are no longer used on the map, usually leftover keys from deletions or edits. + * Map save format: This **MUST** be set to **TGM** if you do not want to run map merger. Enabling this setting means SDMM will automatically map merge, letting you skip manual merging. * Variable Editing (Var-edits) * While var-editing an item within the editor is perfectly 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. From 6f68e253c69bb41bdce1241c0bd7e64cd5e66662 Mon Sep 17 00:00:00 2001 From: S34N <12197162+S34NW@users.noreply.github.com> Date: Tue, 20 Jul 2021 22:15:44 +0100 Subject: [PATCH 09/13] Update CONTRIBUTING.md --- .github/CONTRIBUTING.md | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index 13aaf1140f8..e0bbe59c46d 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -489,9 +489,9 @@ in the SQL/updates folder. * StrongDMM * When using StrongDMM, the following options **MUST** be enabled to avoid file bloat. They can be found under `File > Preferences > Save Options` in SDMM. - * Sanitize Variables - Removes variables that are declared on the map, but are the same as default. (For example: A standard floor turf that has dir = 2 declared on the map will have that variable deleted as it is redundant.) - * Clean Unused Keys - Removes content tile keys that are no longer used on the map, usually leftover keys from deletions or edits. * Map save format: This **MUST** be set to **TGM** if you do not want to run map merger. Enabling this setting means SDMM will automatically map merge, letting you skip manual merging. + * Sanitize Variables - Removes variables that are declared on the map, but are the same as default. (For example: A standard floor turf that has `dir = 2` declared on the map will have that variable deleted as it is redundant.) + * Clean Unused Keys - Removes content tile keys that are no longer used on the map, usually leftover keys from deletions or edits. * Variable Editing (Var-edits) * While var-editing an item within the editor is perfectly 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. @@ -519,7 +519,7 @@ in the SQL/updates folder. * 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. * 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``` + * 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 officers should contain a requests console. * Firelocks should be used at area boundaries over doors and windows. Firelocks can also be used to break up hallways at reasonable intervals. * Double firelocks are to be avoided unless absolutely necessary. @@ -535,12 +535,9 @@ in the SQL/updates folder. * 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 generally 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.) - - + * 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) ### 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. * 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. From 439085689401eaa5ad97d85c370358a0a0430491 Mon Sep 17 00:00:00 2001 From: S34N <12197162+S34NW@users.noreply.github.com> Date: Tue, 20 Jul 2021 22:15:58 +0100 Subject: [PATCH 10/13] Update .github/CONTRIBUTING.md Co-authored-by: SabreML <57483089+SabreML@users.noreply.github.com> --- .github/CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index e0bbe59c46d..5f65e2d89e7 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -489,7 +489,7 @@ in the SQL/updates folder. * StrongDMM * When using StrongDMM, the following options **MUST** be enabled to avoid file bloat. They can be found under `File > Preferences > Save Options` in SDMM. - * Map save format: This **MUST** be set to **TGM** if you do not want to run map merger. Enabling this setting means SDMM will automatically map merge, letting you skip manual merging. + * Map save format: This **MUST** be set to **TGM** if you do not want to run Map Merge. Enabling this setting means SDMM will automatically map merge, letting you skip manual merging. * Sanitize Variables - Removes variables that are declared on the map, but are the same as default. (For example: A standard floor turf that has `dir = 2` declared on the map will have that variable deleted as it is redundant.) * Clean Unused Keys - Removes content tile keys that are no longer used on the map, usually leftover keys from deletions or edits. From 3f9fabc0a11228b33a9b8cbc6402cec36e1767d1 Mon Sep 17 00:00:00 2001 From: S34N <12197162+S34NW@users.noreply.github.com> Date: Tue, 20 Jul 2021 22:18:26 +0100 Subject: [PATCH 11/13] Update CONTRIBUTING.md --- .github/CONTRIBUTING.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index 5f65e2d89e7..d2198ac0376 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -483,9 +483,8 @@ in the SQL/updates folder. ### Mapping Standards * Map Merge * The following guideline for map merging applies to people who are **NOT** using StrongDMM, please see the StrongDMM section if you are. - * You **MUST** run Map Merge prior to opening your PR when updating existing maps to minimize the change differences (even when using third party mapping programs such as FastDMM.) - * Failure to run Map Merge on a map after using third party mapping programs (such as FastDMM) 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; + * You **MUST** run Map Merge prior to opening your PR when updating existing maps to minimize the change differences (even when using third party mapping programs such as FastDMM.) + * Failure to run Map Merge on a map after using third party mapping programs (such as FastDMM) 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; * StrongDMM * When using StrongDMM, the following options **MUST** be enabled to avoid file bloat. They can be found under `File > Preferences > Save Options` in SDMM. From 7a1087a7f5d68e86516b639a24316b22f8a4caff Mon Sep 17 00:00:00 2001 From: S34N <12197162+S34NW@users.noreply.github.com> Date: Tue, 20 Jul 2021 22:43:17 +0100 Subject: [PATCH 12/13] Update CONTRIBUTING.md --- .github/CONTRIBUTING.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index d2198ac0376..95b6f049d90 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -534,9 +534,8 @@ in the SQL/updates folder. * 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 generally 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.) - * 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) - ### 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. * 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. From e6f015cb3018cefd4eeba24cf983b57d662981e6 Mon Sep 17 00:00:00 2001 From: S34N <12197162+S34NW@users.noreply.github.com> Date: Wed, 21 Jul 2021 10:50:44 +0100 Subject: [PATCH 13/13] Update CONTRIBUTING.md --- .github/CONTRIBUTING.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index 95b6f049d90..69893a3b68a 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -513,10 +513,11 @@ in the SQL/updates folder. * 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, should be given an APC with a larger power cell. + * 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 officers should contain a requests console.