cyberpresidentvanellope/Paradise
1
0
Fork 0
mirror of https://github.com/ParadiseSS13/Paradise.git synced 2026-08-22 19:47:22 +01:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #16125 from S34NW/patch-1

Browse Source 
Addition to contribution guidelines, mapping section.
This commit is contained in:
variableundefined
2021-07-25 09:06:12 -04:00
committed by GitHub
parent 7526d01c67 e6f015cb30
commit 171edcbc7f
1 changed files with 46 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/CONTRIBUTING.md
+46 -4
View File
@@ -482,9 +482,15 @@ 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.)
* 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;
* 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;
* 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 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.
* 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,9 +498,45 @@ 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 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.
* 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:
![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 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 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`](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 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.)
### 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.