[pull] master from VoRe-ss13:master

.editorconfig

@@ -1,22 +1,22 @@
+# http://editorconfig.org
 root = true
 
 [*]
-charset = utf-8
+indent_style = tab
 end_of_line = lf
-insert_final_newline = true
+charset = utf-8
 trim_trailing_whitespace = true
+insert_final_newline = true
 
-[*.{dme,dmf,dmm,dm}]
-end_of_line = crlf
-indent_style = tab
-
-[*.md]
-trim_trailing_whitespace = false
+[*.yml]
+indent_style = space
+indent_size = 2
 
 [*.py]
 indent_style = space
-indent_size = 4
 
-[*.yml]
+[*.md]
+trim_trailing_whitespace = false
+
+[Dockerfile]
 indent_style = space
-indent_size = 2

.git-blame-ignore-revs

@@ -0,0 +1,12 @@
+#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
+
+# Whitespace Standardization
+aa7cd0f69ff16ba465d97b97731966857f4c958b
+3995338290d8b69edb786c331e335d6d33838905
+
+# Removes /obj/item/weapon and /obj/item/device
+5ea698a0ef9a432f41a10d11b7016b04dab52e5b

.gitattributes

@@ -3,6 +3,7 @@
 ## Enforce text mode and LF line breaks
 *.bat text eol=lf
 *.cjs text eol=lf
+*.mjs text eol=lf
 *.css text eol=lf
 *.dm text eol=lf
 *.dme text eol=lf
@@ -42,4 +43,3 @@
 
 ## Force tab indents on dm files
 *.dm whitespace=indent-with-non-tab
-

.github/CONTRIBUTING.md

@@ -1,18 +1,20 @@
-# Contributing to CHOMPStation
+# Contributing to TORCHStation13
 
 :+1::tada: First off, thanks for taking the time to contribute! :tada::+1:
 
-The following is a set of guidelines for contributing to Chomp Station, which is hosted in the [Chomp Station](https://github.com/CHOMPStation2/CHOMPStation2) on GitHub.
+The following is a set of guidelines for contributing to TORCHStation, which is hosted in the [TORCHStation](https://github.com/VoRe-ss13/ss13) on GitHub.
 These are just guidelines, not rules, use your best judgment and feel free to propose changes to this document in a pull request.
 
 #### Table Of Contents
 
 [What should I know before I get started?](#what-should-i-know-before-i-get-started)
   * [Code of Conduct](#code-of-conduct)
+  * [Upstream Parity with Virgo](#upstream-parity-with-virgo)
 
 [How Can I Contribute?](#how-can-i-contribute)
   * [Your First Code Contribution](#your-first-code-contribution)
-  * [Chomp Station Coding Standards](#chomp-station-coding-standards)
+  * [TORCHStation Map Edits](#torchstation-map-edits)
+  * [TORCHStation Coding Standards](#torchstation-coding-standards)
   * [Pull Requests](#pull-requests)
   * [Git Commit Messages](#git-commit-messages)
 
@@ -26,62 +28,73 @@ These are just guidelines, not rules, use your best judgment and feel free to pr
 This project adheres to the Contributor Covenant [code of conduct](code_of_conduct.md).
 By participating, you are expected to uphold this code.
 
+### Upstream Parity with [Virgo](https://github.com/VOREStation/VOREStation)
+
+To work together with Virgo and make the lives of the devstaff easier for ourselves, our upstream and our downstreams, we enforce parity with upstream files.
+* What are upstream files?
+    * Upstream files are files that exist on Virgo's repo identically to here.
+* What is upstream parity?
+    * Upstream parity means to keep files that exist identically both here and upstream, identical. 
+* Why are we doing this?
+    * Cooperation between this codebase and upstream has taken significant upturns recently. There is much effort from coders both here and upstream to fix a great many issues with this shared codebase. To avoid the difficulty of trying to both fix a codebase and retain parity/maintainability, it is much preferred to fix core code on Virgo, whom is the primary upstream of this codebase (They disconnected from polaris) in a complete and clean manner and allow those fixes to trickle down to all downstreams. This helps us, it helps virgo, and it helps all the other downstreams too. 
+* I just want to code for Chomp though.
+    * This is fine, we do not want to prevent this. There will be greater emphasis on putting all chomp-only code in the /modular_chomp subdirectory from now on. For assistance on coding in a modular fashion, please ask for help in the CHOMP discord #ss13-development channel.
+* I want to edit a core mechanic / implement a feature that only works when editing upstream code.
+    * Please try your hardest to make this modular. If this isn't possible, your PR might be requested to be moved up to virgo, or denied. 
+* I just want to add sprites / sounds / add a new type of mob / add clothing / add a map
+    * This is fine! This is easily made modular and done by adding code and resources to the modular_chomp directory. 
+* What if Virgo deny a core change that was desired on Chomp?
+    * Hopefully this shouldn't happen. If you implement your feature with an "on/off" switch, then you can push it to virgo turned off, and we can turn it on here. If differences of development become too divisive in the future, then we will go back to the way things were with more freedom on this codebase. 
+
 ## How Can I Contribute?
 
 ### Your First Code Contribution
 
-Unsure where to begin contributing to Chomp Station? You can start by looking through the issues tab.
+Unsure where to begin contributing to TORCHStation? You can start by looking through the issues tab.
 
-### Chomp Station Map Edits
+### TORCHStation Map Edits
 
-* Our base map files are in [map/southern_cross/].
-* Our stationary overmap location files are in [maps/southern_cross/overmap/].
-* Our random overmap POI files are in [modular_chomp/code/modules/overmap/].
+* Our base map files are in [modular_chomp/maps/].
+* Our stationary overmap location files are in [modular_chomp/maps/southern_cross/overmap/].
+* Our random overmap POI files are in [modular_chomp/maps/overmap/].
 * Our surface POI map files (Wilderness, plains, ...) are in [modular_chomp/maps/submaps/surface_submaps/].
-* Map changes must be in tgm format. See the [Mapmerge2 Readme] for details, or use [StrongDMM] which can automatically save maps as tgm.
-
-### Chomp Station Coding Standards
-
-Any code submissions that do not meet our coding standards are likely to be rejected, or at the very least, have a maintainer request changes on your PR. Save time and follow these standards from the start:
-
-In an effort to make contributing easier to do, Black Major has started a modularity folder, https://github.com/CHOMPStation2/CHOMPStation2/tree/master/modular_chomp.
+* Map changes must be in tgm format. See the [Mapmerge2 Readme](../tools/mapmerge2/readme.md) for details, or use [StrongDMM](../tools/StrongDMM/README.md) which can automatically save maps as tgm.
+* PoIs or map templates placed during generation (Mining, plains, wilderness, space...) are generally fair game for editing or creating anew.
+* Maps that are placed permanently (Station, planetary locations) must be subject to discussion. To prevent wasted time, discuss these with the community and staff
+    * There is a limited budget of RAM available for permanent maps. This must be carefully rationed. 
+* Entire new station designs MUST be discussed with the community and the staff. Post a floor plan or basic design before committing effort in discord to prevent wasted time. 
+* For new atmospherics settings, subtypes of turfs for all turfs can be created with the [turfpacks](../modular_chomp/maps/~turfpacks/turfpacks.dm) system quickly and easily.
+
+### TORCHStation Coding Standards
+
+### General
+* **DO NOT** create joke or meme PRs. The Github is intended to be a sterile location for reviewing technical content.
+* We **DO NOT** allow any kind of CKEY/personally locked content on this codebase. Anything created must be available to all or none.
+    * Our upstream does allow this, and ckey-locked content from them does exist in our code. We try to comment it out where possible. Please report anything missing.
+    * If you have ckey locked content from our upstream and would like to make it available to all here, please contact us.
+* we **DO NOT** allow any 'naming' in our coded content. this includes shoutouts, naming a player as an owner or otherwise. All descriptions, names, lore-texts must be free of an individual's name. NPC naming is permitted.
+
+In an effort to make contributing easier to do, Black Major has started a modularity folder, https://github.com/VoRe-ss13/ss13/tree/master/modular_chomp.
 Ideally, any content that can be written that is wholelly independant of vorestation's content, should be
 included in this modularity folder, and put into the associated folder that it would have appeared in among the standard files.
 
-Ideally, the point of this is to make it slightly easier to differentiate chomp specific content from virgo content.
-
-When should you use this?
-Mostly for chomp exclusive stuff, otherwise if you need to modify a base file for any reason or if it is expected to be a part of upstream as well, write it in the base files with the following standards/policies/guidelines in the meantime:
+### Scene devices
+* A scene device or tool is considered any object or coded mechanic designed primarily to service roleplay scenes in-game. Usually, but not limited to roleplay of a private nature.
+* Scene devices **MUST** avoid giving a purely mechanical/gameplay advantage of any kind 
+* Scene devices **MUST** respect OOC consent where applicable.
+* Scene devices **MUST** react to the 'OOC Escape' command where possible. 
 
-* If it is something like a bugfix that VoreStation or Polaris would want (the codebases we use), code it in their code and make the PR to them. We regularly update from them. They would want any general gameplay bugfixes, and things that are obviously intended to work one way, but do not. They do not have any of our fluff species (vulp, akula, fenn, etc) so do not make PRs related to that, or any vore content to them.
-* Never edit stock Polaris or Vore .DMI files. If you are confused about which .DMI files we have added and which were there originally, refer to their repository and and see if they exist (https://github.com/PolarisSS13/Polaris) (https://github.com/VOREStation/VOREStation). All PRs with edits to stock .DMI files might be rejected.
-* When changing any code in any stock Polaris .DM file, you must mark your changes:
-    * For single-line changes: //CHOMPEdit - "Explanation" (Edit can also be Add for new lines or Removal if you are commenting the line out)
-    * For multi-line additions: //CHOMPEdit - "Explanation" and then at the bottom of your changes, //CHOMPEdit End
-    * For multi-line removals: Use a block comment (/\* xxx \*/) to comment out the existing code block (do not modify whitespace more than necessary) and at the start, it should contain /\* CHOMP Removal - "Reason"
-* If it is something like a bugfix that Polaris or Vorestation would want (the codebase we use), you may want to consider coding it there as well. They may want any general gameplay bugfixes, and things that are obviously intended to work one way, but do not. They do not have any of our fluff species (vulp, akula, fenn, etc) so do not make PRs related to that, or any vore content to them.
-* Change whitespace as little as possible. Do not randomly add/remove whitespace.
-* Any new files should preferrably go into the modular_chomp folder following the file structure of where it would be placed normally. The old method was to have "_ch" at the end. For example, "life_ch.dm".
-* Do not make changes to base icon files. New icon files should go into modular_chomp and code should be changed to point to the new file.
+### TGUI
+* **DO NOT** edit upstream TGUI files. Small changes should be passed to upstream. Large edits require the file to be copied/rewritten in the chompstation subdirectory.
+* **ALL** TGUI files require typescript with properly defined types.
 
-The `attempt_ch()` proc has been added for your convienence. It allows a many-line change to become a single-line change in the existing Polaris files, preserving mergeability and allowing better code separation while preventing your new code from causing runtimes that stop the original code from running. If you are wanting to inject new procedures into an existing proc, called `update_atoms()` for example, you would create `update_atoms_ch()` in a nearby `_ch.dm` file, and then call to it from a single line in the original `update_atoms()` with `attempt_ch()`.
-
-The syntax for `attempt_ch()` is: `attempt_ch(atom,"proc_name",list(arg1,arg2))`, where:
-* `atom` should be replaced with what your extended proc is defined on (if you are in something like /obj/machine/scanner/proc/update_things() and you are calling your newly defined /obj/machine/scanner/proc/update_things_ch() you can just put `src` here)
-* `proc_name` is a STRING that should be the name of your proc, such as "update_atoms_ch"
-* `list(arg1,arg2)` should contain any args you wish to pass to the proc
-
-As an example of something you can do with `attempt_ch()` in a single line, the grab and vore code is done with this in a single line. When a grab is clicked on someone, there is a line similar to:
-`if(attempt_ch(src,"handle_grabs_ch",list(src,attacker))) return`
-
-Then in our `handle_grabs_ch()` proc, if we want to avoid performing the stock game actions and have handled the vore stuff ourselves, we return true, and the original proc returns since attempt_ch returns true.
 
 ### Pull Requests
 
 * Your submission must pass CI checking. The checks are important, prevent many common mistakes, and even experienced coders get caught by it sometimes. If you think there is a bug in CI, open an issue. (One known CI issue is comments in the middle of multi-line lists, just don't do it)
-* Your PR should not have an excessive number of commits unless it is a large project or includes many separate remote commits (such as a pull from Polaris). If you need to keep tweaking your PR to pass CI or to satisfy a maintainer's requests and are making many commits, you should squash them in the end and update your PR accordingly so these commits don't clog up the history.
 * You can create a WIP PR, and if so, please mark it with [WIP] in the title **and make it a draft pr** so it can be labeled appropriately. These can't sit forever, though.
 * If your pull request has many no-conflict merge commits ('merge from master' into your PR branch), it cannot be merged. Squash and make a new PR/forcepush to your PR branch.
+* PRs here are squash-merged into a single commit onto Master
 
 ### Git Commit Messages
 
@@ -92,15 +105,12 @@ Then in our `handle_grabs_ch()` proc, if we want to avoid performing the stock g
 ### Early porting
 
 * You may earlyport.
-* Follow standard chompcomments incase upstream ends up closing their PR for any reason.
-* If it does get merged upstream and the mirror appears on our repo, you are responsible for unfucking the comments situation, because it'll have to say VORE edits instead of CHOMP edits.
+* Follow standard torchcomments incase upstream ends up closing their PR for any reason.
+* If it does get merged upstream and the mirror appears on our repo, you are responsible for fixing the comments situation, because it'll have to say VORE or CHOMP edits instead of TORCH edits.
 
 ## Licensing
-CHOMPStation is licensed under the GNU Affero General Public License version 3, which can be found in full in LICENSE-AGPL3.txt.
+TORCHStation13 is licensed under the GNU Affero General Public License version 3, which can be found in full in LICENSE-AGPL3.txt.
 
 Commits with a git authorship date prior to `1420675200 +0000` (2015/01/08 00:00) are licensed under the GNU General Public License version 3, which can be found in full in LICENSE-GPL3.txt.
 
 All commits whose authorship dates are not prior to `1420675200 +0000` are assumed to be licensed under AGPL v3, if you wish to license under GPL v3 please make this clear in the commit message and any added files.
-
-[Mapmerge2 Readme]: ../tools/mapmerge2/mapmerge tool readme.md
-[StrongDMM]: ../tools/StrongDMM/README.md

.github/ISSUE_TEMPLATE/0-feature.yml

@@ -0,0 +1,29 @@
+name: "✨ New feature"
+description: Suggest an idea for this codebase
+title: "✨ <title>"
+type: 'feature'
+labels: ['Type: Feature/Suggestion']
+body:
+- type: textarea
+  attributes:
+    label: Brief description of the feature
+    description: "Please provide a clear and concise description of what the feature should be."
+  validations:
+    required: true
+
+- type: textarea
+  attributes:
+    label: What you want to happen
+    description: "Please use as much detail as possible when describing the feature behavior, including any context that might be relevant."
+  validations:
+    required: false
+
+- type: textarea
+  attributes:
+    label: Anything else you may wish to add
+    description: |
+      Location if it's a mapping issue, screenshots, sprites, etc.
+
+      Tip: You can attach images or log files by clicking this area to highlight it and then dragging files in.
+  validations:
+    required: false

.github/ISSUE_TEMPLATE/1-bug_report.yml

@@ -0,0 +1,57 @@
+name: General Bug
+description: Create a report to help us improve
+title: '[GENERAL] <title>'
+type: 'bug'
+labels: 'Type: Bug'
+body:
+- type: textarea
+  attributes:
+    label: Brief description of the bug
+    description: "Please provide a clear and concise description of what the bug is."
+  validations:
+    required: true
+
+- type: textarea
+  attributes:
+    label: What you expected to happen
+    description: "What normally happens when this occurs? Keep in mind that behavior may be different on other servers."
+  validations:
+    required: false
+
+- type: textarea
+  attributes:
+    label: What actually happened
+    description: "Please use as much detail as possible when describing the bug behavior, including any context (things you did before) that might be relevant."
+  validations:
+    required: false
+
+- type: textarea
+  attributes:
+    label: Reproduction steps
+    description: "How do you trigger this bug? Please walk us through it step by step."
+    value: |
+      1.
+      2.
+      3.
+      ...
+    render: bash
+  validations:
+    required: true
+
+- type: input
+  attributes:
+    label: Code Revision
+    description: "Found using the 'Show Server Revision' verb under the OOC tab."
+  validations:
+    required: false
+
+- type: textarea
+  attributes:
+    label: Anything else you may wish to add
+    description: |
+      Location if it's a mapping issue, screenshots, sprites, etc.
+
+      Tip: You can attach images or log files by clicking this area to highlight it and then dragging files in.
+  validations:
+    required: false
+

.github/ISSUE_TEMPLATE/2-ui_report.yml

@@ -0,0 +1,42 @@
+name: UI Bug
+description: File a bug report, specific to any UI related things.
+title: '[UI] <title>'
+labels: 'Type: Bug'
+type: 'bug'
+body:
+- type: textarea
+  attributes:
+    label: Brief description of the bug
+    description: "Please provide a clear and concise description of what the bug is."
+  validations:
+    required: true
+
+- type: textarea
+  attributes:
+    label: Reproduction steps
+    description: "How do you trigger this bug? Please walk us through it step by step."
+    value: |
+      1.
+      2.
+      3.
+      ...
+    render: bash
+  validations:
+    required: true
+
+- type: input
+  attributes:
+    label: Code Revision
+    description: "Found using the 'Show Server Revision' verb under the OOC tab."
+  validations:
+    required: false
+
+- type: textarea
+  attributes:
+    label: Anything else you may wish to add
+    description: |
+      Location if it's a mapping issue, screenshots, sprites, etc.
+
+      Tip: You can attach images or log files by clicking this area to highlight it and then dragging files in.
+  validations:
+    required: false