everything

.dockerignore

@@ -0,0 +1,27 @@
+.dockerignore
+.editorconfig
+GPLv3.txt
+LICENSE
+README.md
+TGS3.json
+.github
+.gitignore
+.gitattributes
+.git/hooks
+.git/info
+.git/modules
+.git/objects
+.git/refs
+.vs*
+cfg
+data
+SQL
+node_modules
+tgstation.dmb
+tgstation.int
+tgstation.rsc
+tgstation.lk
+tgstation.dyn.rsc
+*.dll
+Dockerfile
+tools/bootstrap/.cache

.editorconfig

@@ -0,0 +1,23 @@
+# http://editorconfig.org
+root = true
+
+[*]
+indent_style = tab
+indent_size = 4
+end_of_line = lf
+charset = utf-8
+trim_trailing_whitespace = true
+insert_final_newline = true
+
+[*.yml]
+indent_style = space
+indent_size = 2
+
+[*.py]
+indent_style = space
+
+[*.md]
+trim_trailing_whitespace = false
+
+[Dockerfile]
+indent_style = space

.git-blame-ignore-revs

@@ -0,0 +1,16 @@
+#Ignores big formatting commits when checking blame.
+#To make use of this file by default, run 'git config blame.ignoreRevsFile .git-blame-ignore-revs'
+#in the project folder
+
+## Line ending conversions
+
+# Force LF line endings with gitattributes and convert repo
+62676e72a85cd23e7a87d94adff96d17859dbdc5
+# Line ending apocalypse
+134a76cc8f5517bdc1bba5a8cbe01dc820df1c2a
+# Initial pass to convert LF to CRLF
+8af8a43d6f27e342e79d4aacb22b7668cbdc8559
+# Many changes
+931da9e7ef8c0f52a768eed7998e7e62ccdefcdc
+# Remove hideous inline tab indentation, and bans it in contributing guidelines
+0f435d5dff0a7957e8cba60a41a7fc10439064c3

.gitattributes

@@ -1,2 +1,44 @@
-# Auto detect text files and perform LF normalization
 * text=auto
+
+## Enforce text mode and LF line breaks
+*.bat text eol=lf
+*.cjs text eol=lf
+*.css text eol=lf
+*.dm text eol=lf
+*.dme text eol=lf
+*.dmf text eol=lf
+*.htm text eol=lf
+*.html text eol=lf
+*.js text eol=lf
+*.json text eol=lf
+*.jsx text eol=lf
+*.md text eol=lf
+*.ps1 text eol=lf
+*.py text eol=lf
+*.scss text eol=lf
+*.sh text eol=lf
+*.sql text eol=lf
+*.svg text eol=lf
+*.ts text eol=lf
+*.tsx text eol=lf
+*.txt text eol=lf
+*.yaml text eol=lf
+*.yml text eol=lf
+
+## Enforce binary mode
+*.bmp binary
+*.dll binary
+*.dmb binary
+*.exe binary
+*.gif binary
+*.jpg binary
+*.png binary
+*.so binary
+
+## Merger hooks, run tools/hooks/install.bat or install.sh to set up
+*.dmm text eol=lf merge=dmm
+*.dmi binary merge=dmi
+
+## Force tab indents on dm files
+*.dm whitespace=indent-with-non-tab
+

.github/CODEOWNERS

@@ -0,0 +1,5 @@
+# This list auto requests reviews from the specified org members
+# when a PR that modifies the file in question is opened
+# This list is alphabetized by User -> Filename and separated into sections for Maintainers/Contributors KEEP IT THAT WAY
+# In the event that people are to be informed of changes
+# to the same file or dir, add them to the end of under Multiple Owners

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,24 @@
+---
+name: Bug report
+about: Create a report to help reproduce and fix the issue
+---
+<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may not be viewable -->
+## Round ID:
+
+<!--- **INCLUDE THE ROUND ID**
+If you discovered this issue from playing tgstation hosted servers:
+[Round ID]: # (It can be found in the Status panel or retrieved from https://sb.atlantaned.space/rounds ! The round id let's us look up valuable information and logs for the round the bug happened.)-->
+
+<!-- If you are reporting an issue found in another branch or codebase, you MUST link the branch or codebase repo in your issue report or it will be closed. For branches, If you have not pushed your code up, you must either reproduce it on master or push your code up before making an issue report. For other codebases, if you do not have a public code repo you will be refused help unless you can completely reproduce the issue on our code. -->
+
+## Testmerges:
+
+<!-- If you're certain the issue is to be caused by a test merge [OOC tab -> Show Server Revision], report it in the pull request's comment section rather than on the tracker(If you're unsure you can refer to the issue number by prefixing said number with #. The issue number can be found beside the title after submitting it to the tracker).If no testmerges are active, feel free to remove this section. -->
+
+## Reproduction:
+
+<!-- Explain your issue in detail, including the steps to reproduce it. Issues without proper reproduction steps or explanation are open to being ignored/closed by maintainers.-->
+
+<!-- **For Admins:** Oddities induced by var-edits and other admin tools are not necessarily bugs. Verify that your issues occur under regular circumstances before reporting them. -->
+
+<!-- If you are reporting a runtime error you must include the runtime in your report or your report will be closed. -->

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,7 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+
+---
+
+Feature requests are not handled in the repository. The best place to discuss these ideas would be on the /tg/station 13 forums here: https://tgstation13.org/phpBB/viewforum.php?f=9&sid=5153c1c704a4fb1006bf7a265e45e03f

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,36 @@
+<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may not be viewable. -->
+<!-- You can view Contributing.MD for a detailed description of the pull request process. -->
+
+## About The Pull Request
+
+<!-- Describe The Pull Request. Please be sure every change is documented or this can delay review and even discourage maintainers from merging your PR! -->
+
+## Why It's Good For The Game
+
+<!-- Argue for the merits of your changes and how they benefit the game, especially if they are controversial and/or far reaching. If you can't actually explain WHY what you are doing will improve the game, then it probably isn't good for the game in the first place. -->
+
+## Changelog
+
+<!-- If your PR modifies aspects of the game that can be concretely observed by players or admins you should add a changelog. If your change does NOT meet this description, remove this section. Be sure to properly mark your PRs to prevent unnecessary GBP loss. You can read up on GBP and it's effects on PRs in the tgstation guides for contributors. Please note that maintainers freely reserve the right to remove and add tags should they deem it appropriate. You can attempt to finagle the system all you want, but it's best to shoot for clear communication right off the bat. -->
+
+:cl:
+add: Added new mechanics or gameplay changes
+add: Added more things
+del: Removed old things
+qol: made something easier to use
+balance: rebalanced something
+fix: fixed a few things
+soundadd: added a new sound thingy
+sounddel: removed an old sound thingy
+imageadd: added some icons and images
+imagedel: deleted some icons and images
+spellcheck: fixed a few typos
+code: changed some code
+refactor: refactored some code
+config: changed some config setting
+admin: messed with admin stuff
+server: something server ops should know
+/:cl:
+
+<!-- Both :cl:'s are required for the changelog to work! You can put your name to the right of the first :cl: if you want to overwrite your GitHub username as author ingame. -->
+<!-- You can use multiple of the same prefix (they're only used for the icon ingame) and delete the unneeded ones. Despite some of the tags, changelogs should generally represent how a player might be affected by the changes rather than a summary of the PR's contents. -->

.github/alternate_byond_versions.txt

@@ -0,0 +1,9 @@
+# This file contains extra tests to run for specific BYOND versions.
+# This is useful for making sure we maintain compatibility with both older and newer versions,
+# while still having our main tests run on a guaranteed pinned version.
+
+# Format is version: map
+# Example:
+# 500.1337: runtimestation
+
+515.1596: runtimestation

.github/gbp.toml

@@ -0,0 +1,24 @@
+no_balance_label = "GBP: No Update"
+reset_label = "GBP: Reset"
+
+[points]
+"Accessibility" = 3
+"Administration" = 2
+"Atomic" = 2
+"Balance" = -5
+"Code Improvement" = 2
+"Documentation" = 1
+"Feature" = -6
+"Feedback" = 2
+"Fix" = 3
+"Grammar and Formatting" = 1
+"Hard Deletes" = 12
+"Logging" = 1
+"Performance" = 12
+"Priority: CRITICAL" = 20
+"Priority: High" = 15
+"Quality of Life" = 1
+"Refactor" = 10
+"Sound" = 3
+"Sprites" = 3
+"Unit Tests" = 6

.github/guides/AUTODOC.md

@@ -0,0 +1,108 @@
+# dmdoc
+[DOCUMENTATION]: http://codedocs.tgstation13.org
+
+[BYOND]: https://secure.byond.com/
+
+[DMDOC]: https://github.com/SpaceManiac/SpacemanDMM/tree/master/crates/dmdoc
+
+[DMDOC] is a documentation generator for DreamMaker, the scripting language
+of the [BYOND] game engine. It produces simple static HTML files based on
+documented files, macros, types, procs, and vars.
+
+We use **dmdoc** to generate [DOCUMENTATION] for our code, and that documentation
+is automatically generated and built on every new commit to the master branch
+
+This gives new developers a clickable reference [DOCUMENTATION] they can browse to better help
+gain understanding of the /tg/station codebase structure and api reference.
+
+## Documenting code on /tg/station
+We use block comments to document procs and classes, and we use `///` line comments
+when documenting individual variables.
+
+It is required that all new code be covered with DMdoc code, according to the [Requirements](#Required)
+
+We also require that when you touch older code, you must document the functions that you
+have touched in the process of updating that code
+
+### Required
+A class *must* always be autodocumented, and all public functions *must* be documented
+
+All class level defined variables *must* be documented
+
+Internal functions *should* be documented, but may not be
+
+A public function is any function that a developer might reasonably call while using
+or interacting with your object. Internal functions are helper functions that your
+public functions rely on to implement logic
+
+
+### Documenting a proc
+When documenting a proc, we give a short one line description (as this is shown
+next to the proc definition in the list of all procs for a type or global
+namespace), then a longer paragraph which will be shown when the user clicks on
+the proc to jump to it's definition
+```
+/**
+ * Short description of the proc
+ *
+ * Longer detailed paragraph about the proc
+ * including any relevant detail
+ * Arguments:
+ * * arg1 - Relevance of this argument
+ * * arg2 - Relevance of this argument
+ */
+```
+
+### Documenting a class
+We first give the name of the class as a header, this can be omitted if the name is
+just going to be the typepath of the class, as dmdoc uses that by default
+
+Then we give a short oneline description of the class
+
+Finally we give a longer multi paragraph description of the class and it's details
+```
+/**
+ * # Classname (Can be omitted if it's just going to be the typepath)
+ *
+ * The short overview
+ *
+ * A longer
+ * paragraph of functionality about the class
+ * including any assumptions/special cases
+ *
+ */
+```
+
+### Documenting a variable/define
+Give a short explanation of what the variable, in the context of the class, or define is.
+```
+/// Type path of item to go in suit slot
+var/suit = null
+```
+
+## Module level description of code
+Modules are the best way to describe the structure/intent of a package of code
+where you don't want to be tied to the formal layout of the class structure.
+
+On /tg/station we do this by adding markdown files inside the `code` directory
+that will also be rendered and added to the modules tree. The structure for
+these is deliberately not defined, so you can be as freeform and as wheeling as
+you would like.
+
+[Here is a representative example of what you might write](http://codedocs.tgstation13.org/code/modules/keybindings/readme.html)
+
+## Special variables
+You can use certain special template variables in DM DOC comments and they will be expanded
+```
+    [DEFINE_NAME] - Expands to a link to the define definition if documented
+    [/mob] - Expands to a link to the docs for the /mob class
+    [/mob/proc/adjust_drunk_effect] - Expands to a link that will take you to the /mob class and anchor you to the adjust_drunk_effect proc docs
+    [/mob/var/stat] - Expands to a link that will take you to the /mob class and anchor you to the stat var docs
+```
+
+You can customise the link name by using `[link name][link shorthand].`
+
+eg. `[see more about adjust drunk effect here] [/mob/proc/adjust_drunk_effect]`
+
+This is very useful to quickly link to other parts of the autodoc code to expand
+upon a comment made, or reasoning about code

.github/guides/CI.md

@@ -0,0 +1,55 @@
+# Required Tests (Continuous Integration)
+
+> ℹ️ This is not the documentation for *writing* a test. You can find that in [the unit tests folder](../../code/modules/unit_tests/README.md).
+
+Every pull request runs through a series of checks and tests to ensure its quality.
+
+![A picture of the automatic checks](https://user-images.githubusercontent.com/35135081/192867761-0edfe4e2-399c-4dc1-824e-ca042f8bbe4b.png)
+
+If after reading this guide you still do not understand why a check suite is failing, either ask on your pull request or ask in the coding channel on the Discord.
+
+## Run Linters
+
+The [linters](https://en.wikipedia.org/wiki/Lint_(software)) check the maps and code for common mistakes. This includes things like:
+
+- Files not being included in the .dme
+- Misspelling Nanotrasen as NanoTrasen
+- Unformatted map files
+
+Sometimes linters will fail, but you won't see anything in the "Run Linters" tab. If you open up the action, it might look like this:
+
+![Run Linters fails, but Annotate Lints does not](https://user-images.githubusercontent.com/35135081/192870304-f848d576-5bcd-41bf-9514-362e2972a401.png)
+
+Specifically, notice that "Run Linters" has failed, but "Annotate Lints" has not. When this happens, click on Annotate Lints to see your problem.
+
+![A lint error inside Annotate Lints, with Run Linters failing above it](https://user-images.githubusercontent.com/35135081/192870602-96dc6bcb-c24d-4d14-9f8c-6a40c93bcdb1.png)
+
+You can also see the errors on the "Files Changed" tab of your pull request.
+
+!["relatively pathed proc here", found in the Files Changed tab](https://user-images.githubusercontent.com/35135081/192870833-d2020500-3fcb-466f-9586-395df44c4095.png)
+
+Linter failures are usually very easy to fix, and will hopefully be clear from the message alone.
+
+## Compile Maps / Windows Build
+
+These two check nothing more than that your code actually compiles, with slightly different requirements. Compile Maps forces all maps (including space ruins etc) to be compiled in, to make sure all of them are valid, and Windows Build makes sure your code actually compiles on Windows. If these tests pass, but other tests fail, it means your code *compiles* but not necessarily that it *works*.
+
+## Integration Tests
+
+The real meat and potatoes, this will not only compile the game, but also start a round, and run a bunch of premade tests. If anything runtimes (whether or not it's part of a specific test), there is a bug, and this test will fail. We run this for every station in the game to ensure maximum coverage. If all of these tests fail, your code is almost certainly bugged in some way! Read through the error, and try to resolve the issue. As always, ask maintainers if you need help.
+
+Sometimes a test will fail on only one map, and not the others. This means two things. The first is, of course, there is a bug on that specific map. This could happen if you, for instance, do a large mapping change, but mess something up only on DeltaStation. The second option is that a flaky test has failed. Not all tests consistently fail/pass, [this is something we actively try to fix](https://github.com/tgstation/tgstation/issues?q=is%3Aopen%20is%3Aissue%20project%3Atgstation%2Ftgstation%2F19). If you believe this has happened to you, you should wait for a maintainer to re-run the failed test.
+
+## Screenshot Tests
+
+Screenshot tests exist to make sure things look the same before and after your commit. This helps us detect bugs such as humans not properly rendering clothing/limbs.
+
+If your commit *does* change the appearance of something saved in a screenshot test, you will automatically receive a message on your PR showing you the before and after. From here, it will contain instructions for how to resolve the issue, whether it's a bug or intentional.
+
+## Codeowner Reviews
+
+GitHub comes with a handy feature where we can alert relevant contributors if you edit a file that they are knowledgable with. However, this feature only works with members of the organization. This is inadequate for our purposes, where we encourage contributors to keep an eye on stuff they create.
+
+Thus, we created our own system that does what GitHub does, but in a way that supports codeowners outside of the organization.
+
+This isn't a test, but if it fails, it's absolutely not your fault. Contact a maintainer.