tp-link-extender · Heliodex · Apr 23, 2026 · Mar 19, 2026 · Mar 25, 2026 · Mar 25, 2026
diff --git a/Docs/bun.lock b/Docs/bun.lock
diff --git a/Docs/package.json b/Docs/package.json
@@ -10,13 +10,13 @@
 		"astro": "bun x -b astro"
 	},
 	"devDependencies": {
-		"@biomejs/biome": "^2.4.6"
+		"@biomejs/biome": "^2.4.10"
 	},
 	"dependencies": {
-		"@astrojs/markdoc": "^1.0.0",
-		"@astrojs/starlight": "^0.38.1",
+		"@astrojs/markdoc": "^1.0.3",
+		"@astrojs/starlight": "^0.38.2",
 		"@astrojs/starlight-markdoc": "^0.6.0",
-		"astro": "^6.0.3",
+		"astro": "^6.1.3",
 		"sharp": "^0.34.5"
 	}
 }
diff --git a/Docs/src/content/docs/architecture/launchers.md b/Docs/src/content/docs/architecture/launchers.md
@@ -0,0 +1,26 @@
+---
+title: Revival platform types
+description: Comparison of 2 popular types of revival platforms, launcher-based and web-based.
+---
+
+Mercury Core is a foundation for building web-based revival platforms. These are platforms where services external to the Client, such as place launching and character customisation, are accessed via a hosted website. This is in contrast to launcher-based platforms, where a custom launcher application is used to join places and customise characters. This page provides an overview of the differences between these 2 types of platforms, and whether the web-based approach of Mercury Core is suitable for certain use cases.
+
+## Launchers
+
+Launchers are still necessary for both types of platforms, as they are used to launch the Client application, and in the case of a web-based platform, to interact with the site and download a Client. Conversely, a web-based platform is not necessarily required for a launcher-based platform, as the launcher could come pre-bundled with a Client and Studio, as well as possibly its own API server for interacting with the Client. However, sometimes these launchers have web API servers that are used for downloading Client updates and other features.
+
+The difference is mainly where the functionality is accessed from, the centralisation or decentralisation of service hosting & access, and the development & usage focus on either the website or the launcher. Both types of platforms have their own advantages and disadvantages, users may have strong preferences of one over another, and the choice between them depends on the specific use case, goals, and user base of the platform being developed.
+
+There do exist web-based platforms that do not need a separate launcher, most commonly by compiling 2016 Client source code to WebAssembly, allowing it to run in the browser. However, this approach is not very common, and has its own set of challenges and limitations. These include performance issues and modification requirements, with certain unsupported libraries needing to be substituted for compatible alternatives.
+
+## Distinction
+
+Generally, the distinction is broader than simply the type of application where the services are accessed from. Web-based platforms tend to host centralised features on the website alongside their main services, such as a marketplace & economy, features & communication, and discoverability, whereas launcher-based platforms typically have more decentralised place joining and local character customisation systems, allowing the user to choose for themselves where to connect to places and what accessories to use with their avatar.
+
+Launcher-based platforms also usually have a launcher more closely integrated with the Client and more often depend on users hosting their own places rather than using centralised dedicated hosting. However, this can mean that game discoverability suffers due to lack of place listings. Multiplayer experiences using launcher-based platforms generally revolve around external communication platforms to organise place hosting and joining. This also happens for small web-based platforms with few users hosting places at a time, though this tends to be less of an issue for larger web-based platforms with more users hosting places at a time, as they can display more active place listings and better discoverability.
+
+## Related experiments
+
+Previous Mercury experiments, including [Mercury Core for Launcher Revivals](https://github.com/tp-link-extender/MCLauncherRevivals), aimed to tackle the launcher platform server discoverability problem by hosting a decentralised list of active servers, for various different launchers, on the website. Anyone would be able to host their own version of the list and see the same servers, with an ability to rate servers and join currently active ones. However, this approach offered no further economy or social features, and is not actively being developed.
+
+[Reblox](https://github.com/Heliodex/Reblox) was one of several attempts at building a hybrid platform, with a single launcher, or multiple implementations of such, that could each connect to multiple different servers. Each server would have only hosted a standardised API for communicating with the launcher, and the launcher would have handled all interactions with the Client. Users would have been able to transfer their identity across multiple platforms, preventing inaccessibility of user accounts due to platform shutdowns. Places could have been hosted on any server, and have their discoverability across many servers. This approach would have offered more of the advantages of both types of platforms, also featuring plenty of social features, though at a much higher development cost than an approach like Mercury Core for Launcher Revivals due to lack of interoperability with existing launcher-based platforms. However, an implementation of an engaging marketplace or economic system would have been difficult or not possible, and the project is also not in development anymore.
diff --git a/Docs/src/content/docs/design/mercury3.md b/Docs/src/content/docs/design/mercury3.md
@@ -13,8 +13,8 @@ Mercury 2 changed a significant amount during its 2 years of development. Many c
 
 ## Development of Mercury 3
 
-The development process of Mercury 3 has been very different to that of Mercury 2.
+The development process of Mercury 3 has been very different to that of Mercury 2. Originally, Mercury 3 was planned to be a fork of Mercury Core with improvements being backported to Mercury Core when possible. However, an alternative development process was found to be easier and chosen instead, where Mercury 3 is simply a hosted version of Mercury Core with no modifications. If you are interested more in the revival platform than the source code, Mercury Core can be seen as the "testing ground" for Mercury 3. If you are interested more in the source code than the revival platform, Mercury 3 can be seen as the "testing ground" for Mercury Core. Different Mercury 3 developers see the relationship differently.
 
-todo
+The existence and testing of Mercury 3 helps with the development of Mercury Core, as it allows for testing of new features and changes in a real-world environment. Before Mercury 3, Mercury Core was only tested in development environments, which were not as effective at finding bugs and issues as a production environment would be.
 
 [^1]: These changes can be viewed in full, with code change history throughout the entirety of Mercury 2, in Mercury Core's [commit history](https://github.com/tp-link-extender/MercuryCore/commits/).
diff --git a/Docs/src/content/docs/guides/config.mdoc b/Docs/src/content/docs/guides/config.mdoc
@@ -61,7 +61,7 @@ An array that contains the optional pages for the site, with a string value for
 
 Whether to automatically start the database server when starting the Site. Requires that [SurrealDB](/install/surrealdb) is installed and available on the command line or in your system's PATH as `surreal`.
 
-This is recommended to be enabled in all cases except when debugging database issues, or when managing the database server separately from the Site, surch as when using a container manager.
+This is recommended to be enabled in all cases except when debugging database issues, or when managing the database server separately from the Site, such as when using a container manager.
 
 #### Database &ndash; Domain
 

diff --git a/Docs/src/content/docs/history.md b/Docs/src/content/docs/history.md
@@ -21,7 +21,7 @@ Krypton was a revival platform developed in late 2020 and early 2021, built upon
 
 The first version of Mercury started development as a rebranding and improvement of the Krypton codebase in May 2021, and was hosted at [banland.xyz (archive link)](https://web.archive.org/web/20210803231644/https://banland.xyz/). Mercury 1 used the late 2013 Client and Studio.
 
-Mercury 1 peaked at around 300 users before it shut down in September 2021 and merged with Project Polygon. A [functional archive](https://files.heliodex.cf/mercury-website.zip)[^2] of the original Mercury 1 website is available.
+Mercury 1 peaked at around 300 users before it shut down on 21 September 2021 and merged with Project Polygon. A [functional archive](https://files.heliodex.cf/mercury-website.zip)[^2] of the original Mercury 1 website is available.
 
 ## Krypton X
 
@@ -61,7 +61,7 @@ Mercury 2 moved to the domain [mercury2.com (archive link)](https://web.archive.
 
 Mercury then went on a short development hiatus and returned in mid-May with more fixes for database functions, and more attempts at making client integration work through a DLL hook, with plans to soon integrate a basic anti-cheat system. Users continued to be accepted onto the site at a slower rate. Through the start of June, some experiments were made with an updated economy system and various other updates on the site, while further progress on the DLL hook remained slow and difficult to advance.
 
-Eventually, it was decided that DLL hooking was not feasible, and with no good way to connect the Client and Studio to the rest of the platform, it was decided to [shut down Mercury 2](https://web.archive.org/web/20250622030340/http://mercury2.com/) on 22 June 2024. At the time of shutdown, Mercury 2 had just over 150 registered users.
+Eventually, it was decided that DLL hooking was not feasible, and with no good way to connect the Client and Studio to the rest of the platform, it was decided to [shut down Mercury 2](https://web.archive.org/web/20250331074009/https://mercury2.com/) on 22 June 2024. At the time of shutdown, Mercury 2 had just over 150 registered users.
 
 Some of Mercury 2's related projects were already available as open source, such as [melt](https://github.com/Heliodex/melt). Many other components, including the Setup deployer, 2013 scripts and tools, RCCService proxy, application settings JSON, and Discord bot were all made available as well.
 
@@ -81,6 +81,6 @@ On 6 September 2024, Mercury Core was officially made public with an announcemen
 
 [^1]: The Project Polygon FOSS source code listed at this link differs slightly from the version used to develop Mercury 1 and is missing the commit history.
 
-[^2]: This archive includes Git history for changes made to Mercury 1. Changes made to the Project Polygon codebase before it was used to develop Mercury 1 are not included.
+[^2]: This archive includes Git history for changes made to Mercury 1 as far back as 27 July 2021. Changes made to the Project Polygon codebase before it was used to develop Mercury 1 are not included.
 
 [^3]: This led to the misconception that Mercury Core had been open source from the beginning of Mercury 2 development, which is not the case.
diff --git a/Docs/src/content/docs/install/bun.md b/Docs/src/content/docs/install/bun.md
@@ -3,7 +3,7 @@ title: Bun
 description: Details on how to install Bun.
 ---
 
-[Bun](https://bun.sh) is a Javascript runtime used for running the Site service, and facilitates management and installation of dependencies. At the time of writing, the latest version is [**v1.3.10**](https://bun.com/blog/bun-v1.3.10).
+[Bun](https://bun.sh) is a Javascript runtime used for running the Site service, and facilitates management and installation of dependencies. At the time of writing, the latest version is [**v1.3.11**](https://bun.com/blog/bun-v1.3.11).
 
 Check out the [installation guide](https://bun.com/docs/installation) for detailed instructions, or install the latest version on Linux or macOS with the following shell command:
 

diff --git a/Docs/src/content/docs/install/docker.md b/Docs/src/content/docs/install/docker.md
@@ -11,4 +11,4 @@ After installation, Docker should be available from the command line with `docke
 
 ## Virtualisation
 
-Docker requires a virtualisation system to be enabled on your machine to run. This usually means enabling virtualization in your motherboard's UEFI/BIOS settings. Depending on your CPU, this may be called VT-x (Intel) or SVM (AMD), or something else, sometimes found under advanced CPU or security settings.
+Docker requires a virtualisation system to be enabled on your machine to run. This usually means enabling virtualization in your motherboard's UEFI/BIOS settings. Depending on your CPU model/manufacturer, this may be called VT-x (Intel), SVM (AMD), or something else, sometimes found under advanced CPU or security settings.
diff --git a/Docs/src/content/docs/install/go.md b/Docs/src/content/docs/install/go.md
@@ -14,7 +14,7 @@ To upgrade Go to the latest version without going through the reinstallation pro
 ```
 module whatever
 
-go 1.26.0
+go 1.26.1
 ```
 
 Upon the next build or run command, Go will automatically download and use the specified version. However, changing the Go version in a **go.mod** file may prevent older versions of Go from building the project, even if newer features aren't used, which could be required if an older Go version is required to work with an older system or CPU architecture. If you run into any issues with Go versions, please file an issue on the [GitHub repository](https://github.com/tp-link-extender/MercuryCore/issues) so we can help out.

diff --git a/Docs/src/content/docs/install/surrealdb.md b/Docs/src/content/docs/install/surrealdb.md
@@ -3,7 +3,7 @@ title: SurrealDB
 description: Details on how to install SurrealDB.
 ---
 
-[SurrealDB](https://surrealdb.com) is a multi-model database that combines the flexibility of document databases with the power of graph databases. It is used as the main data storage mechanism for Mercury Core. At the time of writing, the latest version is [**v3.0.3**](https://github.com/surrealdb/surrealdb/releases/tag/v3.0.3).
+[SurrealDB](https://surrealdb.com) is a multi-model database that combines the flexibility of document databases with the power of graph databases. It is used as the main data storage mechanism for Mercury Core. At the time of writing, the latest version is [**v3.0.5**](https://github.com/surrealdb/surrealdb/releases/tag/v3.0.5).
 
 Check out the [installation guide](https://surrealdb.com/docs/surrealdb/installation) for detailed instructions, or install the latest version on Linux or macOS with the following shell command:
 

diff --git a/Docs/src/content/docs/services/launcher.md b/Docs/src/content/docs/services/launcher.md
@@ -5,7 +5,7 @@ description: Information about the Lanucher, the application responsible for sta
 
 This page provides information about the Mercury Launcher, responsible for downloading, installing, and unpacking Setup deployment packages. It also registers itself with the operating system to handle file associations, and should open when any place is joined from the Site, then launching the Client. An implementation of the Launcher is available at the [tp-link-extender/MercuryLauncher](https://github.com/tp-link-extender/MercuryLauncher) repository.
 
-With the modularity of the Mercury Suite, it is not required to use this implementation of the Launcher alongside Mercury Core, and a custom implementation or other launcher can be used instead. However, the custom Setup deployment format is designed to be used with the Launcher, and isn't compatible with the 'standard' deployment format. 
+With the modularity of the Mercury Suite, it is not required to use this implementation of the Launcher alongside Mercury Core, and a custom implementation or other launcher can be used instead. However, the custom Setup deployment format is designed to be used with the Launcher, and isn't compatible with the 'standard' deployment format.
 
 ## Configuration
 

diff --git a/Docs/src/content/docs/services/orbiter.mdoc b/Docs/src/content/docs/services/orbiter.mdoc
@@ -24,7 +24,7 @@ GAMESERVER_KEY=password
 
 The process for starting a gameserver with the Orbiter is very similar to that of manually starting a selfhosted gameserver. Gameservers are simply Studio sessions that are started with a Host/Serve loadscript, which starts a network server on a specific port and listens for incoming player connections. The gameserver will load a specific place, and if the server's port is forwarded correctly, players can connect to the server with their Clients and play the game. The Serve loadscript, a similar version of the Host loadscript which runs in dedicated servers, includes a few functions that run periodically for server upkeep, including checking for inactive players to shut down the server once it has been empty for a certain amount of time.
 
-Mercury Core includes [configuration options](https://github.com/tp-link-extender/MercuryCore/blob/main/mercury.core.ts#L81-L83) for declaring whether selfhosted or dedicated servers should be used. When using dedicated servers, the Orbiter service is used to manage the gameserver instances, and the Orbiter is given special permissions to carry out required operations, for example getting place files in order to load them. When using selfhosted servers, gameservers are started manually by the server owner, and the Orbiter is not used.
+Mercury Core includes [configuration options](https://github.com/tp-link-extender/MercuryCore/blob/main/mercury.core.ts#L94-L96) for declaring whether selfhosted or dedicated servers should be used. When using dedicated servers, the Orbiter service is used to manage the gameserver instances, and the Orbiter is given special permissions to carry out required operations, for example getting place files in order to load them. When using selfhosted servers, gameservers are started manually by the server owner, and the Orbiter is not used.
 
 {% aside type="tip" title="Gameserver trust" %}
 	In the near future, Mercury Core will include support for gameservers to access certain API routes to enable ingame features such as friending/following other users and chat history. This will only be possible when using dedicated servers with the Orbiter, as selfhosted servers cannot be trusted to send legitimate requests.

diff --git a/Site/Caddyfile b/Site/Caddyfile
@@ -1,4 +1,6 @@
-mercs.dev {
+# www. is the insecure HTTP version, not to be accessed via the browser
+
+mercs.dev, http://www.mercs.dev  {
 	rewrite /Asset /asset
 	rewrite /Asset/ /asset
 	rewrite /Asset/Default.ashx /asset
@@ -21,8 +23,3 @@ mercs.dev {
 
 	reverse_proxy localhost:4443
 }
-
-# Insecure HTTP version, not to be accessed via the browser
-http://www.mercs.dev {
-	reverse_proxy localhost:4443
-}
Original file line number	Diff line number	Diff line change
Expand Up		@@ -11,4 +11,4 @@ After installation, Docker should be available from the command line with `docke

		## Virtualisation

		Docker requires a virtualisation system to be enabled on your machine to run. This usually means enabling virtualization in your motherboard's UEFI/BIOS settings. Depending on your CPU, this may be called VT-x (Intel) or SVM (AMD), or something else, sometimes found under advanced CPU or security settings.
		Docker requires a virtualisation system to be enabled on your machine to run. This usually means enabling virtualization in your motherboard's UEFI/BIOS settings. Depending on your CPU model/manufacturer, this may be called VT-x (Intel), SVM (AMD), or something else, sometimes found under advanced CPU or security settings.