Merge remote-tracking branch 'upstream/master'

.gitattributes

@@ -1,2 +1,3 @@
 ## Merger hooks, run tools/hooks/install.bat or install.sh to set up
 *.dmm text eol=lf merge=dmm
+*.dmi binary merge=dmi

.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`.
@@ -383,7 +385,7 @@ Look for code examples on how to properly use it.
 
 //Good
 /datum/datum1/proc/proc1(target)
-    addtimer(CALLBACK(target, .proc/dothing, arg1, arg2, arg3), 5 SECONDS)
+    addtimer(CALLBACK(target, PROC_REF(dothing), arg1, arg2, arg3), 5 SECONDS)
 ```
 
 ### Operators
@@ -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
 
@@ -607,6 +618,8 @@ in the SQL/updates folder.
 
 * All new var/proc names should use the American English spelling of words. This is for consistency with BYOND.
 
+* All mentions of the company "Nanotrasen" should be written as such - 'Nanotrasen'. Use of CamelCase (NanoTrasen) is no longer proper.
+
 * If you are making a PR that adds a config option to change existing behaviour, said config option must default to as close to as current behaviour as possible.
 
 ### Dream Maker Quirks/Tricks
@@ -619,7 +632,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)
 
@@ -734,6 +747,7 @@ Each role inherits the lower role's responsibilities (IE: Headcoders also have c
 
 * [AffectedArc07](https://github.com/AffectedArc07)
 * [Charliminator](https://github.com/hal9000PR)
+* [lewcc](https://github.com/lewcc)
 * [S34N](https://github.com/S34NW)
 
 ---

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,3 +1,5 @@
+<!-- By ticking or leaving ticked the option "Allow edits and access to secrets by maintainers" you give permission for repository maintainers to push changes to your branch without explicilty asking. -->
+
 <!-- 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. -->
 

.github/workflows/ci.yml

@@ -12,7 +12,7 @@ jobs:
     name: Run Linters
     runs-on: ubuntu-20.04
     steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
       - name: Setup Cache
         uses: actions/cache@v3
         with:
@@ -35,6 +35,8 @@ 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.ci.check_icon_conflicts
           python -m tools.maplint.source --github
           ~/dreamchecker > ${GITHUB_WORKSPACE}/output-annotations.txt 2>&1
       - name: Annotate Lints
@@ -47,7 +49,7 @@ jobs:
     name: Lint with OpenDream
     runs-on: ubuntu-20.04
     steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
       - name: Setup OD
         run: |
           bash tools/ci/setup_od.sh
@@ -59,7 +61,7 @@ jobs:
     name: Compile All Maps
     runs-on: ubuntu-20.04
     steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
       - name: Setup Cache
         uses: actions/cache@v3
         with:
@@ -89,7 +91,7 @@ jobs:
           - 3306
         options: --health-cmd "mariadb-admin ping" --health-interval 10s --health-timeout 5s --health-retries 10
     steps:
-      - uses: actions/checkout@v3
+      - uses: actions/checkout@v4
       - name: Setup Cache
         uses: actions/cache@v3
         with:
@@ -107,7 +109,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.7.0
         with:
           redis-version: 6
       - name: Compile & Run Unit Tests
@@ -122,7 +124,7 @@ jobs:
     name: Windows RUSTG Validation
     runs-on: windows-latest
     steps:
-    - uses: actions/checkout@v3
+    - uses: actions/checkout@v4
     - uses: actions/setup-python@v4
       with:
         python-version: '3.8.2' # Script was made for 3.8.2

.github/workflows/dmi5.yml

@@ -7,7 +7,7 @@ jobs:
     runs-on: ubuntu-latest
 
     steps:
-    - uses: actions/checkout@v3
+    - uses: actions/checkout@v4
     - uses: ParadiseSS13/DMI5Checker@v1
       with:
         icons-path: 'icons'

.github/workflows/generate_autodoc.yml

@@ -8,10 +8,10 @@ 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
+      uses: actions/checkout@v4
       with:
         fetch-depth: 1
         ref: master
@@ -24,7 +24,7 @@ jobs:
       # Nojekyll is important to disable jeykll syntax, which can mess with files that start with underscores
 
     - name: 'Deploy Documentation'
-      uses: crazy-max/ghaction-github-pages@v3
+      uses: crazy-max/ghaction-github-pages@v4
       with:
         keep_history: false
         build_dir: dmdoc

.github/workflows/render_nanomaps.yml

@@ -21,7 +21,7 @@ jobs:
     runs-on: ubuntu-22.04
     steps:
     - name: 'Update Branch'
-      uses: actions/checkout@v3
+      uses: actions/checkout@v4
 
     - name: Branch
       run: |

.gitignore

@@ -25,6 +25,7 @@ stddef.dm
 .atom-build.json
 *.vscode/*
 !/.vscode/extensions.json
+!/.vscode/tasks.json
 
 # ignore DMI tool build cache
 /tools/dmitool/bin/

.vscode/extensions.json

@@ -6,6 +6,7 @@
 		"dbaeumer.vscode-eslint",
 		"eamodio.gitlens",
 		"usernamehw.errorlens",
-		"anturk.dmi-editor"
+		"anturk.dmi-editor",
+		"esbenp.prettier-vscode"
     ]
 }

.vscode/tasks.json

@@ -0,0 +1,54 @@
+{
+	"version": "2.0.0",
+	"tasks": [
+		{
+			"type": "dreammaker",
+			"dme": "paradise.dme",
+			"problemMatcher": [
+				"$dreammaker"
+			],
+			"group": "build",
+			"label": "dm: build - paradise.dme"
+		},
+		{
+			"type": "shell",
+			"command": "tgui/bin/tgui-build",
+			"windows": {
+				"command": ".\\tgui\\bin\\tgui-build.bat"
+			},
+			"problemMatcher": [
+				"$tsc",
+				"$eslint-stylish"
+			],
+			"group": "build",
+			"label": "tgui: build"
+		},
+		{
+			"type": "shell",
+			"command": "tgui/bin/tgui-dev-server",
+			"windows": {
+				"command": ".\\tgui\\bin\\tgui-dev-server.bat"
+			},
+			"problemMatcher": [
+				"$tsc",
+				"$eslint-stylish"
+			],
+			"group": "build",
+			"label": "tgui: run dev server"
+		}
+		,
+		{
+			"type": "shell",
+			"command": "tgui/bin/tgui-formatting",
+			"windows": {
+				"command": ".\\tgui\\bin\\tgui-formatting.bat"
+			},
+			"problemMatcher": [
+				"$tsc",
+				"$eslint-stylish"
+			],
+			"group": "build",
+			"label": "tgui: run prettier formatting"
+		}
+	]
+}

SQL/paradise_schema.sql

@@ -117,6 +117,7 @@ CREATE TABLE `death` (
   `coord` text NOT NULL COMMENT 'X, Y, Z POD',
   `tod` datetime NOT NULL COMMENT 'Time of death',
   `death_rid` INT NULL,
+  `last_words` text NULL DEFAULT NULL,
   `server_id` TEXT NULL DEFAULT NULL,
   `job` text NOT NULL,
   `special` text NOT NULL,
@@ -473,7 +474,17 @@ CREATE TABLE `playtime_history` (
   `ckey` varchar(32) NOT NULL,
   `date` DATE NOT NULL,
   `time_living` SMALLINT NOT NULL,
+  `time_crew` SMALLINT NOT NULL,
+  `time_special` SMALLINT NOT NULL,
   `time_ghost` SMALLINT NOT NULL,
+  `time_command` SMALLINT NOT NULL,
+  `time_engineering` SMALLINT NOT NULL,
+  `time_medical` SMALLINT NOT NULL,
+  `time_science` SMALLINT NOT NULL,
+  `time_supply` SMALLINT NOT NULL,
+  `time_security` SMALLINT NOT NULL,
+  `time_silicon` SMALLINT NOT NULL,
+  `time_service` SMALLINT NOT NULL,
   PRIMARY KEY (`ckey`, `date`)
 ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
 
@@ -606,3 +617,19 @@ CREATE TABLE `tickets` (
 	CONSTRAINT `all_responses` CHECK (json_valid(`all_responses`)),
 	CONSTRAINT `awho` CHECK (json_valid(`awho`))
 ) COLLATE='utf8mb4_general_ci' ENGINE=InnoDB;
+
+--
+-- Table structure for table `json_datum_saves`
+--
+DROP TABLE IF EXISTS `json_datum_saves`;
+CREATE TABLE `json_datum_saves` (
+	`id` INT(11) NOT NULL AUTO_INCREMENT,
+	`ckey` VARCHAR(64) NOT NULL COLLATE 'utf8mb4_general_ci',
+	`slotname` VARCHAR(32) NOT NULL COLLATE 'utf8mb4_general_ci',
+	`slotjson` LONGTEXT NOT NULL COLLATE 'utf8mb4_general_ci',
+	`created` DATETIME NOT NULL DEFAULT current_timestamp(),
+	`updated` DATETIME NOT NULL DEFAULT current_timestamp() ON UPDATE current_timestamp(),
+	PRIMARY KEY (`id`) USING BTREE,
+	UNIQUE INDEX `ckey_unique` (`ckey`, `slotname`) USING BTREE,
+	INDEX `ckey` (`ckey`) USING BTREE
+) COLLATE = 'utf8mb4_general_ci' ENGINE = InnoDB;