Trijent prison breake

.github/CONTRIBUTING.md

@@ -11,13 +11,15 @@
 		- [Issue Managers](#issue-managers)
 	- [Issues Tracker](#issues-tracker)
 	- [Development Guides](#development-guides)
-			- [Writing readable code](#writing-readable-code)
-			- [Writing sane code](#writing-sane-code)
-			- [Writing understandable code](#writing-understandable-code)
-			- [Misc](#misc)
+		- [Creating a development environment](#creating-a-development-environment)
+		- [Writing readable code](#writing-readable-code)
+		- [Writing sane code](#writing-sane-code)
+		- [Writing understandable code](#writing-understandable-code)
+		- [Misc](#misc)
 	- [Pull Request Process](#pull-request-process)
+		- [A note on PRs altering sprites](#a-note-on-prs-altering-sprites)
+		- [A note on PRs altering maps](#a-note-on-prs-altering-maps)
 		- [A note on balance impacting PRs](#a-note-on-balance-impacting-prs)
-	- [Good Boy Points](#good-boy-points)
 	- [Porting features/sprites/sounds/tools from other codebases](#porting-featuresspritessoundstools-from-other-codebases)
 	- [Things you can work on](#things-you-can-work-on)
 		- [Spriting](#spriting)
@@ -28,6 +30,7 @@
 		- [Mapping](#mapping-1)
 		- [Coding](#coding-1)
 	- [Banned content](#banned-content)
+		- [Generative AI](#generative-ai)
 
 ## Reporting Issues
 
@@ -74,10 +77,13 @@ These are the few directives we have for project maintainers.
     - Try to get secondary maintainer approval before merging if you are able to.
   - PRs with empty commits intended to generate a changelog.
 - Do not merge PRs that contain content from the [banned content list](./CONTRIBUTING.md#banned-content).
-- Do not merge PRs that contain balance changes without Maintainer Manager approval. Exceptions include:
-  - Any PR that has been un-reviewed by a Maintainer Manager for 7 days.
-- Do not remove the DNM label that another Maintainer has applied. Exceptions include:
+- Do not merge or remove the DNM label that another Maintainer has applied. Exceptions include:
   - Maintainer Managers removing a DNM label placed by a Maintainer for Balance/Design reasons
+- Do not merge PRs that lack appropriate approvals:
+  - A PR that alters code needs approval from a codetainer (a maintainer authorized to approve code)
+  - A PR that alters sprites needs approval from a spritetainer (a maintainer authorized to approve sprites)
+  - A PR that alters maps needs approval from a maptainer (a maintainer authorized to approve maps)
+  - A PR that alters balance needs approval from a Maintainer Manager unless it has been un-reviewed by a Maintainer Manager for 7 days.
 
 These are not steadfast rules as maintainers are expected to use their best judgement when operating.
 
@@ -91,16 +97,16 @@ PR’s that affect staff tools/major rules rewrite (adding/removing/editing etc.
 
 ### Issue Managers
 
-Issue Managers help out the project by labelling bug reports and PRs and closing bug reports which are duplicates or are no longer applicable.
+Issue Managers help out the project by labelling bug reports and closing bug reports which are duplicates or are no longer applicable.
 
 <details>
 <summary>What You Can and Can't Do as an Issue Manager</summary>
 
-This should help you understand what you can and can't do with your newfound github permissions.
+This should help you understand what you can and can't do with your newfound GitHub permissions.
 
 Things you **CAN** do:
-- Label issues appropriately
-- Close issues when appropriate
+- Label issues appropriately.
+- Close issues when appropriate.
 
 Things you **CAN'T** do:
 - Close PRs: Only maintainers are allowed to close PRs. Do not hit that button.
@@ -109,18 +115,21 @@ Things you **CAN'T** do:
 </details>
 
 ## Issues Tracker
-Potential bugs can be submitted to the project issue tracker on GitLab. While we appreciate suggestions, they should **not** be posted here to make triaging technical issues and fixing bugs easier.
+Potential bugs can be submitted to the project issue tracker on GitHub. While we appreciate suggestions, they should **not** be posted here to make triaging technical issues and fixing bugs easier.
 
 When submitting an issue, use the provided template. A few things to keep in mind for a good issue report maximizing the chance of finding and fixing it:
 
- * Search quickly for existing related issues - add info there if applicable rather than duplicating them
- * Stay factual and as concise as possible
- * If possible, attempt to reproduce and confirm the issue, and detail steps
+ * Search quickly for existing related issues - add info there if applicable rather than duplicating them.
+ * Stay factual and as concise as possible.
+ * If possible, attempt to reproduce and confirm the issue, and detail steps.
 
 The tracker is a powerful tool - it might look pointless, but ensures what's there can be known by anyone, team members and contributors alike, and won't be forgotten. This maximizes chances of issues being resolved. Don't be afraid to use it.
 
 ## Development Guides
 
+#### Creating a development environment
+[Guide to Git](https://cm-ss13.com/wiki/Guide_to_Git)
+
 #### Writing readable code
 [Style guidelines](./guides/STYLES.md)
 
@@ -139,15 +148,15 @@ The tracker is a powerful tool - it might look pointless, but ensures what's the
 
 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 courteous and respectful. Here are some helpful ways to make it easier for you and for the maintainers when making a pull request.
 
-* Make sure your pull request complies to the requirements outlined here
+* Make sure your pull request complies to the requirements outlined here.
 
 * You are expected to have tested your pull requests if it is anything that would warrant testing. Text only changes, single number balance changes, and similar generally don't need testing, but anything else does. This means by extension web edits are disallowed for larger changes.
 
 * You are going to be expected to document all your changes in the pull request. Failing to do so will mean delaying it as we will have to question why you made the change. On the other hand, you can speed up the process by making the pull request readable and easy to understand, with diagrams or before/after data. Should you be optimizing a routine you must provide proof by way of profiling that your changes are faster.
 
-* We ask that you use the changelog system to document your player facing changes, which prevents our players from being caught unaware by said changes - you can find more information about this [on this wiki page](http://tgstation13.org/wiki/Guide_to_Changelogs).
+* We ask that you use the changelog system to document your player facing changes, which prevents our players from being caught unaware by said changes - you can find more information about this [on this wiki page](http://tgstation13.org/wiki/Guide_to_Changelogs) but all possible options are already in the template when opening a pull request.
 
-* If you are proposing multiple changes, which change many different aspects of the code, you are expected to section them off into different pull requests in order to make it easier to review them and to deny/accept the changes that are deemed acceptable.
+* If you are proposing multiple changes, which change many different aspects of the code, you are expected to section them off (aka atomize) into different pull requests in order to make it easier to review them and to deny/accept the changes that are deemed acceptable.
 
 * If your pull request is accepted, the code you add no longer belongs exclusively to you but to everyone; everyone is free to work on it, but you are also free to support or object to any changes being made, which will likely hold more weight, as you're the one who added the feature. It is a shame this has to be explicitly said, but there have been cases where this would've saved some trouble.
 
@@ -157,12 +166,22 @@ There is no strict process when it comes to merging pull requests. Pull requests
 
 * While we have no issue helping contributors (and especially new contributors) bring reasonably sized contributions up to standards via the pull request review process, larger contributions are expected to pass a higher bar of completeness and code quality *before* you open a pull request. Maintainers may close such pull requests that are deemed to be substantially flawed. You should take some time to discuss with maintainers or other contributors on how to improve the changes.
 
-* After leaving reviews on an open pull request, maintainers should convert it to a draft. Once you have addressed all their comments to the best of your ability, feel free to mark the pull as `Ready for Review` again.
+* After leaving reviews on an open pull request, maintainers should convert it to a draft. Once you have addressed all their comments to the best of your ability, please mark the pull as `Ready for Review` again. Keep in mind it won't appear in our backlog if it is drafted or has merge conflicts.
 
 * We ask that you refrain from pinging staff about getting your pull request reviewed until after it is automatically marked stale pending review. If it ends up stale exempt, give it a week, but usually this situation will be explained such as when a relevant maintainer is currently unavailable.
 
+### A note on PRs altering sprites
+
+Spriting changes requires additional approval from a spritetainer.
+
 * Whenever sprites are added, please include screenshots or video(s) of them in game in the pull request description.
 
+### A note on PRs altering maps
+
+Mapping changes requires additional approval from a maptainer.
+
+* Whenever bulk modifying a map (i.e. repathing existing objects), please include an [UpdatePaths](../tools/UpdatePaths/readme.md) script in your PR (under /tools/UpdatePaths/Scripts) for other mappers to easily apply your changes to their own mapping PRs or for downstreams.
+
 ### A note on balance impacting PRs
 
 Certain PRs, such as those which directly change number values (i.e. health, recoil, damage) or add large pieces of content to the game (i.e. a new gun, a new dropship weapon, or a new xeno structure) can have the potential to highly impact game balance or gameflow.
@@ -175,13 +194,13 @@ Certain PRs, such as those which directly change number values (i.e. health, rec
 
 If you are porting features/tools from other codebases, you must give them credit where it's due. Typically, crediting them in your pull request and the changelog is the recommended way of doing it. Take note of what license they use though, porting stuff from AGPLv3 and GPLv3 codebases are allowed.
 
-Regarding sprites & sounds, you must credit the artist and possibly the codebase.
+* Regarding sprites & sounds, you must credit the artist and possibly the codebase.
 
 ## Things you can work on
+
 The following list is non-exhaustive, but should give you a good idea of what we would like to see in Pull Requests.
 
 ### Spriting
-
 - Replacements of legacy Bay12 sprites
 - Strain specific designs for Aliens for ones that lack them
 - Alternative Alien sprite sets
@@ -193,7 +212,6 @@ The following list is non-exhaustive, but should give you a good idea of what we
 - Additional HUD styles
 - Bug fixes and inconsistency fixes
 
-
 ### Mapping
 - Nightmare inserts
 - Object placement quality of life improvements (such as widening hallways and combat lanes cluttered with props)
@@ -202,9 +220,8 @@ The following list is non-exhaustive, but should give you a good idea of what we
 - New maps*
 - Bug fixes and inconsistency fixes
 
-**A note on new maps.**
-Entirely new maps are generally considered to be stepping stones into the maintainers’ mapping dept. proper. However, making a new map is a months long process that requires dedication and constant communication and oversight from mappers on the Maintainer team. Mapping, like spriting and coding is an acquired skill, and it is highly likely your first map is going to suck. Maps are fluid entities that are never absolutely complete, don’t wed yourself to your initial layout, always be prepared to remap half the project when going in.
-
+#### A note on new maps:
+Entirely new maps are generally considered to be stepping stones into the maintainers’ mapping dept. proper. However, making a new map is a months long process that requires dedication and constant communication and oversight from mappers on the Maintainer team. Mapping, like spriting and coding, is an acquired skill and it is highly likely your first map is going to suck. Maps are fluid entities that are never absolutely complete, don’t wed yourself to your initial layout, always be prepared to remap half the project when going in.
 
 ### Coding
 - Quality of life improvements that don’t impact gameplay, but improve it
@@ -214,7 +231,7 @@ Entirely new maps are generally considered to be stepping stones into the mainta
 - Content for jobs currently lacking in it
 - Anything on the public task-board
 - New Alien strains
-- Bay12 legacy feature removal (such as wizard backend, laser eyes, etc)
+- Bay12 legacy feature removal (such as wizard backend, laser eyes, etc.)
 - Map specific survivor loadouts
 - Bug fixes and inconsistency fixes
 - New TGUI
@@ -249,4 +266,9 @@ Remember that the list is not exhaustive. And you can freely contribute an PR wi
 Do not add any of the following in a Pull Request or risk getting the PR closed:
 * Any content that adds a specific character played by or reference to a single player, contributor, staff member, or maintainer.
 For example, a PR that adds a blue crab named after a staff member’s username is not permitted, as it directly references a specific individual.
-* Code which violates GitHub's [terms of service](https://github.com/site/terms).
+* Code which violates GitHub's [terms of service](https://github.com/site/terms) or [acceptable use policies](https://docs.github.com/en/site-policy/acceptable-use-policies/github-acceptable-use-policies).
+
+### Generative AI
+
+The use of generative AI tools is not permitted on the CM-SS13 repository. This includes but is not limited to pull request code, code review, and filing issues. If you proceed to post PRs, issues, or comments that are clearly AI generated, you will be warned against this and your content will be closed/deleted. Multiple infractions will result in an outright ban from the repository.
+

.github/PULL_REQUEST_TEMPLATE.md

@@ -34,23 +34,25 @@ Put screenshots and videos here with an empty line between the screenshots and t
 
 :cl:
 add: Added something
-del: Removed old things
-qol: made something easier to use
+admin: messed with admin stuff
 balance: rebalanced something
-fix: fixed a few things
-spellcheck: fixed a few typos
-ui: changed something relating to user interfaces
 code: changed some code
-refactor: refactored some code
-soundadd: added a new sound thingy
-sounddel: removed an old sound thingy
+config: changed some config setting
+del: Removed old things
+fix: fixed a few things
 imageadd: added some icons and images
 imagedel: deleted some icons and images
+imagetweak: tweaked some icons and images
 mapadd: added a new map or section to a map
 maptweak: tweaked a map
-config: changed some config setting
-admin: messed with admin stuff
+qol: made something easier to use
+refactor: refactored some code
 server: something server ops should know
+soundadd: added a new sound thingy
+sounddel: removed an old sound thingy
+soundtweak: tweaked a sound thingy
+spellcheck: fixed a few typos
+ui: changed something relating to user interfaces
 /:cl:
 
 <!-- Both :cl:'s are required for the changelog to work! -->

.github/actions/restore_or_install_byond/action.yml

@@ -0,0 +1,51 @@
+# This action attempts to restore BYOND from a cache, or to install it otherwise.
+name: Restore or Install BYOND
+description: Attempts to restore a specified BYOND version from cache; if it can't, it installs it.
+
+inputs:
+  major:
+    description: "The major BYOND version to install. Defaults to the BYOND_MAJOR specified in `dependencies.sh`."
+    required: false
+    type: string
+  minor:
+    description: "The minor BYOND version to install. Defaults to the BYOND_MINOR specified in `dependencies.sh`."
+    required: false
+    type: string
+
+runs:
+  using: composite
+  steps:
+    - name: Configure BYOND version from inputs
+      if: ${{ inputs.major }}
+      shell: bash
+      run: |
+        echo "BYOND_MAJOR=${{ inputs.major }}" >> $GITHUB_ENV
+        echo "BYOND_MINOR=${{ inputs.minor }}" >> $GITHUB_ENV
+    - name: Configure BYOND version from dependencies.sh
+      if: ${{ !inputs.major }}
+      shell: bash
+      run: |
+        source dependencies.sh
+        echo "BYOND_MAJOR=$BYOND_MAJOR" >> $GITHUB_ENV
+        echo "BYOND_MINOR=$BYOND_MINOR" >> $GITHUB_ENV
+
+    # The use of `actions/cache/restore` and `actions/cache/save` here is deliberate, as we want to
+    # save the BYOND install to a cache as early as possible. If we used just `actions/cache`, it
+    # would only attempt to save the cache at the end of a job. This ensures that if a workflow run
+    # is cancelled, we already have a cache to restore from.
+    - name: Restore BYOND cache
+      id: restore_byond_cache
+      uses: actions/cache/restore@v4
+      with:
+        path: ~/BYOND
+        key: ${{ runner.os }}-byond-${{ env.BYOND_MAJOR }}-${{ env.BYOND_MINOR }}
+    - name: Install BYOND
+      if: ${{ !steps.restore_byond_cache.outputs.cache-hit }}
+      shell: bash
+      run: bash tools/ci/install_byond.sh
+    - name: Save BYOND cache
+      if: ${{ !steps.restore_byond_cache.outputs.cache-hit }}
+      uses: actions/cache/save@v4
+      with:
+        path: ~/BYOND
+        key: ${{ steps.restore_byond_cache.outputs.cache-primary-key }}

.github/actions/setup_bun/action.yml

@@ -0,0 +1,17 @@
+# This action is a wrapper around `oven-sh/setup-bun` to use the version specified in
+# `dependencies.sh`.
+name: Setup Bun
+description: Install Bun using the version specified in `dependencies.sh`
+
+runs:
+  using: composite
+  steps:
+    - name: Configure Bun version
+      shell: bash
+      run: |
+        source dependencies.sh
+        echo "BUN_VERSION_REQUIRED=$BUN_VERSION" >> $GITHUB_ENV
+    - name: Install Bun
+      uses: oven-sh/setup-bun@v2
+      with:
+        bun-version: ${{ env.BUN_VERSION_REQUIRED }}

.github/actions/setup_node/action.yml

@@ -0,0 +1,26 @@
+# This action is a wrapper around `actions/setup-node`, to use the version specified in
+# `dependencies.sh`.
+name: Setup Node
+description: Install Node using the version specified in `dependencies.sh`; additionally, restores the Yarn cache if one exists
+
+inputs:
+  restore-yarn-cache:
+    description: 'If `true`, restores the Yarn cache alongside installing node.'
+    required: false
+    type: boolean
+    default: false
+
+runs:
+  using: composite
+  steps:
+    - name: Configure Node version
+      shell: bash
+      run: |
+        source dependencies.sh
+        echo "NODE_VERSION_REQUIRED=$NODE_VERSION_LTS" >> $GITHUB_ENV
+    - name: Install Node
+      uses: actions/setup-node@v4
+      with:
+        node-version: ${{ env.NODE_VERSION_REQUIRED }}
+        cache: ${{ fromJSON(inputs.restore-yarn-cache) && 'yarn' || '' }}
+        cache-dependency-path: ${{ fromJSON(inputs.restore-yarn-cache) && 'tgui/yarn.lock' || '' }}