Mercury Used AI

The site has been released to Mercury's beta testers! We now have maybe 25-30 accounts on site, all creating places, assets, forum & status posts, comments, groups etc, and discovering plenty of interesting bugs!

Avatars now have their images displayed correctly as well, as we have RCCService set up correctly, which the attached image shows some examples of in user avatars on a locally hosted version. This handles rendering of avatars, uploaded models, clothing accessories, and perhaps place thumbnails in the future as well. RCCService had some trouble running performantly on the site's VPS, so was moved to running on my own dedicated server, running under Wine on OpenSUSE. This was a pretty interesting process as well, as RCC requires a display server to run correctly, so can't run properly in a standard SSH environment. It ends up working really well and providing decently fast renders too! (I'm not sure if this is using hardware acceleration)

A small list of bugs to be fixed are as follows:
- Renders for shirt assets currently don't show the shirt correctly
- Creating randomised invite keys mistakenly sees the creation form as not fully submitted
- The result of the aforementioned form error (400) causes a new error (500) due to the form error function not working correctly
- Groups with a / (or other URL-unsafe characters) in their name get an invalid link as a result of the group name being in the URL (fixed, though not yet deployed)

The site was inaccessible for a short time due to issues with hosting. It is currently on a Windows VPS, and we're considering moving to the same dedicated server that RCCService is running on.

More asset-related improvements have been made, including assets now loading from Roblox's API, via Open Cloud, from Mercury user-uploaded assets, and from administrator-managed privileged assets.

The attached image shows the code changed for serving assets. We had a few issues with this, with a few particular types of asset: scripts, meshes, images, and XML.
- Script assets are already signed at compile time, so don't need to be modified, and meshes don't need to be either. These are text formats, so will be fine if they need to be re-encoded.
- XML assets need to have Roblox URLs in them replaced with the Mercury equivalents.
- Images must go through unchanged, as re-encoding a binary image format as text (UTF-8) will corrupt it.
Basically this all means we have to guess what type the asset is when loading it. If it begins with <roblox, it's probably XML, and this works well enough for our use cases.
Loadscripts are now instead signed at runtime, as parts of the script need to be replaced on-the-fly (for example, the API URLs that a hosted game server needs to access, or a user's username when joining a game).

The change of place and asset IDs to integers instead of strings caused some unforseen complications, and areas of code for loading icons/thumbnails/loadscripts etc all had to be changed to account for this, as well as the Economy service. All of these changes are still on Mercury Core's assets branch for the time being.

A number of issues with loading corescripts were encountered, so we spent a lot of time designing potential new solutions for loading them, even discussing bundling them all into the game client. However, we eventually found the issue was due to bad signatures at the top of each file: they must sign the entire file, but also including the file's asset ID. Fixing this, all corescripts now load correctly into the client, allowing us to get the first real hosted games running for the upcoming Mercury 3 beta release!

A number of improvements have been made to the way assets are loaded on Mercury. Firstly, assets loaded with hardcoded IDs, IDs entirely controlled by scripts served to the client, and these assets' dependencies (all of which we're calling privileged assets) will now be archived alongside the corescripts in the tp-link-extender/2013 repository, instead of needing to be uploaded through the site, which incurs complications with the database and is tedious whenever it needs to be reset.

The Luau script for compiling the corescripts has been rewritten as a Go tool for bundling these alongside libraries, loadscripts, and archived privileged assets. Signing of corescripts and loadscripts is now done at compile time instead of when they're served, simplifying site code and reducing load.

Modifications have also been made to the client's DLL hook, allowing assets to be correctly loaded from the endpoint at xtcy.dev. In the near future we'll need to be able to back up and handle more categories of assets, including those loaded and cached from Roblox's API, so we're still mapping out potential solutions for these.

2 large pull requests have been merged into Mercury Core: improved service process management (#400, https://github.com/tp-link-extender/MercuryCore/issues/400), and better runtime type checking (#401, https://github.com/tp-link-extender/MercuryCore/pull/401).

The first pull request improves the ease of use for users to start up the Database and Economy services by spawning them directly and as needed when the site is running. This means there's no longer any need to use complex and inconsistent container managers or cumbersome management of terminals for each service. I tried out several possible solutions to this problem and this one seemed the lowest friction and most ergonomic.

The second pull request fixes runtime schema validation errors for forms across the site, as well as Typescript type errors caused by trying to get around these errors. I ended up replacing the Zod library with ArkType for validation, as it reduces some incompatibilities with other dependencies.

More work has been done on the upcoming documentation site for Mercury. This will encompass more in-depth setup guides than currently in the README, installation guides for tools needed for development and production, and common usage patterns in integration with larger projects.
The documentation site is built with Astro + Starlight. As I had previously used Astro I found the documentation to be pleasant and easy to build, and trivial to style with the Mercury Core colour scheme and design. Implementing the documentation directly into Mercury Core was also considered, though this would mean that users would have to set up the system correctly before being able to see the guides on how to set it up.