FINALLY got everything working again

All versions are tested, but of course the maven servers the mod needs for building are NOT reliable. I’ve just had to cancel 10+ CI/CD runs just because maven servers timed out. Keep in mind, each run takes ~20min (which I actually also finally reduced down to ~5min). Only gotta build & publish everything now!

god DAMN it

Well… I found out today that all the versions I had published up until that point had the config setting’s effect inverted.
 
ADDITIONALLY, the forge version was just straight up broken. Turns out, it’s a stupid idea to not register KeyInputHandler.onKeyTick under Neoforge’s onClientTick event.

Other Changes

Instead of the setting in the config screen being a true/false value with “Show output in chat instead of actionbar”, the config value is now “Message Location” with a button that toggles between actionbar and chat for better UX.

Just started refactoring another one of my mods, CoordsCopy!

1.16.5-fabric already works, now I’m just trying to get forge and CI/CD running for today.

oh and look cool new logo :D

After a little bit of a fight, CatVision v3.0 is finally done!

Support for 26.1, 26.1.1, 26.1.2 and 26.2 is finally here.
After fixing a mistake in the fabric build config, everything finally works and compiles.

funny thing btw

Yesterday, the 1.21.9 build on github failed… because the maven server of one dependency decided not to respond :)

oh and look at this beautiful compatibility right here

1.21.x is done!! :)

Going to sleep now…

1.20.x is finally done! 🎉

I’ll be doing 1.21.x now, not sure if I’ll finish it today. Tomorrow, hopefully everything will be finished and I can start rewriting my other three mods in this format :)

A few notes

• Forge support has now been dropped in favour of NeoForge (the last version which supports forge is 1.20.1)
• 1.20.2, 1.20.3 and 1.20.5 don’t have NeoForge support (none publish gradle module data - they’re all beta versions - making it impossible for moddev-gradle to resolve them properly)
• Fabric still supports 1.20 to 1.20.6 tho! :)

i just spent two f*cking hours trying to find out why my mod wasnt loading in neoforge

So get this: In NeoForge 20.4 and earlier (which maps to MC version 1.20.4 and prior, I’m on MC 1.20.4), the metadata file should be under META-INF/mods.toml.

Exactly ONE version later (NeoForge 20.5+, aka MC 1.20.5+), that changed to META-INF/neoforge.mods.toml. Of course, my build toolchain was generating neoforge.mods.toml and NeoForge wasn’t recognizing that, it wanted mods.toml.

why why why do i do this to myself every single day

Support for 1.19.x is here!

All the 1.19 versions are built, working and published!

Next up is 1.20.x, however those will be taking a longer time due to NeoForge being introduced at 1.20.2.

Support for 1.18.x is here!

After a few more hiccups, 1.18, 1.18.1 and 1.18.2 are finally working! :)
 
1.18 is already out, 1.18.1 is building on github and 1.18.2 is about to start building

And the Modrinth Page still isn’t public… (still being reviewed 🥲)

I AM FREE OF THIS HELL (for now)

it is 3h after midnight why do i do this to myself

The problems (there were a lot of them)

• Wrong Java Versions caused the mod to blow up when starting in a real launcher
• After correcting the Java Versions, fletching-table didnt resolve :D (it needs Java 17+, but MC needs Java 8 (1.16.5) and Java 16 (1.17.1))
• Cloth Config was misbehaving >:(
• JiJ (jar in jar) did NOT want to work properly (cloth config issue #1)

AAND the final boss… cloth config issue #2

Final boss (scary alert)

Problem: The dev instance of minecraft uses the mojang mappings, but cloth config uses SRG mappings. Of course, SRG mappings and mojang mappings aren’t compatible, and as soon as you opened the config menu, the game would crash (but only in dev builds!). The problem is, this issue would’ve likely stayed for EVERY forge version of the mod, meaning debugging would’ve gotten VERY ANNOYING (build, import into real minecraft instance, test there).

The Fix

Simple: just remap cloth config from SRG to mojmap when in the dev env! Simple task!

…except the remapper needs a “dictionary” jar in the same mappings as the thing it’s remapping. Cloth is SRG. The dev env only has mojmap. So there was no SRG dictionary to hand it.

How do I solve this now? SIMPLE!!! Remap Minecraft itself BACK to SRG just to use it as the dictionary, then remap cloth against that!!!!!!!!!!!! All that to fix ONE GODDAMN FIELD NAME
 
I would like to thank Claude for the technical (and moral) support in this thank you thank you thank you thank you thank you thank you

i am going to bed holy f*ck

1.16.5 works and is out!

Published on GitHub, under review on Modrinth and Curseforge :)

What’s currently done

• CI/CD working, builds & publishes to github, modrinth and curseforge automatically
• 1.16.5-fabric done and released
• 1.16.5-forge done and released

The Problem with 1.16.5-forge specifically

NFRT (the runtime behind net.neoforged.moddev.legacyforge) can only build Minecraft versions that ship official Mojang mappings (which start at 1.17), which of course aren’t shipped for 1.16.5. This required the switch to Architectury Loom for that one version+loader combo. (thank you claude for your token-sacrifise for that 🫡)

I’ll be working on the next few versions now, wish me luck they’ll be easier! 😅

CI/CD working!

I finally got all the CI/CD (validate, build, publish to github, modrinth and curseforge) working.
 
Next, I’ll be trying to get forge for 1.16.5 working to be able to publish 1.16.5 fully.

CatVision v3.0

yes, this is the third rewrite

Why rewrite again??

I didn’t like the project structure (seperate branch per minecraft version, hard to maintain, every version has to be managed independently, hard to scale) and I wanted compatibility for 1.16.5 up to the latest version and all inbetween with support for fabric, forge and neoforge.

The Solution: Stonecutter

Stonecutter is a gradle plugin that lets you maintain a single codebase for a multi-version and multi-loader project. You just annotate your code with version and loader conditions, and at compile time, stonecutter just “preprocesses” the annotated code.

On a slight side note to preprocessing (if you’re interested): Preprocessing is the act of temporarily changing the source code (the human readable code that you write, NOT the machine code) before compilation. This is done by the preprocessor, a special program written for this one purpose. It is usually the first step in a program’s compilation (example: the C preprocessor, with instructions like #include, #define and more)

Current progress

Currently, I’ve got the template up and running with the 1.16.5-fabric version of the mod already functional. I’ve also set up the GitHub repo and the modrinth and curseforge projects.

The refactoring hell continues…

I’ve refactored PMM and VMM into SIMPLE_STATE, updated the build and docs scripts, enhanced kernel logging via log levels and more, added and fleshed out a Claude Code Skill for writing rustdoc and let Claude re-do a lot of the rust doc to reduce the over-documentation that was done by none other than… Claude.

also look at this fancy new fb logging :D

Refactoring into oblivion!

Currently working on improving the kernel a lot to make it robuster for its later stages.

What was so far improved

Tooling

• Replace loose markdown docs with proper GitHub Pages hosted rustdoc
• Add docs.py, refactor build.py to work on linux too

Kernel

• Serial Logging abstracted into trait + per-arch impls
• Improve panic handlers to give more info and dynamically use what is avail for outputting info (basic fb, serial)
• Refactor basic framebuffer and PSF2 font into cleaner struct+impl approach
• Remove text.rs and move its logic into kprint (which has also been refactored to be concurrency-safe)

Other Stuff

I also tested the kernel on real hardware!!
To my suprise, grabbing the ISO from the build folder, flashing it onto a USB drive and plugging it into a laptop just… WORKED?!?

well i guess my kernel is real hardware certified now :)

I attached a video of the kernel booting on real hardware and IRQ0 (the BIOS-configured 18.2 Hz hardware timer) printing “a” repeatedly. :)

Big Update :)

(sorry for not doing much the past weeks had to get 4th place at the botball competition real quick)

Changelog

• Implemented heap allocator (partially and broken)
• Implement PIC (Programmable Interrupt Controller) Init + get basic IRQ stuff working
• Fix GDT (was missing a few entries)
• Fix TSS (IST1-4 interrupt stacks were missing)
• Implement interrupts for vectors #0 through #31
• Update Panic for most interrupts to give way more details (example: pagefault in attached image)
• Replace Mutex with IrqMutex for text writing and holding CHAINED_PICS

Current State

I’ve noticed that my so far work has been kinda sloppy, so I’m currently working on improving everything (as u can see on the changelist above ive already started). I’m doing this because when I started with IRQs, stuff started breaking a lot. My goal is to get everything thread-safe and ready in a way that it’ll work in later stages of the kernel too.

Next up?

Next, I’ll be working on fixing logging (add a ringbuffer to prevent interrupts creating half-printed or partially drawn logs)

Partial Live CPU Data working! :)

I’ve managed to get the live CPU stats (usage, per-core usage and (approx.) clock speed) and the CPU usage graph running.

One problem with the current approach for measuring values (which is done using OSHI) is that on Windows, things like CPU temperature, CPU clock speed and others are not reliable.

Why?

On Windows, metrics like CPU temperature are read over WMI. However, the actual CPU temp is often only partially or not at all correctly exposed via WMI. CPU clock is often a stale/cached value or sometimes not at all given.
 
This requires an external source of data which is both correct and more reliable.

Technical Architecture of HwManager and live stats/graphs

The hardware manager is a class that can provide all sensor data necessary. It abstracts OSHI and any future methods of aquiring data into one class (with instances of other classes such as Cpu).
It has its own thread which calls the pollValues method of all subclasses (Cpu, …) which then update their internal values, which can be retrieved via getter functions.

The Window class has an internal timer which calls the update method of TopPanel, MiddlePanel and BottomPanel, which then call each component panel’s update method which then update their stats and graphs.

Fan Panel and Disks Panel done!

After once again a little time away from this project, I finally finished the fan panel and the disks panel! :)

Fan Panel

The fan panel has a 2x3 grid which expands in columns if more than 6 fans are present (which also expands the width of the panel). Each fan is just a Stat instance.

Disks Panel

Each Disk is given params such as name, type (NVMe, SATA SSD/HDD, …), usage percentage and read/write rates. Then, the Disk instance manages the layout and drawing.
 
The Disk class extends BaseBottomEntry, which is a horizontal JPanel with a BoxLayout and a name label. Then, Disk adds a JPanel on the right side of itsself and places stats like the ones given above (type, read/write activity, …) in it. For usage, there’s also a PercentageBar which is also custom-written.

Looking forward to finishing the UI and then getting started on the actual stats reading! :)

UI coming together even more!

The core UI structure is done now. This includes:

• Top Row
• Middle Row
• Bottom Row

Top Row

The top row contains CPU and RAM, same as in the last devlog.

Middle Row

The middle row contains all GPUs and fan speeds. This means it can contain 2..n component panels (if n is number of GPUs minus one).
It is horizontally scrollable which prevents this row over-cluttering the popup (which would be caused by methods like wrapping excess panels to the next row).

Bottom Row

This row contains two panels which fill the window’s width. The first panel - the disks panel - contains info about all disks or drives in the computer. It will have one “entry” (one row inside the panel with info such as drive name, transfer speed and used/total size).
 
Same goes for the network panel, which contains all network adapters. It will display info such as download, upload, adapter state and name.