Tgstation master

.github/CODEOWNERS

@@ -189,7 +189,6 @@
 /_maps/ @EOBGames @Maurukas @MMMiracles @san7890 @ShizCalev
 
 /icons/ @Imaginos16 @Krysonism @Twaticus @Wallemations
-/icons/ass/ @Ghilker @tralezab
 
 /code/__DEFINES/atmospherics/ @Ghilker @LemonInTheDark
 

.github/ISSUE_TEMPLATE/bug_report_form.yml

@@ -0,0 +1,65 @@
+name: Bug Report
+description: Create a report to help reproduce and fix the issue.
+body:
+  - type: markdown
+    attributes:
+      value: |
+        # **Please read the following guidelines. Follow all instructions or else your issue is subject to closure.**
+        ## If you use the "Report Issue" button in the top-right corner of the game, it will automatically fill in some of the information below.
+
+        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, please 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 repository you will be refused help unless you can completely reproduce the issue on our master branch.
+  - type: input
+    id: reporting-version
+    attributes:
+      label: "Client Version:"
+      description: |
+        The BYOND version you are using to report this issue. You can find this information in the bottom left corner of the "About BYOND" window in the BYOND client.
+        It is strongly recommended that you include this, especially for concerns on the visual aspects of the game.
+      placeholder: "xxx.xxxx"
+    validations:
+      required: false
+  - type: textarea
+    id: issue-summary
+    attributes:
+      label: "Issue Summary:"
+      description: |
+        Briefly explain your issue in a few plain sentences. You may copy and paste the issue title here if it is suitable.
+      placeholder: |
+        "When I do X, Y happens instead of Z."
+        "X on Y map has Z issue."
+    validations:
+      required: true
+  - type: input
+    id: round-id
+    attributes:
+      label: "Round ID:"
+      description: |
+        If you discovered this issue from playing tgstation hosted servers, the Round ID can be found in the Status panel or retrieved from https://statbus.space/
+        The Round ID lets us look up valuable information and logs for the round the bug happened. Leave this blank if there is no round ID.
+      placeholder: "XXXXXX"
+    validations:
+      required: false
+  - type: textarea
+    id: test-merges
+    attributes:
+      label: "Test Merge Information:"
+      description: |
+        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 submission of this form.
+    validations:
+      required: false
+  - type: textarea
+    id: reproduction
+    attributes:
+      label: "Reproduction Steps:"
+      description: |
+        Describe the steps to reproduce the issue in detail. Include any relevant information, such as the map, round type, and any other factors that may be relevant.
+        If it is a runtime-related error, please include the runtime here as that is pertient information. Issues are not for oddities introduced by admin varedits, ensure these occur in normal circumstances.
+      placeholder: |
+        1. Go to the X location
+        2. Do Y action
+        3. Observe Z result
+    validations:
+      required: true

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,4 @@
+contact_links:
+  - name: Feature Requests
+    url: https://tgstation13.org/phpBB/viewforum.php?f=9
+    about: Post feature requests and suggestions on the forums. This repository does not handle them.

.github/PULL_REQUEST_TEMPLATE.md

@@ -11,7 +11,7 @@
 
 ## 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. -->
+<!-- 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 its 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
@@ -22,6 +22,7 @@ balance: rebalanced something
 fix: fixed a few things
 sound: added/modified/removed audio or sound effects
 image: added/modified/removed some icons or images
+map: added/modified/removed map content
 spellcheck: fixed a few typos
 code: changed some code
 refactor: refactored some code

.github/dependabot.yml

@@ -0,0 +1,11 @@
+# https://docs.github.com/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file
+version: 2
+updates:
+  - package-ecosystem: github-actions
+    directory: /
+    target-branch: master
+    schedule:
+      interval: daily
+    labels:
+      - GitHub
+    open-pull-requests-limit: 10

.github/gbp.toml

@@ -23,3 +23,4 @@ reset_label = "GBP: Reset"
 "Sound" = 3
 "Sprites" = 3
 "Unit Tests" = 6
+"Wallening Revert Recovery" = 10

.github/guides/AUTODOC.md

@@ -40,7 +40,7 @@ public functions rely on to implement logic
 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
+the proc to jump to its definition
 ```
 /**
  * Short description of the proc
@@ -59,7 +59,7 @@ 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
+Finally we give a longer multi paragraph description of the class and its details
 ```
 /**
  * # Classname (Can be omitted if it's just going to be the typepath)

.github/guides/RUNNING_A_SERVER.md

@@ -4,7 +4,7 @@ BYOND installed. You can get it from https://www.byond.com/download. Once you've
 that, extract the game files to wherever you want to keep them. This is a
 sourcecode-only release, so the next step is to compile the server files.
 
-Double-click `BUILD.bat` in the root directory of the source code. This'll take
+Double-click `BUILD.cmd` in the root directory of the source code. This'll take
 a little while, and if everything's done right you'll get a message like this:
 
 ```

.github/guides/STANDARDS.md

@@ -100,11 +100,11 @@ While we normally encourage (and in some cases, even require) bringing out of da
 ### RegisterSignal()
 
 #### PROC_REF Macros
-When referencing procs in RegisterSignal, Callback and other procs you should use PROC_REF, TYPE_PROC_REF and GLOBAL_PROC_REF macros. 
+When referencing procs in RegisterSignal, Callback and other procs you should use PROC_REF, TYPE_PROC_REF and GLOBAL_PROC_REF macros.
 They ensure compilation fails if the reffered to procs change names or get removed.
 The macro to be used depends on how the proc you're in relates to the proc you want to use:
 
-PROC_REF if the proc you want to use is defined on the current proc type or any of it's ancestor types.
+PROC_REF if the proc you want to use is defined on the current proc type or any of its ancestor types.
 Example:
 ```
 /mob/proc/funny()
@@ -129,7 +129,7 @@ Example:
 /mob/subtype/proc/do_something()
 	var/obj/thing/x = new()
 	// we're referring to /obj/thing proc inside /mob/subtype proc
-	RegisterSignal(x, COMSIG_FAKE, TYPE_PROC_REF(/obj/thing, funny)) 
+	RegisterSignal(x, COMSIG_FAKE, TYPE_PROC_REF(/obj/thing, funny))
 ```
 
 GLOBAL_PROC_REF if the proc you want to use is a global proc.
@@ -154,7 +154,7 @@ All procs that are registered to listen for signals using `RegisterSignal()` mus
 ```
 This is to ensure that it is clear the proc handles signals and turns on a lint to ensure it does not sleep.
 
-Any sleeping behaviour that you need to perform inside a `SIGNAL_HANDLER` proc must be called asynchronously (e.g. with `INVOKE_ASYNC()`) or be redone to work asynchronously. 
+Any sleeping behaviour that you need to perform inside a `SIGNAL_HANDLER` proc must be called asynchronously (e.g. with `INVOKE_ASYNC()`) or be redone to work asynchronously.
 
 #### `override`
 
@@ -280,7 +280,7 @@ Good:
 		off_overlay = iconstate2appearance(icon, "off")
 		broken_overlay = icon2appearance(broken_icon)
 	if (stat & broken)
-		add_overlay(broken_overlay) 
+		add_overlay(broken_overlay)
 		return
 	if (is_on)
 		add_overlay(on_overlay)
@@ -304,7 +304,7 @@ Bad:
 	if (isnull(our_overlays))
 		our_overlays = list("on" = iconstate2appearance(overlay_icon, "on"), "off" = iconstate2appearance(overlay_icon, "off"), "broken" = iconstate2appearance(overlay_icon, "broken"))
 	if (stat & broken)
-		add_overlay(our_overlays["broken"]) 
+		add_overlay(our_overlays["broken"])
 		return
 	...
 ```
@@ -391,7 +391,7 @@ At its best, it can make some very common patterns easy to use, and harder to me
 		some_code()
 		if (do_something_else())
 			. = TRUE // Uh oh, what's going on!
-	
+
 	// even
 	// more
 	// code
@@ -468,7 +468,7 @@ Meaning:
 	to_chat(world, uh_oh())
 ```
 
-...will print `woah!`. 
+...will print `woah!`.
 
 For this reason, it is acceptable for `.` to be used in places where consumers can reasonably continue in the event of a runtime.
 
@@ -494,7 +494,7 @@ If you are using `.` in this case (or for another case that might be acceptable,
 	. = ..()
 	if (. == BIGGER_SUPER_ATTACK)
 		return BIGGER_SUPER_ATTACK // More readable than `.`
-	
+
 	// Due to how common it is, most uses of `. = ..()` do not need a trailing `return .`
 ```
 
@@ -513,6 +513,30 @@ The following is a list of procs, and their safe replacements.
 * Move away from something, taking turf density into account `walk_away()` -> `SSmove_manager.move_away()`
 * Move to a random place nearby. NOT random walk `walk_rand()` -> `SSmove_manager.move_rand()` is random walk, `SSmove_manager.move_to_rand()` is walk to a random place
 
+### Avoid pointer use
+
+BYOND has a variable type called pointers, which allow you to reference a variable rather then its value. As an example of how this works:
+
+```
+var/pointed_at = "text"
+var/value = pointed_at // copies the VALUE of pointed at
+var/reference = &pointed_at // points at pointed_at itself
+
+// so we can retain a reference even if pointed_at changes
+pointed_at = "text AGAIN"
+world << (*reference) // Deref to get the value, outputs "text AGAIN"
+
+// or modify the var remotely
+*reference = "text a THIRD TIME"
+world << pointed_at // outputs "text a THIRD TIME"
+```
+
+The problem with this is twofold.
+- First: if you use a pointer to reference a var on a datum, it is essentially as if you held an invisible reference to that datum. This risks hard deletes in very unclear ways that cannot be tested for.
+- Second: People don't like, understand how pointers work? They mix them up with classical C pointers, when they're more like `std::shared_ptr`. This leads to code that just doesn't work properly, or is hard to follow without first getting your mind around it. It also risks hiding what code does in dumb ways because pointers don't have unique types.
+
+For these reasons and with the hope of avoiding pointers entering general use, be very careful using them, if you use them at all.
+
 ### BYOND hellspawn
 
 What follows is documentation of inconsistent or strange behavior found in our engine, BYOND.

.github/workflows/auto_changelog.yml

@@ -15,10 +15,22 @@ jobs:
     steps:
     - name: Checkout
       uses: actions/checkout@v4
+
+    - name: Generate App Token
+      id: app-token-generation
+      uses: actions/create-github-app-token@v1
+      if: env.APP_PRIVATE_KEY != '' && env.APP_ID != ''
+      with:
+        app-id: ${{ secrets.APP_ID }}
+        private-key: ${{ secrets.APP_PRIVATE_KEY }}
+      env:
+        APP_PRIVATE_KEY: ${{ secrets.APP_PRIVATE_KEY }}
+        APP_ID: ${{ secrets.APP_ID }}
+
     - name: Run auto changelog
-      uses: actions/github-script@v6
+      uses: actions/github-script@v7
       with:
         script: |
           const { processAutoChangelog } = await import('${{ github.workspace }}/tools/pull_request_hooks/autoChangelog.js')
           await processAutoChangelog({ github, context })
-        github-token: ${{ secrets.COMFY_ORANGE_PAT || secrets.GITHUB_TOKEN }}
+        github-token: ${{ steps.app-token-generation.outputs.token || secrets.GITHUB_TOKEN }}