# Skyrat Jump into Mapping June
Taking after our upstream, TG held a Marching into Mapness back during March. There was an incentive to create ruins, shuttles, which would result in a reward should your map(s) be merged.

Skyrat does lack a significant quantity of mappers as is, and those who do map are already either contributors themselves or maintainers. The goal of Jump into Mapping June is to extend a hand to the playerbase and get more involved. Mapping is one of the easier things (subjective) to get into when it comes to contributing to Space Station 13.

Offering a reward isn't the incentive here, nor should it be the focal point of getting new contributors involved in mapping. The goal is to try and teach new mappers, as well as educating current mappers on things.

Below will be the categories listed of things that'll be addressed.

## Getting Started - StrongDMM and YOU
You're going to need tools for coding and mapping, obviously. Here are some resources.
GitHub Desktop is one of the Git intergrations you can use, and is the easiests to understand. VSC has them as well, although, its much more simplistic.
Whatever you use it up to personal preference.

VSC (Visual Studio Code) - https://code.visualstudio.com/download
GitHub Desktop - https://desktop.github.com
StrongDMM - https://github.com/SpaiR/StrongDMM

Byond comes with its own built-in mapping tools. For all intensive purposes, please **do not** use it. If you are hard press to map in it, then you'll need to use specific tools to make sure it fits the saving format that is now commonly used. Byond saves maps as asci art, whereas today they're saved in "keys", this can be viewed by looking at a maps source code.

## GitHub Basics - VSC and GitHub Desktop

### Before Creating a Pull Request
Before doing so, you must make sure your GitHub enviornment is set up. This can be automated through GitHub Desktop, if you choose to download and replicate a repository. VSC can do this as well, although, requires some input from you.
Once thats done, you should be set on pushing commits.

PLEASE KEEP IN MIND: When you do decide to make a PR, espeically a MAP PR, ensure that your MASTER BRANCH is 1:1 with upstream/master to mitigate initial map merge conflicts. This means, make sure you are pulling upstream/master into your fork/master branch. DO NOT MAKE A PR ON YOUR FORK TO DO THIS, THIS'LL JUST CREATE ISSUES FOR YOU LATER.

Secondly, MAKE SURE YOU ARE NOT PRING FROM YOUR MASTER BRANCH. This will create a headache for you and be a pain in the ass to resolve. MAKE A BRANCH, DO NOT PR FROM YOUR FORK/MASTER.

### GitHub Desktop Pull Request Sequence

### VSC Pull Request Sequence

1. Firstly, you're going to want to select your "master" branch name (this is now commonly called "main" on newer repositories)

2. This is where you can either select a previous branch, or create a new one

3. Once you have a branch created, you can start making changes. By creating a branch, you're essentially creating a "new" enviornment to test stuff in.

4. Once you make changes, they'll appear in the source panel, where GitHub intergrations are handled.

5. If you're satisified with your changes, click the "+" icon to stage your changes. This prepares them to be committed. If you're unsatisified with the changes, you can just click the "-" to unstage them.

NOTE: While changes are staged, they can still be overrided with new changes, You do not need to unstage changes every time if you're unstatisified with them.

6. Once you're ready to commit, enter a message and click the commit button. Try to keep your commit messages helpful, as it not only helps you keep track of whats going on, but it also helps other contributors and maintainers.

7. Oh no I committed something I didn't want to commit! You can undo the last commit by selecting the "..." option at the very right of the "Source Control" panel, above the commit message box. To undo a commit, navigate to the commit option, then to "Undo Last Commit".

8. If you're satisfied, navigate the same "..." and select "Pull, Push" or "Push to". This'll either push to your fork, or you can select where to push.

9. Once pushed, check the repository you're trying to open a PR on. If you do not see the attached image, try pushing again.

10. From there, its as simple as filling out the PR body. Follow the repositories templates and make sure to defend your changes should they potentially be against maintainers wishes.

NOTE: When writing your PR body, if you're looking to *fix* issues, include "Fixes: #PR" in your body. This'll link your PR to the issue, and if its merged, close the issue. For example, if you put "This Fixes: #3333", issue #3333 will be linked, and if merged, will be closed.
You can also use Closes: #PR if you believe your PR is a better alternative to another PR thats currently open.

## UpdatePaths and Map Merge Conflict Resolution

Update Paths is a very strong tool for mappers and coders alike. What Update Paths does is simple. If a coder changes `/obj/item/banana` to `/obj/item/fruit/banana`, this'll render the obj typepths in the maps invalid, as the original obj no longer exists.
The way we do this is by adding a .txt file to /tools/UpdatePaths/scripts (NOTE: If you're writing scripts for, say, Skyrat, you want to put them in the `Skyrat_scripts` folder!). It would look something like this,

# Makes banans a fruit subtype - Commet to help explain what the script does

/obj/item/banana : /obj/item/fruit/banana - The syntax that convertts X -> Y

Please keep in mind this is a VERY BASIC way to do this. Theres a lot more involved when writing Update Paths.
There is a indepth guide to understanding this tool on [/tg/Stations](https://github.com/tgstation/tgstation/tree/master/tools/UpdatePaths) repository. It'll be briefly covered here for the essentials.

### Important UpdatePath syntaxs

*Please make sure to see /tg/s guide on UpdatePaths for more syntaxs!*

`/obj/structure/door/airlock/science/closed/rd : /obj/structure/door/airlock/science/rd/closed{@OLD}` This'll keep any var edits on an obj, like custom names. If you wish to nuke var edits (preferably don't) do not include `{@OLD}`.

`/obj/foo/ball : @DELETE` - As it implies, deletes the obj

`/turf/open/floor/iron/i_like_spawning_mobs : /obj/mob_spawner, /turf/open/floor/iron` - This will take X and replace it with BOTH Y and Z

`/obj/item/window/@SUBTYPES : /obj/strucutre/window/@SUBTYPES{@OLD}` - @SUBTYPES here will update anything following the typepath, so `/obj/item/window/cafe` would be changed to `/obj/strucutre/window/cafe`

## Area Definition - Why You shouldn't Use the Same Area Twice

Area's are a fickle thing to get right. Sometime's you don't know if this wall belongs to area A or B. There's no real right or wrong here, just goes with what looks right and nice.

For example,
The area definition here is fine. Nothing really weird with chemistry.

However, the sub level,
It could use a big of changing!

With areas, we want to try and define as much of the surrounding area to the room as possible. There are going to be weird cases that you run into with "Do I give this wall to that room or this room?" again, follow "whatever looks nicer".

For example,
AI Upload's northern wall is shared with the Showroom and Central Maint rooms. If we were to dedicate that wall to AI upload..

Well, that surely doesn't look pretty at all.

Some Thigns to Keep in Mind
---
While room defining isn't exactly set in stone, there are SOME rules when planning areas out.

### Do not duplicate area defines
This may seem silly, but you do not want to use the same area define twice.
Take this Central Maint for example:

It's majorly defined here,
And here,

*Whats the issue?*
The major issue is power. Since the APC is in the first image, you could build a lot of machines in the second are and mysteriously drain the APC charge. That isn't fun for anyone.
This can also create issues when checking for bugs through CI. CI will blare the alarms about duped APCs in these areas!

### Maintenance should overlap maintenance doors
This is easily explained with images.

DO THIS,

NOT THIS,

*Whats the issue?*
The one issue is ambience that plays. You're entering maintenance!
Secondly is power. If a room depowers, the airlock becomes unoperable, so you're sorta shit out of luck.
But doesn't this apply to maintenance as well? Yes! It does. It's also consistent that maintenance areas overlap with maintenance doors. If maintenance loses power, so should its doors.

### Splitting up very large areas into smaller areas
VERY big areas can strain power nets very quickly. Big areas are usually reserved to maintenance, halls, and select areas within departments (like the prison). Luckily, there are already a handful of subtypes of these specific areas to cut things up.

Take this example (look at the pink)
This is the central hall for LimaStation. It's split up into the following: Fore, Aft, Starboard, Port and Central.

*Whats the issue?*
The issue here is mainly in powernets. If this entire area was one big glob, not only would it be a MASSIVE power sink, during events such as power outage, any doors in the main hall would be unoperable. By splitting the area up, not only do you cut down the power consumption it does, but it can potentially save the rest of the halls and/or station from issues, since each individual section can operate independently.

### Areas are color coded, for the most part
To make navigating maps easier at a glance, all the departments are color coded.

Take the full map photo of LimaStation. How many departments can you count at a glance?

NOTE: Service is the only department to not use a consistent color throughout the department. The kitchen is grey, hydro is green, and the library is blue.

Security is generally red, with the prison being orange.
Engineer is either orange or yellow.
Medical is primarily blue. Virology is green.
Science is purple.
Command is some varible of a deep blue.
AI areas are black.

Hallways, maintenance and service do not follow any coloring patterns, but consistency with them should be maintained if possible.

### Nearstation
Nearstation area defines look like this,

They're a white star.

What nearstation is best described using code.

/area/space/nearstation
	icon_state = "space_near"
	area_flags = UNIQUE_AREA | AREA_USES_STARLIGHT
	static_lighting = TRUE
	base_lighting_alpha = 0
	base_lighting_color = COLOR_WHITE

Nearstation is used for areas that may not have a "roof", in other terms, it's outside the station. This is what gives things that "fully lit" effect. It also prevents blobs from placing their cores down.

## Creating Subtypes - Why you Shouldn't Var Edit Every Goddamn Tile
You don't always need to create subtypes. Creating them for, say, every time you wanted to add a new pug to the game isn't needed. It would bloat code and just add something utterly pointless. So how do we go about doing this? We can edit the varibles (var edit). While small var edits are usually permissible and accepted, bigger, farther reaching ones (ones that would alter the functionality of the item) would require to be subtyped. You don't need to be a coder to subtype!

### Acceptable var edits
Editing airlocks, windoors, ect, are what would be considered acceptable. Doors in this case are unjustifiable to have subtypes for every each case. We'd have hundreds of airlocks with different names.

Look, its Tends-The-Gardens!

### Unacceptable var edits
Outside of changing names, descriptions and other variables that are fluid (like in nav beacons, buttons), you'll need to make a subtype. Some example cases are:
1. Adding a new armor datum to something (or changing an existing armor datum)
2. Mass changing a singular var for say lights (its easier to subtype these and use them. Small var edits like these can get lost!)
3. [Adding a heat capacity var a plate and forgetting it exists](https://github.com/tgstation/tgstation/pull/73758)

### Creating subtypes
Creating subtypes is fairly easy! Search for what you want to subtype. Lets say you want to add a new rug. Find where /turf/open/floor/carpet is defined.

If its in its own file WITH its subtypes, add the subtype to that file.
If the subtypes are NOT in the same file, search for them and see how they're done. If they're all in their own files, the best case is to just put the new subtype in the main file where the parent is defined. If more subtypes are needed, make a new file.

## ERROR Signs Galore - Why installing Counter Strike Source isn't Required

## Wires and Pipes - The Pain in the Ass and Not Pain in the Ass