Tiazzz

Since I started this a small while before uploading it to GitHub and Flavortown, here’s what I did:

1. I made a fresh Vite project with nothing in it
2. I made a small website start with Bootstrap SCC
3. Procrastination
4. I improved the website:

• Added a header
• Improved the NavBar
• Added OpenGraph support
  I made it run on GitHub Pages using the simple Vite Static Websites Actions Workflow and it’s all available at https://hermes.tiazzz.me

Next up I wanna make rehearsal Cards with Bootstrap, and add a progress/blog-esque page to share our progress on the project!

I guess I should have learnt from my mistakes, because I am once again an hour further, because of a shitton of issues that appeared in prod. I made the mistake (again) of uploading the version before thoroughly testing everything, but this time I’m certain everything is fixed! So v2.0.2 is the FINAL ship-ready version!

(And hey, the uploads in the image attached were automatically uploaded using GitHub Actions!)

EVEN more preparations… And an accidental hotfix.

When getting ready to ship the project, I already uploaded the mod to Modrinth as v2.0.0. However, when I tried testing it on a prod server, everything broke… Turns out, I wasn’t including all the dependencies of the dependencies (transitive dependencies) in the final jar, which is a problem, because obviously we still need them during runtime. I fixed this by modifying some stuff in my build script and whatnot, which came with even more issues.

Firstly, I needed to publish kamera and krapher to the local Maven repo in order to access it for automatic transitive inclusion. Then, I had to make it so certain libraries that need a higher version than Minecraft provides (such as ICU4J and Netty) also get included regardless of the fact that Minecraft has them anyway.

After this, I decided to take another shot at making mod publish work, and I’m quite confident it’ll work now! Only one way to find out…

As even more final preparations for the release of the mod, I set up a documentation page with Vitepress. I love using Vitepress for documentation, I used MkDocs in the past, but Vitepress looks much more modern.

You can check it out at https://docs.tiazzz.me/Khat. I had a few problems with GitHub Actions and whatnot, and for some reason npm did not generate a package-lock.json, which was apparently a problem.

In this devlog, there’s some preparations for the release of the mod. I made the Gradle configuration build the files based on some factors:
Firstly, the project is now split into three “functionalities”: Webhooks only, with mRpc, and full.
Secondly, the project is then split into the three LTS versions: 1.20.1, 1.21.1 and 1.21.11.
Then, for every build, we put the archive files into per-mc-version directories in the root builds/libs directory. (See attachments)

This makes uploading the mod jars substantially easier for me, because they’re ordered as how I would release the features on Modrinth and GitHub. I tried setting up Modmuss’ publishMods plugin thing, but I had a lot of issues due to the fact it applies it to every Stonecutter node (version). I wanted it to grab the directories from that build directory and upload all the artefacts in there as one version on Modrinth and GitHub. But there’s no way I can make it run once, while also retaining info like the title and versions without making it super scuffed.

I opt to just post the new versions myself instead. This also ensures I don’t accidentally mess something up when automating it.

Apart from that, applying the whole Stonecutter magic brought with it that I had to implement yet again, more comment logic. I made use of the constants feature because it was the easiest way for me to check in the comments with version of the functionality we’re working with. And guess what! It works very nicely.

I added a bot mode to the mod. You can now, alongside the kRpc server, run a bot made with KordEx. It has functionality that integrates with the various services in respective extensions.

• ChatExtension, checks a channel to send messages via the ChatService;
• CommandExtension, allows users to run commands via the CommandService;
• LinkingExtension, lets users link their Minecraft account via the LinkService;
• LookupExtension, lets you look up Minecraft accounts by UUID, usernames and, if they’re linked, Discord account;
• MiscExtension, which adds functionality like updating the status of the server and renaming people to follow a strict pattern you can set.

Alongside this, I updated my client classes for Kamera to be a little more robust and have a very simple built-in API, the KameraClient. I made the testing one use this as well because using two while loops is probably not very good.

I’ve tried to add a KordEx bot to my mods before, in CTD, but I always had hassles due to it not working very well with Java and all sorts of stuff, alongside the Gradle Plugin being unreliable in multiproject layouts in which it is not the root project. However, I opted to start with a clean slate and just add the basic dependencies and implementations needed for a KordEx bot, and it works nicely!

Something I want to work out and integrate into my Gradle workflow is publishing multiple jars for webhooks, kRpc and kRpc + the bot.

I fixed a few issues relating to the fact Minecraft changed permission logic in 1.21.11, which I forgot about.

Luckily, Stonecutter came in clutch yet again, I was able to very easily add a new version and add the required checks for commands. I also had to change the mRpc command source a little bit, but once again, very easy due to Stonecutter.

I tried to do some shenanigans with branches in Stonecutter to make the JVM version of Kamera (the kRpc model) change on a per-version basis, but that does not work out because it should be a global library. I’m opting to just release everything as Java 21.

I added the ChatService, which allows you to send chat messages via the kRPC server. One issue I’m having with it though, is that Minecraft Components are for some reason hell to work with when it comes to styling them, although for now it’s fine.

I fixed up some of the CommandService stuff and made it more robust by, instead of using the server’s Rcon implementation, using my own implementation of a brigadier CommandSource.

Finally, I made the LinkService also actually work, because now it can use a database and I somehow managed to mess up how registering commands worked, so I fixed that too!

I now want to improve the services more, maybe add some extra, and maybe separate releases into including:

• Just the webhook part
• Ditto + the kRpc server
• Ditto + a VERY simple bot

Fixed a small thing where the execute form and webhook URL would be printed.

You can now set verbose to true in the webhook builder to enable the logging of these values and a few more. This is disabled by default. It also logs the queries and whether files were added.

Alongside this, I switched the library to use SLF4J Loggers instead of println.

It turns out using Components V2 was a little overboard, there’s practically no use for it.

On the positive side: I found a great way to implement a connection with the Minecraft server that isn’t RCON! Using kRPC (KotlinX RPC), I made a way for clients to connect to the server and use the predefined services (for now, more will be added):

• CommandService, you can, well, run commands with this one!
• LinkService, upcoming service that allows people to link their Minecraft accounts with (technically any ULong value) their Discord Snowflakes (IDs).

Adding kRPC was a little harder in the start, but luckily I have some experience with Ktor and allat. Writing the model wasn’t hard, but writing the client and server logic was considerably harder, especially setting up the routes and authentication. (Yes it has authentication!)

Now that I have the base of kRPC set up, I can extend the model and as such, extend the functionality to give to clients.

These commits finally make per-webhook configs work and, well, in general make config work! Apart from this, I also added some migration logic for people that used the “old” mod (Chat To Discord). This was especially fun because I like making stuff work seamlessly for users and also seeing it work live when I finished it.

At first I wanted to mash all the webhook configs into one file, but that seems to bring along some weird quirks with Konf, so I opted to just make separate files for every webhook. This way I was actually able to also make a very very VERY minimal, but still quite effective API for configured webhooks.

Next up: adding Components V2 support. After that, I’m going to make some small tweaks that I see fit, and then it’s time for the big guns: I want to take a crack at making a Socket connection based protocol-ish thing maybe (?) for communication with a bot.

After a lot of work, I finally fixed the following few hassles:

• Build issues, a LOT of them, but it finally works in game now (at least, using a server on 1.21.1, I have yet to test 1.20.1);
• The webhook library, because I made my own! Check it out here: https://github.com/Tywrap-Studios/hookt (Flavortown: https://flavortown.hackclub.com/projects/2880);
• Some other things I probably already forgot (because I completely dropped working on this project in favor of hookt, lol)

Working with Stonecutter thus far has been a little confusing, but I’m getting the hang of it, especially the whole switching “Active Versions” thing, where you, well, switch between the version you’re actively working on.

As a last bit of stuff before the shipment, I fixed up some of the message stuff, polished the tests, and we’re good to go!

So lo and behold, passing tests!

This time I added file support for components and general attachments!

At first I was pretty discouraged because I’d have to work with the HTTP multipart/form-data Content Type rather than the usual application/json. The reason is because one part is for the JSON, and the others for the files, of course. Luckily, when I checked how well Ktor was made for this, it turned out it was surprisingly easy. With a small setup (which excludes the builders and DSL, and also the whole attachments block in the execute form) it already worked out of the box. Of course I still added DSL for files, that pretty automatically manages the attachments too, and it also works perfectly fine.

Alongside this I also quickly added a minimal data class for messages, so it can be returned from the execute function’s HttpResult, and used for the other message-related functions.

Happy new year!

This time I went ahead and added DSL functions to add components to your Discord message! As far as I’m aware there aren’t a lot of libraries that natively support Components V2, let alone make it a concise process.

Adding components was actually surprisingly easy, but I had to come up with some very interesting code that uses types, reflection and all that in order to “automatically” be able to add a universal component DSL function. It’s even developer in such a way that it’s pretty modular, you can probably add your own custom components in case this library does not support them. Again, everything is “properly” documented.

Next up: adding file uploading support, because a lot of these components include media and having to use just https probably won’t cut it for longer. Also, I want to write a GitHub wiki. Happy days!

The latter goal has been achieved, and I have added three helper functions that can retrieve environmental values!

getEnv, getEnvOrNull and getEnvOrElse. The first tries to get the value and throws if it can’t be found, the second simply returns null in that case and the third returns whatever you passed from the lambda (for when you maybe want to do user config via .env files!) Alongside this I added fitting JUnit tests for them (which was a beast, I liked tinkering around with the somewhat unused JUnit asserts, like assertThrows, which checks whether the code block provided throws a certain exception, handy in the case of getEnv.)

Now the only thing that remains is components and perhaps files.

Webhooks are stupidly simple, yet when I check to see if there are any ready-to-use wrappers with some decent DSL I can only find either bad ones, or old ones. Because of this, I decided to make my own since I desperately needed it for Khat (https://github.com/Tywrap-Studios/Khat), and maybe for other projects too, may they use webhooks.

In this quick session I added the bare-bones basics of webhooks: simple content messages and rich embeds. No files, although I might not add those, and no components. Considering Components V2 is very nifty to have, however, I am excited to try to implement using it through more comprehensive DSL.

So that’s next up, I want to add Components (V2) support, and utilities for getting environment variables.

I finished up making a new Kotlin Fabric project + Stonecutter versioning and moving over all the old logic and “files” from Chat To Discord to this project. Then I translated them into Kotlin counterparts, and changed them to utilise Stonecutter.
Now sadly I still have to work out some JVM quirks, so I don’t have anything to show, instead, have this picture of a Mixin class using Stonecutter to work for 1.20.X and 1.21.X!

Next up: fixing JVM quirks, and then improving the old logic and codebase! After that, I want to attempt messing with Sockets for a connection with an independently hosted bot (using our Krafter software).