Heliodex project update – February 2026

Oh wow, look at the size of this one. Yeah, these posts are most definitely getting longer, to the great detriment of all 0 readers. Grab some of your preferred snack to make this seemingly less boring to read if you so please, and welcome back to the monthly project update!

Mercury

Mercury 3 has 91 user accounts. The number of beta testers is smaller than that but still growing, and other user-generated areas like the Forums and Catalog are of course growing as well.

Recent news includes the migration of the database from SurrealDB v2 to v3 after its recent new release, mainly by following their migration guide, though plenty of manual intervention was required. As such, the Site was down for about 2 hours. The manual steps that were necessary in the migration made me think that there would be some data loss, though this didn't end up being the case. The only remaining fallout was a number of broken pages, which I didn't test after the migration, still being broken due to changes in behaviour and removal of some operators. All reported issues with query errors caused by the database upgrade have now been fixed.

Our free $100 of Microsoft Azure credit, which we got for free from GitHub's Student pack, has finally run out after we were able to stretch it for 5 months on a Standard_D2_v5 spot VM running the Orbiter for Mercury 3's gameservers. However, the same student pack also gave us $200 in DigitalOcean credit. We have no particular preference or favour for any cloud provider, except for ones that give us free credits of course, so we had a great time trying to set up a Windows Server VM on their services. Attempting to load an ISO file wasn't supported, loading a pre-built VDI image kept BSODing, and attempting to extract the ISO manually to the disk wouldn't boot.

Eventually, an alternative solution was found by running the Orbiter on a Linux VM using Wine. A display server also needs to be set up, which Xvfb is being used for, though in future it shouldn't be difficult to switch to something Wayland-based, so the Orbiter was modified to set this up automatically. DigitalOcean offers a few varieties of Linux VMs alongside custom images, though I decided to go for a custom openSUSE MicroOS image instead. I of course use openSUSE Tumbleweed as my main server OS, though I haven't used any immutable distributions previously, and I'm beginning to like it. One of the downsides of using a custom image is that some DigitalOcean features aren't available, most notably IPv6 networking (why?!?!), so I'll probably move the Orbiter to one of their images soon, likely Debian. After a few game sessions, it was ostensibly running fine, though in reality players in-game were experiencing various crashing issues. We upsized the VM from 1GB RAM & 1vCPU to 2GB RAM & 2vCPU, which seems to have alleviated the crashing issues. Task still claims that 2GB RAM is "not gonna cut it", and they're probably right, though we can always scale vertically later. At least we're finally upping the uptime.

The README file in the Mercury Core repository still contains a fair amount of outdated information, so I'm in the process of moving any of its information to the docs if it doesn't already exist there. After this is finished, the README will be cut to about half its current length and simplified to include only a brief overview of the project and links to any relevant resources, such as the documentation. I would like to write some more pages for the docs soon too, especially given that a lot of the current open issues are essentially asking for better documentation on setup of certain components.
Oh, and the Project Polygon FOSS repository was removed from its organisation recently, which is a shame. At least some forks have survived which I will back up and update the links referencing it in the docs. Or I could use one of my surviving copies with commit history...

A recent Mercury News session was also held, not as a voice call as I felt too lazy to do that, but instead as a text-based infodump including a most of the same information as above.

The Mercury Launcher was also improved with a tweaked setup deployment format, moving the binary executable for the Launcher out of the setup package and instead downloading only the one that matches the current system. This worked... once, as the executable originally wasn't being moved into the correct directory, causing the Launcher to remove itself after the first run, and another bug was a failure to install correctly due to being unable to overwrite its own executable while it was running. Fixing these resulted in a neat ~20MB reduction in the setup download size.

After more experiments with the Studio browser, we kept running into the same problems as previously, primarily due to the fact that the modern development environment and processing tools like Vite, Rolldown, and SvelteKit don't work at all in such an old browser. Ages ago, near the end of Mercury 2's development, I tried to fix this with a number of legacy additions and plugins, though these didn't end up working and were never possible to apply to just one area of the site. New errors such as JS event handlers not working correctly and onclick attributes not working by default as Svelte 5 does processing with these. As such, I decided to test an alternative system – splitting off the entire part of the site into a separate service & stack, which I'm calling the Studio Site service.

As the experiment is currently going, the stack is much more lightweight than everything going on in the main part of the Site, sacrificing a lot of development experience for the control we get by rendering HTML pages ourselves. Pages are written in a simple composable system with Go HTML templates (copied from an old Web Design & Development project), though there's no backend functionality yet. Part of the reason I wanted to do the database migration before implementing any backend functionality here was to have parity between the SDKs used by this and the main Site. The new JS SDK supports embedding the database in WebAssembly, which I've attempted and would have liked to do previously, though if we need to access the database from 2 different services then it's probably better to keep the database as its own process.
I probably could have solved this by serving static HTML pages in a different way from an API route in SvelteKit, but I just like building stuff like this and couldn't think of a better solution anyway.

The pain with getting the Site working in the Studio browser also informed our potential plan to move from the 2013 client to 2016. If we go through with this, our plan is to use a client with modified 2016-based tech and 2013 feel, possibly by munging together the 2013 UI with 2016 Corescripts behaviour. If we need to do this, I hope to be able to employ some of Coputer's Luau tools to make the process easier. Using a 2016 client would also eliminate our browser woes, as while the newer client obviously uses a newer browser, it's also easily replaceable with one from the modern day using something like CEF. Others have managed to do plenty of cool things like this with the 2016 client, and while I have no relevant experience I'm still very inspired.
The community reaction from beta testers has been positive so far, and we suspect this will drop off if we expand this news to the wider ORC due to what I percieve as a somewhat common dislike for the fact that the 2016 client is by far the most popular client choice for revivals.

An upcoming Mercury video trailer is still in production, with some scenes taking place in a modified version of the venerable Iron Cafe and with a crowd of beta testers as the cast. I'm not at all involved in its production so can't give much detailed information, though it's been very cool to see how it has been turning out and I hope it will be released eventually.

The new Economy service has received some small updates, notably an actual implementation of stipends. Next up we need to implement a similar API to the previous Economy service and to integrate it with the Site, alongside any other (probably lots of) tweaks we need to make.
Automatic deployment will probably happen eventually. I'd like to do this through PM2 deploy since we're already using PM2 to manage the Site process.
Admin transaction listing, asset comments, and face asset thumbnails all still need to be fixed. I should really get on with those instead of writing screeds like this.

Coputer

The implementation of the new Luau parser experiment, based on 1 existing implementation in Luau as well as the reference implementation, is going pretty well. I ended up finishing about 1/3 of the parser code (mostly just Copilot pausing) before handing it off entirely to Sonnet 4.6, which was surprisingly easily able to extrapolate from the existing code & Luau implementation to finish the rest of the parser. Some modifications needed to be made, including some updates to my lexer to provide some extra data that the parser needs.

After this was working, I added String() methods to every Node type, allowing me to compare to a very similar format used by the previous parser, so I could reuse the same test cases and check for correctness. After the fixes of some generic nil pointer and buffer overflow errors, it parses everything I've thrown at it so far, including the enormous Luauception test, and a lot faster than the previous parser too – going from ~30s to just a couple of seconds for Luauception. The old parser spent a small initial portion running luau-ast and the rest on turning its JSON output into a tree of weird generic structs. The use of these generic structs was because of the need to hold both AST nodes and not-yet-parsed JSON objects. Using the experimental encoding/json/v2 package did speed parsing up, with the same test now taking ~20s, though still not comparable to the new parser.

I'm sure there will still be a number of bugs, differences, and edge cases to catch, such as Luau definition files parsing with luau-ast (and also being supported by the old parser AST), though not with the new parser, so I'll see if there's material available in the official reference implementation I can copy from instead. However, how quickly it's come into a "semi-working" state was still unexpected to me, and I don't have much of an idea on what to use it for now. I'll probably add back a Source() method to each Node type and build a formatter/legacy tranformer, as was done with the old parser, though seeing if I can go about it in a cleverer (more effective) way than basic string building. If there's anything you would like to see done with this or any tools you feel are missing from the broader Luau ecosystem, do tell me as I'd love to hear your suggestions!

Of course, the parser is still just an experiment, and has no clear part in the broader Coputer project yet. However, a while ago the codebase was so fragmented that it was impossible to say that anything had a clear purpose, so I'm not concerned about this at the moment.