Merge branch 'master' into jgrpp

# Conflicts:
#	src/network/network.cpp
#	src/pathfinder/yapf/yapf.h
#	src/pathfinder/yapf/yapf_ship.cpp
#	src/saveload/afterload.cpp
#	src/ship_cmd.cpp
#	src/station_cmd.cpp
#	src/vehicle.cpp
#	src/vehicle_gui.cpp

docs/desync.md

@@ -195,10 +195,11 @@ Last updated: 2014-02-23
      'src/network/network_func.h'.
      (DEBUG_FAILED_DUMP_COMMANDS is explained later)
    - Put the 'commands-out.log' into the root save folder, and rename
-      it to 'commands.log'.
-   - Run 'openttd -D -d desync=3 -g startsavegame.sav'.
-     This replays the server log and creates new 'commands-out.log'
-     and 'dmp_cmds_*.sav' in your autosave folder.
+      it to 'commands.log'. Strip everything and including the "newgame"
+      entry from the log.
+   - Run 'openttd -D -d desync=0 -g startsavegame.sav'.
+     This replays the server log. Use "-d desync=3" to also create a
+     new 'commands-out.log' and 'dmp_cmds_*.sav' in your autosave folder.
 
 ## 3.2) Evaluation of the replay
 
@@ -226,7 +227,7 @@ Last updated: 2014-02-23
   savegames with your own ones from the replay. You can also comment/disable
   the 'NOT_REACHED' mentioned above, to get another 'dmp_cmds_*.sav' from
   the replay after the mismatch has already been detected.
-  See Section 3.2 on how to compare savegames.
+  See Section 3.3 on how to compare savegames.
   If the saves differ you have located the Desync between the last dmp_cmds
   that match and the first one that does not. The difference of the saves
   may point you in the direction of what causes it.
@@ -252,16 +253,14 @@ Last updated: 2014-02-23
      are replayed. Their internal state will thus not change in the
      replay and will differ.
 
-  To compare savegame more semantically, there exist some ugly hackish
-  tools at:
-     http://devs.openttd.org/~frosch/texts/zpipe.c
-     http://devs.openttd.org/~frosch/texts/printhunk.c
+  To compare savegame more semantically, easiest is to first export them
+  to a JSON format with for example:
 
-  The first one decompresses OpenTTD savegames. The second one creates
-  a textual representation of an uncompressed savegame, by parsing hunks
-  and arrays and such. With both tools you need to be a bit careful
-  since they work on stdin and stdout, which may not deal well with
-  binary data.
+  https://github.com/TrueBrain/OpenTTD-savegame-reader
 
-  If you have the textual representation of the savegames, you can
-  compare them with regular diff tools.
+  By running:
+
+  python -m savegame_reader --export-json dmp_cmds_NNN.sav | jq . > NNN.json
+
+  Now you can use any (JSON) diff tool to compare the two savegames in a
+  somewhat human readable way.

docs/releasing_openttd.md

@@ -29,20 +29,25 @@ This guide is for OpenTTD developers/maintainers, to release a new version of Op
 
 1. Go to https://github.com/OpenTTD/website/new/main/_posts and write a new announcement post. See a [previous example](https://github.com/OpenTTD/website/pull/238) for a template.
 2. Create a new branch for this post and open a PR for it.
-3. Write announcement text for socials like Forum/Discord/Twitter/Reddit and include it in the PR.
+3. Write announcement text for the store pages and socials like TT-Forums / Discord / Twitter / Reddit / Fosstodon / etc., and include it in the PR.
 4. Create a Steam news image for that post and include it in the PR.
-5. Check the website post (preview link via checks page) and make corrections. We usually just use the GitHub web interface for this and squash the result later.
+5. Check the website post ("View Deployment" link) and make corrections. We usually just use the GitHub web interface for this and squash the result later.
 6. Get this PR approved, but do not merge yet.
 
 ## Step 3: Make the actual OpenTTD release
 
-1. Go to https://github.com/OpenTTD/OpenTTD/releases/new and create a new tag matching the release number. For the body of the release, see any older release. "Set as a pre-release" for a beta or RC, set as latest for a real release.
-2. Merge website PR.
-3. Wait for the OpenTTD release checks to be complete.
-4. Check that website links to the new release are working and correct, using the [staging website](https://www-staging.openttd.org/).
-5. If this is a full release, ask orudge to update the Microsoft Store and TrueBrain to move the release from the "testing" to "default" branch on Steam.
+1. Go to https://github.com/OpenTTD/OpenTTD/releases/new and create a new tag matching the release number. For the body of the release, copy in the changelog. "Set as a pre-release" for a beta or RC.
+2. Wait for the OpenTTD release workflow to be complete.
+3. Merge the website PR. This will publish the release post.
+4. If this is a full release:
+   * for `Steam`: under Steamworks -> SteamPipe -> Builds, set the "testing" branch live on the "default" branch. This will request 2FA validation.
+   * for `GOG`: under Builds, "Publish" the freshly uploaded builds to `Master`, `GOG-use only` and `Testing`.
+   * for `Microsoft Store`: ask orudge to publish the new release.
+
+Access to `Steam`, `GOG` and/or `Microsoft Store` requires a developer account on that platform.
+You will need access to the shared keystore in order to create such an account.
+For help and/or access to either or both, please contact TrueBrain.
 
 ## Step 4: Tell the world
 
-1. Tag and create a website release to trigger the actions that update the website.
-2. After the website is live, make announcements on social media. You may need to coordinate with other developers who can make posts on Twitter, Reddit, Steam, and GOG.
+1. Make announcements on social media and store pages. You may need to coordinate with other developers who can make posts on TT-Forums, Twitter, Reddit, Fosstodon, Discord, Steam, GOG, Microsoft Store, etc.