Heliodex project update – June 2026

Hello again all! I hope that all that you've been working on has been going well over the past month. Here's the stuff I was working on throughout June.

Mercury

A request was recently issued for inactive beta testers to submit their reasons for inactivity, and as a result, a number of people were removed from the beta tester programmes. No new beta testers were accepted over the past month. More beta testers may be removed on 15 July based on their contributions to the upcoming event. However, on the whole, the rest of the community is still more active in the project than I am.

Speaking of which, Mercury's event teams are hard at work on creating parts of the trailer. My team, the filming team, is probably the least busy at the moment, though we filmed a transition with falling bricks that could be used at some point or revised later. My team will likely be more active when more tasks are issued.

A poll was set up to find out which possible trailer sections would be most popular. 153 votes were received (participants could cast many votes and for multiple options). After voting closed, beta tester leads were selected for the building and writing teams. These aren't to be confused with the existing administrator leads, as the difference is... honestly I'm not quite sure. Anyway.

The Studio Site service has restarted development, since I finally figured out what was wrong with the database queries for the login page: the type I was casting them to was correct though didn't have correct JSON encoding labels, so the data was being discarded and a default-equivalent value returned instead. Logins now work, so next step is to implement a view of user places for the homepage, and loading assets for a Toolbox-like system. There's an associated issue (#455) and draft pull request (#456) for these changes.

The server hosting the Orbiter has been upsized, from 2 vCPUs / 2 GB RAM 60 GB disk to 4 vCPUs / 8 GB RAM / 160 GB disk. This should seriously help with the performance and stability issues with gameservers. The reason this change was made is because DigitalOcean is expiring our remaining free credits at the end of July, so we'd like to spend all of them before then. Still not bare metal raw hardware, though the situation is better for now. We still have about $40 in credits left over which we can't use, so let me know if you need anything hosted in the next few weeks. We will figure out somewhere new to host the gameserver once the credits expire.

The substitution file format has been updated to support multiple substitutions of the same value if the same name appears multiple times in the template. It was initially supposed to do this, I just overlooked it during implementation. Tests have been updated to match.

tracker

I've put projects in monthly updates that have had less work put into them. Whatever, this is a tool that parses a text-based music format and transforms it into Extended Module (XM) tracker music files. Or rather it will use the text-based format to modify an existing XM file. My reasoning behind this is that, while music trackers are convenient for humans to use, I'd like to see if LLMs can make music, just as an experiment.

Dex Display

My font now features glyphs for the Zbalermorna script on top of the original basic Latin. Consonant, semivowel, and single vowel glyphs are complete, however the tone, length, & emphasis symbols need their metrics and kerning tweaked, and combining characters including diphthongs, attitudinal shorthand, and multiple stress marks are not yet implemented.

Once I get the above working properly then I might make a write-up or blog post or something on how I accomplished it, because it's been an interesting and eventful journey and one that I don't see much similar documentation on.

Coputer

Ah, Coputer. Since when I started Litecode in October 2024, it worked with Luau VM bytecode version 6. Up until the last time I touched the bytecode VM, this didn't change. Since then, Luau has released 5 more bytecode versions, with the current version being 11. These updates meant that Litecode needed some changes to be able to deserialise the new format, which I was able to implement. There have also been some additions to the standard library, which shouldn't be to difficult to implement. The bigger problem is the new instructions and opcodes.

The implementation I was using mainly for reference, Fiu, has not yet been updated to support newer bytecode versions than version 6. Of course, the reference implementation isn't really an option since I can't read nor have the desire to learn C++, so my porting efforts have been rather full of mistakes which I can't find.

Since the reference implementation is written mainly for performance and Litecode is written mainly for readability (following on from Fiu), there's a lot of differences when porting that are difficult to reconcile. At the moment I'm working again on getting the conformance test suite passing incrementally, with careful logging and debugging along the way. Luau code using newer compiler versions outputs the new opcodes in its bytecode, regardless of whether any new features are used. After the test suite passes, we can try implementing the newer VM types for integers, classes, etc and adding respective tests for those, and also the new Cyclic requires.

Another decently up-to-date implementation is luaur which, while being an unbelievably impressive project, has the same problems for using it as a reference as the reference implementation does (that seems a little confusing. Should I just say "original implementation" instead?) given that it attempts to match very closely with the reference implementation.

I'll see what I can do and if I can get more of the tests passing on a current Luau version. Keeping the (future, hopefully) ecosystem stuck on a legacy version of Luau certainly isn't something I want to do.

I've been thinking of adding screenshots or other image media to some of my repositories, even some old ones where there aren't any visual indicators of what the project looks like, and especially for projects like Mercury Core where you would have to go through the arduous setup process to see what the website actually looks like after logging in.

Hey, do you remember nostaking? It was a notetaking application I was working on that would store and display notes in a hierarchical format. It used columns to display notes, with the root nodes on the left and scrolling to children when parents were selected. It also planned to link with nostr, which is where the project name comes from. It was a cool concept and matched the way my brain worked quite a bit better than a linear document or folder of markdown files (I used to commonly take huge hierarchical trees of notes. i ought to add some of my other notes to that site too), though it's just not cut out for the agentic era. I don't know, I've just been thinking about taking more notes and I'll probably try a few existing open source solutions.

I was messing around with my Meteorite fork to see if I could get it to start with all the dependency updates that Dependabot has done to it. I did a little bit of code cleanup and removed some of the error messages, though not many.

I was also playing with Gleam, and made a simple demo of frontend compiling to JS and backend compiling to BEAM. What would really make this cool is a type-safe communication system between the 2, though I'm not experienced enough in Gleam to know how to write that.

Okay, that's pretty much everything I did this month. Thanks for reading as always, and hope you have a brilliant July!