More README fixes. (#25384)

* Fixes links/contributing

* Mapmerge readme updates

.github/CONTRIBUTING.md

@@ -1,16 +1,16 @@
 #CONTRIBUTING
 
-##Reporting Issues
+## Reporting Issues
 
 See [this page](http://tgstation13.org/wiki/Reporting_Issues) for a guide and format to issue reports.
 
-##Introduction
+## Introduction
 
 Hello and welcome to /tg/station's contributing page. You are here because you are curious or interested in contributing. Thanks for being interested. Everyone is free to contribute to this project as long as they follow the simple guidelines and specifications below, because at /tg/station, we have a goal to increase code maintainability and to do that we are going to need all pull requests to hold up to those specifications. This is in order for all of us to benefit, instead of having to fix the same bug more than once because of duplicated code.
 
 But first we want to make it clear how you can contribute, if contributing is a new experience for you, and what powers the team has over your pull request so you do not get any surprises when submitting pull requests, and it is closed for a reason you did not anticipate.
 
-##Getting Started
+## Getting Started
 At /tg/station we do not have a list of goals and features to add, we instead allow freedom for contributors to suggest and create their ideas for the game. That does not mean we aren't determined to squash bugs, which unfortunately pop up a lot due to the deep complexity of the game. Here are some useful getting started guides, if you want to contribute or if you want to know what challenges you can tackle with zero knowledge about the game's code structure.
 
 If you want to contribute the first thing you'll need to do is [set up Git](http://tgstation13.org/wiki/Setting_up_git) so you can download the source code.
@@ -21,7 +21,7 @@ There is an open list of approachable issues for [your inspiration here](https:/
 
 You can of course, as always, ask for help at [#coderbus](irc://irc.rizon.net/coderbus) on irc.rizon.net. We are just here to have fun and help so do not expect professional support please.
 
-##Meet the Team
+## Meet the Team
 
 **Project Leads**
 
@@ -37,14 +37,14 @@ Maintainers are quality control. If a proposed pull request does not meet the me
 
 Maintainers can revert your changes if they feel they are not worth maintaining or if they did not live up to the quality specifications.
 
-##Specification
+## Specification
 
 As mentioned before, you are expected to follow these specifications in order to make everyone's lives easier, it will also save you and us time, with having to make the changes and us having to tell you what to change. Thank you for reading this section.
 
-###Object Oriented code
+### Object Oriented code
 As BYOND's Dream Maker is an object oriented language, code must be object oriented when possible in order to be more flexible when adding content to it. If you are unfamiliar with this concept, it is highly recommended you look it up.
 
-###All Byond paths must contain the full path.
+### All Byond paths must contain the full path.
 (ie: absolute pathing)
 
 Byond will allow you nest almost any type keyword into a block, such as:
@@ -98,16 +98,16 @@ The previous code made compliant:
 	code
 ```
 
-###No overriding type safety checks.
+### No overriding type safety checks.
 The use of the : operator to override type safety checks is not allowed. You must cast the variable to the proper type.
 
-###Type paths must began with a /
+### Type paths must began with a /
 eg: `/datum/thing` not `datum/thing`
 
-###Datum type paths must began with "datum"
+### Datum type paths must began with "datum"
 In byond this is optional, but omitting it makes finding definitions harder.
 
-###Do not use text/string based type paths
+### Do not use text/string based type paths
 It is rarely allowed to put type paths in a text format, as there are no compile errors if the type path no longer exists. Here is an example:
 
 ```C++
@@ -118,22 +118,22 @@ var/path_type = /obj/item/weapon/baseball_bat
 var/path_type = "/obj/item/weapon/baseball_bat"
 ```
 
-###Tabs not spaces
+### Tabs not spaces
 You must use tabs to indent your code, NOT SPACES.
 
 (You may use spaces to align something, but you should tab to the block level first, then add the remaining spaces)
 
-###No Hacky code
+### No Hacky code
 Hacky code, such as adding specific checks, 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 )
 
 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.
 
-###No duplicated code.
+### No duplicated code.
 Copying code from one place to another maybe suitable for small short time projects but /tg/station focuses on the long term and thus discourages this.
 
 Instead you can use object orientation, or simply placing repeated code in a function, to obey this specification easily.
 
-###Startup/Runtime tradeoffs with lists and the "hidden" init proc
+### Startup/Runtime tradeoffs with lists and the "hidden" init proc
 First, read the comments in this byond thread, starting here:http://www.byond.com/forum/?post=2086980&page=2#comment19776775
 
 There are two key points here:
@@ -144,19 +144,19 @@ There are two key points here:
 
 Remember, this tradeoff makes sense in many cases but not all, you should think carefully about your implementation before deciding if this is an appropriate thing to do
 
-###Prefer `Initialize` over `New` for atoms
+### Prefer `Initialize` over `New` for atoms
 Our game controller is pretty good at handling long operations and lag. But, it can't control what happens when the map is loaded, which calls `New` for all atoms on the map. If you're creating a new atom, use the `Initialize` proc to do what you would normally do in `New`. This cuts down on the number of proc calls needed when the world is loaded. See here for details on `Initialize`: https://github.com/tgstation/tgstation/blob/master/code/game/atoms.dm#L49
 
-###No magic numbers or strings
+### No magic numbers or strings
 Make these #defines with a name that more clearly states what it's for.
 
-###Control statements:
+### Control statements:
 (if,while,for,etc)
 
 * All control statements must not contain code on the same line as the statement (`if (blah) return`)
 * 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)`)
 
-###Use early return.
+### Use early return.
 Do not enclose a proc in an if block when returning on a condition is more feasible
 This is bad:
 ````
@@ -179,7 +179,7 @@ This is good:
 ````
 This prevents nesting levels from getting deeper then they need to be.
 
-###Develop Secure Code
+### 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
 
@@ -193,14 +193,14 @@ This prevents nesting levels from getting deeper then they need to be.
 
 * 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
+### Files
 * 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.
 
 * Files and path accessed and referenced by code above simply being #included should be strictly lowercase to avoid issues on filesystems where case matters.
 
-###Other Notes
+### Other Notes
 * Code should be modular where possible, if you are working on a new class then it is best if you put it in a new 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.
@@ -209,7 +209,7 @@ This prevents nesting levels from getting deeper then they need to be.
 
 * Do not divide when you can easily convert it to a multiplication. (ie `4/2` should be done as `4*0.5`)
 
-####Enforced not enforced
+#### Enforced not enforced
 The following different coding styles are not only not enforced, but it is generally frowned upon to change them over from one to the other for little reason:
 
 * English/British spelling on var/proc names
@@ -217,7 +217,7 @@ The following different coding styles are not only not enforced, but it is gener
 * Spaces after control statements
 	* if() if () nobody cares.
 
-####Operators and spaces:
+#### Operators and spaces:
 (this is not strictly enforced, but more a guideline for readability's sake)
 
 * Operators that should be separated by spaces
@@ -232,7 +232,7 @@ The following different coding styles are not only not enforced, but it is gener
 
 Math operators like +, -, /, *, etc are up in the air, just choose which version looks more readable.
 
-###Dream Maker Quirks/Tricks:
+### Dream Maker Quirks/Tricks:
 Like all languages, Dream Maker has its quirks, some of them are beneficial to us, like these
 
 * In-To for loops: ```for(var/i = 1, i <= some_value, i++)``` is a fairly standard way to write an incremental for loop in most languages (especially those in the C family) however DM's ```for(var/i in 1 to some_value)``` syntax is oddly faster than its implementation of the former syntax; where possible it's advised to use DM's syntax. (Note, the ```to``` keyword is inclusive, so it automatically defaults to replacing ```<=```, if you want ```<``` then you should write it as ```1 to some_value-1```).
@@ -276,7 +276,7 @@ H.gib()
 however DM also has a dot variable, accessed just as ```.``` on it's 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``` statment) at the end of a proc, provided the proc does not already manually return (```return count``` for example). Why is this special? well the ```return``` statement should ideally be free from overhead (functionally free, of course nothing's free) but DM fails to fulfill this,  DM's return statement is actually fairly costly for what it does and for what it's used for.
 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, however 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 it's a list).
 
-##Pull Request Process
+## Pull Request Process
 
 There is no strict process when it comes to merging pull requests, pull requests will sometimes take a while before they are looked at by a maintainer, the bigger the change the more time it will take before they are accepted into the code. Every team member is a volunteer who is giving up their own time to help maintain and contribute, so please be nice. Here are some helpful ways to make it easier for you and for the maintainer when making a pull request.
 
@@ -297,7 +297,7 @@ Do not add any of the following in a Pull Request or risk getting the PR closed:
 * National Socialist Party of Germany content, National Socialist Party of Germany related content, or National Socialist Party of Germany references
 * Code where one line of code is split across mutiple lines (except for multiple, separate strings and comments and in those cases existing longer lines must not be split up)
 
-##A word on git
+## A word on git
 Yes we know that the files have a tonne of mixed windows and linux line endings, attempts to fix this have been met with less than stellar success and as such we have decided to give up caring until such a time as it matters.
 
 Therefore EOF settings of main repo are forbidden territory one must avoid wandering into

README.md

@@ -121,24 +121,22 @@ IRC channel/server, see the /bot folder for more
 
 ## CONTRIBUTING
 
-Please see [CONTRIBUTING.md](CONTRIBUTING.md)
+Please see [CONTRIBUTING.md](.github/CONTRIBUTING.md)
 
 ## LICENSE
 
-All code after commit 333c566b88108de218d882840e61928a9b759d8f on 2014/31/12 at 4:38 PM PST (https://github.com/tgstation/tgstation/commit/333c566b88108de218d882840e61928a9b759d8f) is licensed under GNU AGPL v3 (http://www.gnu.org/licenses/agpl-3.0.html).
+All code after [commit 333c566b88108de218d882840e61928a9b759d8f on 2014/31/12 at 4:38 PM PST](https://github.com/tgstation/tgstation/commit/333c566b88108de218d882840e61928a9b759d8f) is licensed under [GNU AGPL v3](http://www.gnu.org/licenses/agpl-3.0.html).
 
-All code before commit 333c566b88108de218d882840e61928a9b759d8f on 2014/31/12 at 4:38 PM PST (https://github.com/tgstation/tgstation/commit/333c566b88108de218d882840e61928a9b759d8f) is licensed under GNU GPL v3 (https://www.gnu.org/licenses/gpl-3.0.html).
+All code before [commit 333c566b88108de218d882840e61928a9b759d8f on 2014/31/12 at 4:38 PM PST](https://github.com/tgstation/tgstation/commit/333c566b88108de218d882840e61928a9b759d8f) is licensed under [GNU GPL v3](https://www.gnu.org/licenses/gpl-3.0.html).
 (Including tools unless their readme specifies otherwise.)
 
 See LICENSE-AGPLv3.txt and LICENSE-GPLv3.txt for more details.
 
 tgui clientside is licensed as a subproject under the MIT license.
 Font Awesome font files, used by tgui, are licensed under the SIL Open Font License v1.1
-tgui assets are licensed under a Creative Commons Attribution-ShareAlike 4.0 International License
-(http://creativecommons.org/licenses/by-sa/4.0/).
+tgui assets are licensed under a [Creative Commons Attribution-ShareAlike 4.0 International License](http://creativecommons.org/licenses/by-sa/4.0/).
 
 See tgui/LICENSE.md for the MIT license.
 See tgui/assets/fonts/SIL-OFL-1.1-LICENSE.md for the SIL Open Font License.
 
-All assets including icons and sound are under a Creative Commons 3.0 BY-SA
-license (http://creativecommons.org/licenses/by-sa/3.0/) unless otherwise indicated.
+All assets including icons and sound are under a [Creative Commons 3.0 BY-SA license](http://creativecommons.org/licenses/by-sa/3.0/) unless otherwise indicated.

tools/mapmerge/README.md

@@ -1,68 +1,63 @@
-#Map Merger#
+# Map Merger
+
 Before any change to a map, it is good to use the Map Merger tools. In a nutshell, it rewrites the map to minimize differences between different versions of the map (DreamMakers map editor rewrites a lot of the tile keys). This makes the git diff between different map changes much smaller. More recently a new way of laying out the map was invented by Remie, called TGM, this helps to further reduce conflicts in the map files.
 
 This is good for a few reasons
 
-1) Maintainers can actually verify the changes you are making are what you say they are by simply viewing the diff (For small changes at least)
-
-2) The less changes there are in any given map diff, the easier it is for git to merge it without running into unexpected conflicts, which in most cases you have to either manually resolve or require you to remap your changes
+- Maintainers can actually verify the changes you are making are what you say they are by simply viewing the diff (For small changes at least)
 
+- The less changes there are in any given map diff, the easier it is for git to merge it without running into unexpected conflicts, which in most cases you have to either manually resolve or require you to remap your changes
 
 However - to do all this is going to require you to put some elbow grease into understanding the map merger tool.
 
 If you have difficulty using these tools, ask for help in #coderbus
 
-#Using the tools#
+## Using the tools
 
-##1. Install Python 3.5 or greater##
-If you don't have Python already installed it can be downloaded from: https://www.python.org/downloads/ - make sure you grab the latest python 3, again, it must be 3.5 or greater
-##2. PATH Python##
-This step is mostly applicable to windows users, you must make sure you ask the windows installer to add python to your path, [like shown in this example screenshot](https://file.house/DA6H.png)
+1. **Install Python 3.5 or greater** - If you don't have Python already installed it can be downloaded from: https://www.python.org/downloads/ - make sure you grab the latest python 3, again, it must be 3.5 or greater 
 
-If you have already installed python you may need to manually add it to your path as indicated in [this guide](http://superuser.com/questions/143119/how-to-add-python-to-the-windows-path)
-##3. Prepare Maps##
-Run "Prepare Maps.bat" in the tools/mapmerge/ directory.
-##4. Edit your map##
-Make your changes to the map here. Remember to save them!
-##5. Clean map##
-Run "Run Map Merge - TGM.bat" in the tools/mapmerge/ directory.
-##7. Check differences##
-Use your git application of choice to look at the differences between revisions of your code and commit the result.
-##8. Commit##
-Your map is now ready to be committed, rejoice and wait for conflicts. 
+2. **PATH Python** - This step is mostly applicable to windows users, you must make sure you ask the windows installer to add python to your path. If you have already installed python you may need to manually add it to your path as indicated in this guide 
 
-#Common pitfalls#
-Open the map in dreameditor before committing the results of the mapmerger - this can cause dreameditor to resave the map back to
-dmm, if you're having issues with your map getting stuck in dmm mode, try comitting and pushing the mapmerger changes before 
-reopening in dreameditor.
+3. **Prepare Maps** - Run "Prepare Maps.bat" in the tools/mapmerge/ directory. 
+4. **Edit your map** - Make your changes to the map here. Remember to save them! 
+5. **Clean map** - Run "Run Map Merge - TGM.bat" in the tools/mapmerge/ directory. 
+6. **Check differences** - Use your git application of choice to look at the differences between revisions of your code and commit the result. 
+7. **Commit** - Your map is now ready to be committed, rejoice and wait for conflicts.
 
+## Common pitfalls
+
+Do *not* open the map in dreameditor before committing the results of the mapmerger - this can cause dreameditor to resave the map back to dmm, if you're having issues with your map getting stuck in dmm mode, try committing and pushing the mapmerger changes before reopening in dreameditor.
+
+## Map Conflict Fixer/Helper
 
-#Map Conflict Fixer/Helper#
 The map conflict fixer is a script that can help you fix map conflicts easier and faster. Here's how it works:
 
-###Before using###
-You need git for this, of course.
-Make sure your development branch is up to date before starting a map edit to ensure the script outputs a correct fix.
+### Before using
+
+You need git for this, of course. Make sure your development branch is up to date before starting a map edit to ensure the script outputs a correct fix.
+
+### Dictionary mode
 
-##Dictionary mode##
 Dictionary conflicts are the easiest to fix, you simply need to create more models to accommodate your changes and everyone elses.
 
-When you run in this mode, if the script finishes successfuly the map should be ready to be commited.
+When you run in this mode, if the script finishes successfully the map should be ready to be committed.
 
 If the script fails in dictionary mode, you can run it again in full fix mode.
 
-##Full Fix mode##
+### Full Fix mode
+
 When you and someone else edit the same coordinate, there is no easy way to fix the conflict. You need to get your hands dirty.
 
 The script will mark every tile with a marker type to help you identify what needs fixing in the map editor.
 
 After you edit and fix a marked map, you should run it through the map merger. The .backup file should be the same you used before.
 
-###Priorities###
+#### Priorities
+
 In Full Fix mode, the script needs to know which map version has higher priority, yours or someone elses. This important so tiles with multiple area and turf types aren't created.
 
-Your version has priority - In each conflicted coordinate, your floor type and your area type will be used
-Their version has priority - In each conflicted coordinate, your floor type and your area type will not be used
+Your version has priority - In each conflicted coordinate, your floor type and your area type will be used Their version has priority - In each conflicted coordinate, your floor type and your area type will not be used
 
-##IMPORTANT##
-This script is in a testing phase and you should not consider any output to be safe. Always verify the maps this script produced to make sure nothing is out of place.
+### IMPORTANT
+
+This script is in a testing phase and you should not consider any output to be safe. Always verify the maps this script produced to make sure nothing is out of place.