Khat

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

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.

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).