Multiloader modding is pain

Can’t NeoForge and Fabric just have one common api, for all the boring stuff like registration, networking and events?
I’ve had enough, so I spent 2 hours porting my mod to Balm, which is a library providing exactly that.
The result is beautiful - ~150 lines are gone, and the loader specific subprojects fit under 10 lines of code, as I was able to move everything to common.
Now for the worst irony:
I spent my time doing all of that and the next thing I’m gonna do is… disable fabric support 😭
Why, you may ask?
I was forced into it by reality
read on

First VFX

I made my first VFX, for the leap spell. You can see it in the attached video. It’s going to spawn under player’s legs. For now it’s a really simple one, as I’m rushing to add a bit more of content, than just a single spell, before Stardance ends.

It is made using Photon Editor, which is a VFX editor for Minecraft. It has a lot of good stuff, like emitters, timeline and animation curves, which will be crucial in making more advanced effects.
Only downside: It doesn’t support Fabric, which is why support for it is going to be disabled for now, until I manage to hopefully make a port it in the future.

Reworking spell internals (again)

After making the effect, I realized I have no way to run it from the spell code, because spell logic runs server side only, and VFX needs to be played on the client.
So I wen’t back to the drawing board, and I’m going to change how spells run. They are going be entities now, but more on that next devlog, because it’s not done yet, as I ran into friction in the code, which triggered me to do the Balm refactor, and in the meantime the time counter hit 9,5h.

Do NOT hardcode stuff please

I had to do some work on my laptop today, which has NixOS. So I update my Sephyr clone, try to run it, and bada bing bada bum, it doesn’t work! What’s going on? After a hour of debugging, it turned out that NeoForge devs hardcoded their Gradle plugin to run one specific task using Java 21. The rest runs on Java 25 (the one used by Minecraft 26.1). So, be default, a NeoForge setup for Mc 26.1+ requires two java version. Normally the second one is autodownloaded, but that doesn’t work on NixOS, and that’s also bloat. I don’t want that!
So I made a bug report. Fortunetely it isn’t really hardcoded, just dumb, and I was able to fix it with this line in build.gradle

Update to Burn 0.22

Burn 0.22 was recently released, removing the Backend generic from most of it’s traits. I updated Sepple to work with that. I also had to regenerate the model code for the multipa model. I was hoping the update would provide some speedup to speech processing, but I wasn’t able to measure any difference.

Replacing Multipa with Zipa

I found a new speech-to-IPA model. It’s called Zipa, and it looks very promising. It’s around 4x smaller then multipa, which means faster processing and less to download for end users. Furthermore, according to it’s paper, and my few tests it has noticeable better accuracy!
So I implemnted it. It was a little more trouble then multipa, because the model has a much richer pre-processing. The audio waveform is turned into a mel spectogram, Fourier Transform is done, and other stuff happens.
Buuut there is a problem. It turns out the model is great at doing recognition on longer audio sequences, and doesn’t really work that well on short ones. For them it performed worse then multipa! That means it’s not suitable for doing recognition in realtime, at least when plugged in the same way multipa was. However I have a couple ideas to try, which might, hopefully, solve the issue. Until I do that, it is set aside on a separate branch.