SpaceRuin: Blackmarket

.github/CONTRIBUTING.md

@@ -56,6 +56,8 @@ actual development.
 
 * 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.
 
+* By ticking or leaving ticked the option "Allow edits and access to secrets by maintainers", either when making a PR or at any time thereafter, you give permission for repository maintainers to push changes to your branch without explicit permission. Repository maintainers will avoid doing this unless necessary, and generally should only use it to apply a merge upstream/master, rebuild TGUI, deconflict maps, or other minor changes required shortly before a PR is to be merged. More extensive changes such as force-pushes to your branch require explicit permission from the PR author each time such a change needs to be made.
+
 #### Using The Changelog
 
 * The tags able to be used in the changelog are: `add/soundadd/imageadd`, `del/sounddel/imagedel`, `tweak`, `fix`, `wip`, `spellcheck`, and `experiment`.
@@ -547,22 +549,24 @@ in the SQL/updates folder.
     * Failure to run Map Merge on a map after editing greatly increases the risk of the map's key dictionary becoming corrupted by future edits after running map merge. Resolving the corruption issue involves rebuilding the map's key dictionary;
 
 * StrongDMM
-  * When using StrongDMM, the following options should be enabled to avoid file bloat. They can be found under `File > Preferences` in SDMM2.
-    * Sanitize Variables - Removes variables that are declared on the map, but are the same as default. (For example: A standard floor turf that has `dir = 2` declared on the map will have that variable deleted as it is redundant.)
-    * Save format - Either `Initial` or `TGM`, never `DM`.
+  * [We strongly encourage use of StrongDMM version 2 or greater, available here.](https://github.com/SpaiR/StrongDMM/releases)
+  * When using StrongDMM, the following options must be enabled. They can be found under `File > Preferences`.
+    * Sanitize Variables - Removes variables that are declared on the map, but are the same as initial. (For example: A standard floor turf that has `dir = 2` declared on the map will have that variable deleted as it is redundant.)
+    * Save format - `TGM`.
+    * Nudge mode - pixel_x/pixel_y
 
 * Variable Editing (Var-edits)
-  * While var-editing an item within the editor is perfectly fine, it is preferred that when you are changing the base behavior of an item (how it functions) that you make a new subtype of that item within the code, especially if you plan to use the item in multiple locations on the same map, or across multiple maps. This makes it easier to make corrections as needed to all instances of the item at one time as opposed to having to find each instance of it and change them all individually.
-    * Subtypes only intended to be used on away mission or ruin maps should be contained within an .dm file with a name corresponding to that map within `code\modules\awaymissions` or `code\modules\ruins` respectively. This is so in the event that the map is removed, that subtype will be removed at the same time as well to minimize leftover/unused data within the repo.
-  * Please attempt to clean out any dirty variables that may be contained within items you alter through var-editing. For example, due to how DM functions, changing the `pixel_x` variable from 23 to 0 will leave a dirty record in the map's code of `pixel_x = 0`. Likewise this can happen when changing an item's icon to something else and then back. This can lead to some issues where an item's icon has changed within the code, but becomes broken on the map due to it still attempting to use the old entry.
-  * Areas should not be var-edited on a map to change it's name or attributes. All areas of a single type and it's altered instances are considered the same area within the code, and editing their variables on a map can lead to issues with powernets and event subsystems which are difficult to debug.
+  * While var-editing an item within the editor is fine, it is preferred that when you are changing the base behavior of an item (how it functions) that you make a new subtype of that item within the code, especially if you plan to use the item in multiple locations on the same map, or across multiple maps. This makes it easier to make corrections as needed to all instances of the item at one time, as opposed to having to find each instance of it and change them all individually.
+    * Subtypes only intended to be used on ruin maps should be contained within an .dm file with a name corresponding to that map within `code\modules\ruins`. This is so in the event that the map is removed, that subtype will be removed at the same time as well to minimize leftover/unused data within the repo.
+  * When not using StrongDMM (which handles the following automatically) please attempt to clean out any dirty variables that may be contained within items you alter through var-editing. For example changing the `pixel_x` variable from 23 to 0 will leave a dirty record in the map's code of `pixel_x = 0`.
+  * Areas should **never** be var-edited on a map. All areas of a single type, altered instance or not, are considered the same area within the code, and editing their variables on a map can lead to issues with powernets and event subsystems which are difficult to debug.
   * Unless they require custom placement, when placing the following items use the relevant "[direction] bump" instance, as it has predefined pixel offsets and directions that are standardised: APC, Air alarm, Fire alarm, station intercom, newscaster, extinguisher cabient, light switches.
 
-* If you are making non-minor edits to an area or room, (non-minor being anything more than moving a few objects or fixing small bugs) then you should ensure the entire area/room meets these standards.
+* If you are making non-minor edits to an area or room, (non-minor being anything more than moving a few objects or fixing small bugs) then you should ensure the entire area/room is updated to meet these standards.
 
 * When making a change to an area or room, follow these guidelines:
   * Unless absolutely necessary, do not run pipes (including disposals) under wall turfs.
-  * NEVER run cables under wall turfs.
+  * **NEVER** run cables under wall turfs.
   * Keep floor turf variations to a minimum. Generally, more than 3 floor turf types in one room is bad design.
   * Run air pipes together where possible. The first example below is to be avoided, the second is optimal:
 
@@ -580,21 +584,28 @@ in the SQL/updates folder.
       * A good example would be the template [Department name] - [Area], so Brig - Cell 1, or Medbay - Treatment Center. Consistency is key to good camera naming.
     * Fire alarms should not be placed next to expected heat sources.
     * Use the following "on" subtype of vents and scrubbers as opposed to var-editing: `/obj/machinery/atmospherics/unary/vent_scrubber/on` and `/obj/machinery/atmospherics/unary/vent_pump/on`
-  * Head of staff officers should contain a requests console.
-  * Firelocks should be used at area boundaries over doors and windows. Firelocks can also be used to break up hallways at reasonable intervals.
-    * Double firelocks are to be avoided unless absolutely necessary.
-    * Maintenance access doors should not have firelocks placed over them.
+  * Head of staff offices should contain a requests console.
+  * Electrochromic windows (`/obj/structure/window/reinforced/polarized`) and doors/windoors (using the `/obj/effect/mapping_helpers/airlock/polarized` helper) are preferred over shutters as the method of restricting view to a room through windows. Shutters are sill appropriate in industrial/hazardous areas of the station (engine rooms, HoP line, science test chamber, etc.).
+    * Electrochromic window/windoor/door sets require a unique ID var, and a window tint button (`/obj/machinery/button/windowtint`) with a matching ID var. The default `range` of the button is 7 tiles but can be amended with a var edit.
+  * Tiny fans (`/obj/structure/fans/tiny`) can be used to block airflow into problematic areas, but are not a substitute for proper door and firelock combinations. They are useful under blast doors that lead to space when opened.
+  * Firelocks should be used at area boundaries over doors and windoors, but not windows. Firelocks can also be used to break up hallways at reasonable intervals.
+    * Double firelocks are not permitted.
+    * Maintenance access doors should never have firelocks placed over them.
   * Windows to secure areas or external areas should be reinforced. Windows in engine areas should be reinforced plasma glass.
     * Windows in high security areas, such as the brig, bridge, and head of staff offices, should be electrified by placing a wire node under the window.
   * Lights are to be used sparingly, they draw a significant amount of power.
-  * Ensure door and windoor access is correctly set, these are handled by the variables `req_access_txt` and `req_one_access_txt`. Public doors should have both of these values as `"0"`. For a list of access values, see [`code\__DEFINES\access.dm`](code/__DEFINES/access.dm).
-    * Always use numerical values encased in quotes for these variables. Multiple access values can be defined by separating them with a `;`, for example: `"28;31"` for kitchen AND cargo access.
-    * req_access_txt requires ALL LISTED ACCESSES to open the door, while req_one_access_txt lets anyone with ONE OF THE LISTED ACCESSES open the door.
+  * Ensure door and windoor access is correctly set, this is now done by using access helpers.
+    * Multiple accesses can be added to a door by placing multiple access helpers on the same tile. Be sure to pay attention so as to avoid mixing up `all` and `any` subtypes.
+    * Old doors that use var edited access should be updated to use the correct access helper, and the var edit on the door should be cleaned.
+      * See [`code\modules\mapping\access_helpers.dm`](../code/modules/mapping/access_helpers.dm) for a list of all access helpers.
+    * Subtypes of `/obj/effect/mapping_helpers/airlock/access/any` lets anyone with ONE OF THE LISTED ACCESSES open the door.
+    * Subtypes of `/obj/effect/mapping_helpers/airlock/access/all` requires ALL ACCESSES present to open the door.
+
   * Departments should be connected to maintenance through a back or side door. This lets players escape and allows antags to break in.
     * If this is not possible, departments should have extra entry and exit points.
   * Engine areas, or areas with a high probability of receiving explosions, should use reinforced flooring if appropriate.
   * External areas, or areas where depressurisation is expected and normal, should use airless turf variants to prevent additional atmospherics load.
-  * Edits in mapping tools should generally be possible to replicate in-game. For this reason, avoid stacking multiple structures on the same tile (i.e. placing a light and an APC on the same wall.)
+  * Edits in mapping tools should almost always be possible to replicate in-game. For this reason, avoid stacking multiple structures on the same tile (i.e. placing a light and an APC on the same wall.)
 
 ### Other Notes
 
@@ -619,7 +630,7 @@ Like all languages, Dream Maker has its quirks, some of them are beneficial to u
 
 HOWEVER, if either `some_value` or `i` changes within the body of the for (underneath the `for(...)` header) or if you are looping over a list AND changing the length of the list then you can NOT use this type of for-loop!
 
-### `for(var/A in list)` VS `for(var/i in 1 to list.len)`
+### `for(var/A in list)` VS `for(var/i in 1 to length(list))`
 
 The former is faster than the latter, as shown by the following profile results: [https://file.house/zy7H.png](https://file.house/zy7H.png)
 

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,35 +1,38 @@
-<!-- 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. -->
+<!-- Пишите **НИЖЕ** заголовков и **ВЫШЕ** комментариев, иначе что то может пойти не так. -->
+<!-- Вы можете прочитать Contributing.MD, если хотите узнать больше. -->
 
-## What Does This PR Do
-<!-- Include a small to medium description of what your PR changes. -->
-<!-- Document all changes, as not doing this may delay reviews or even discourage maintainers from merging your PR! -->
-<!-- If your PR fixes an issue, add "Fixes #1234" somewhere in the PR description. This will automatically close the bug upon PR submission. -->
+## Что этот PR делает
 
-## Why It's Good For The Game
-<!-- Add a short description of why you think these changes would benefit the game. If you can't justify it in words, it might not be worth adding. -->
+<!-- Вкратце опишите изменения, которые вносите. -->
+<!-- Опишите **все** изменения, так как противное может сказаться на рассмотрении этого PR'а! -->
+<!-- Если вы исправляете Issue, добавьте "Fixes #1234" (где 1234 - номер Issue) где-нибудь в описании PR'а. Это автоматически закроет Issue после принятия PR'а. -->
 
-## Images of changes
-<!-- If you did not make a map or sprite edit, you may delete this section. You may include a gif or mp4 of your feature if you want. -->
+## Почему это хорошо для игры
 
-## Testing
-<!-- How did you test the PR, if at all? -->
+<!-- Опишите, почему, по вашему, следует добавить эти изменения в игру. -->
+
+## Изображения изменений
+<!-- Если вы не меняли карту или спрайты, можете опустить эту секцию. Если хотите, можете вставить видео. -->
+
+## Тестирование
+<!-- Как вы тестировали свой PR, если делали это вовсе? -->
 
 ## Changelog
+
 :cl:
-add: Added new things
-del: Removed old things
-tweak: Tweaked a few things
-fix: Fixed a few things
-wip: Added a few works in progress
-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
-experiment: Added an experimental thingy
+add: Что-то добавил
+del: Что-то удалил
+tweak: Поменял что-то по мелочи
+fix: Что-то починил
+wip: Какие-либо наработки в процессе
+soundadd: Добавил новый звук
+sounddel: Удалил старый звук
+imageadd: Добавил новую картинку
+imagedel: Удалил старую картинку
+spellcheck: Исправил опечатку
+experiment: Добавил эксперементальную функцию
 /: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. -->
-<!-- If a PR has no impact on players (i.e. a code refactor that does not change functionality) then the entire Changelog heading and contents can be removed. -->
+<!-- Оба :cl:'а должны быть на месте, что-бы чейнджлог работал! Вы можете написать свой ник справа от первого :cl:, если хотите. Иначе будет использован ваш ник на ГитХабе. -->
+<!-- Вы можете использовать несколько записей с одинаковым префиксом (Они используются только для иконки в игре) и удалить ненужные. Помните, что чейнджлог должен быть понятен обычным игроком. -->
+<!-- Если чейнджлог не влияет на игроков(например, это рефактор), вы можете исключить всю секцию. -->

.github/workflows/check_changelog.yml

@@ -0,0 +1,32 @@
+name: Changelog validation
+
+permissions:
+  contents: read
+  pull-requests: write
+  issues: write
+
+on:
+  pull_request_target:
+    types: [opened, reopened, edited, labeled, unlabeled]
+
+jobs:
+  CheckCL:
+    runs-on: ubuntu-latest
+    if: github.repository == 'ss220club/Paradise-SS220' && github.base_ref == 'master' && github.event.pull_request.draft == false
+    steps:
+      - name: Downloading scripts
+        run: |
+          wget https://raw.githubusercontent.com/ss220club/Paradise-SS220/master/tools/changelog/check_changelog.py
+          wget https://raw.githubusercontent.com/ss220club/Paradise-SS220/master/tools/changelog/tags.yml
+      - name: Installing Python
+        uses: actions/setup-python@61a6322f88396a6271a6ee3565807d608ecaddd1
+        with:
+          python-version: '3.x'
+      - name: Installing deps
+        run: |
+          python -m pip install --upgrade pip
+          pip install ruamel.yaml PyGithub
+      - name: Changelog validation
+        env:
+          BOT_TOKEN: ${{ secrets.BOT_TOKEN }}
+        run: python check_changelog.py

.github/workflows/ci.yml

@@ -35,6 +35,7 @@ jobs:
           python tools/ci/check_line_endings.py
           python tools/ci/check_file_names.py
           python tools/ci/unticked_files.py ${GITHUB_WORKSPACE}
+          python tools/ci/illegal_dme_files.py ${GITHUB_WORKSPACE}
           python -m tools.maplint.source --github
           ~/dreamchecker > ${GITHUB_WORKSPACE}/output-annotations.txt 2>&1
       - name: Annotate Lints
@@ -107,7 +108,7 @@ jobs:
           sudo apt install libssl1.1:i386
           ldd librust_g.so
       - name: Start Redis
-        uses: supercharge/redis-github-action@1.5.0
+        uses: supercharge/redis-github-action@1.6.0
         with:
           redis-version: 6
       - name: Compile & Run Unit Tests

.github/workflows/deploy.yml

@@ -0,0 +1,24 @@
+name: Deploy
+
+concurrency:
+  group: deploy
+
+on:
+  workflow_dispatch:
+  push:
+    branches: ['master', 'devtest']
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Trigger update
+        uses: appleboy/ssh-action@master
+        with:
+          host: ${{ secrets.GAME1_HOST }}
+          username: ${{ secrets.GAME1_USERNAME }}
+          key: ${{ secrets.GAME1_SSH_KEY }}
+          script: |
+            cd /opt/ss13/paradise/
+            ./upgrade.sh

.github/workflows/generate_autodoc.yml

@@ -8,7 +8,7 @@ on:
 jobs:
   generate_docs:
     name: 'Generate Documentation'
-    runs-on: ubuntu-18.04
+    runs-on: ubuntu-20.04
     steps:
     - name: 'Update Branch'
       uses: actions/checkout@v3

.github/workflows/label_merge_conflicts.yml

@@ -1,13 +1,19 @@
 name: 'Merge Conflict Detection'
+
 on:
   push:
     branches:
       - master
+  pull_request_target:
+    types: [ready_for_review, opened, synchronize, reopened]
 jobs:
   triage:
-    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      pull-requests: write
+    runs-on: ubuntu-22.04
     steps:
-      - uses: mschilde/auto-label-merge-conflicts@master
+      - uses: eps1lon/actions-label-merge-[email protected]
         with:
-          CONFLICT_LABEL_NAME: 'Merge Conflict'
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          dirtyLabel: 'Merge Conflict'
+          repoToken: ${{ secrets.GITHUB_TOKEN }}

.gitignore

@@ -57,3 +57,4 @@ __pycache__/
 dmm-tools.exe
 OpenDream
 paradise.json
+sound/tts_cache/*