Server owner? RedeeMOD is now CLI!

Honestly, I wouldn’t even have thought about it if not for my other project, UT99 server container. Turns out, this is quite useful!

How does it work?

Like any other CLI app would. It lets anyone load mods on any game without opening the GUI.

It’s useful for 2 audiences:

1. Server owners, that need a tool that could be automated
2. Terminal tinkerers, most likely Linux users :D

After the beginning of UT99 server project one of the things I immediately thought about was modding the server, not only the client. Whether it’s a mutator, map or anything else - tinkering with individual directories can be brittle, especially in a server environment.

Having a tool manage mods is much simplier and foolproof, since RedeeMOD even handles mods disposably - they don’t override the main installation, leading to a predictable setup at all times.

Did anything internally change?

Yes! Qt is no longer a dependency of the backend, allowing CLI app to be much smaller.

The application data paths are now handled manually.

The repo now also has more tests to account for new CLI features.

New adventure of UT99 saga

After the success of RedeeMOD, my other project (a mod launcher for games), I decided I want to make an easier way of running dedicated Unreal Tournament ’99 servers.

The plan

My plan was to create a Docker container, mostly for portability. Since the server itself was already implemented by Epic Games back in 1999, all I have to do it to package it for Docker.

Thankfully, Epic back in the day supported Linux and included official binaries, which are still maintained by a volunteering group called OldUnreal. This meant I didn’t have to think about integrating Wine/Proton into the container!

And while a docker container for UT99 was previously made by someone, lack of updates disappointed me. I decided to make my own because of a couple reasons:

The technologies used

Having experience in UT99 modding, I decided to use Python since I could use RedeeMOD as a source for code templates.

Having coded a modding tool for this game was also trivial while asking AI - my own repos were heavily used as context.

In the near future I’m also planning to bake-in RedeeMOD for mod support for servers, providing great use of something I had already made!

Current stage

Today I have built a strong foundation for the server - it builds, validates and applies environment variables (through .ini patching) and runs the server with provided config. Within its run pipeline also has a place for near-future addition of modding.

Web panel works, LAN discovery too!

It has no CI/CD pipelines yet, but that’s one of the main things I’ll be taking a look at in the next day or so.

Quality of life improvements

I’m happy to report work on Onlinja took one more step further!

Before Stardance closes…

After contacting Steffen Spiele directly and telling them about Onlinja, a love letter to one of their games, we settled on a mutual opinion of lack of attribution.

Luckily, I managed to implement a distinct “credits” tab without casualties :)

And, I am happy to present improvements for both developers and users!!

1. User-end improvements

Taking a better look at your newest suggestions, I noticed 2 issues:

1. Unclear tutorial
2. Bland highlight colors

I tried tackling both. While I couldn’t shorten the tutorial (as I’m not willing to update the rule spec), a new “Try it out” button was added to notify the player about an action block.

The colors were boosted to have better distinction compared to standard lanes :)

A spinning loader wheel now indicates when the app is ready to use.

2. Dev-end improvements

To make Onlinja’s source also feel welcoming for developers, naming conventions, redundant code and skills were upgraded. Imports were refactored for code that’s easier to read and navigate, SoC is a priority while developing (to not make a mess).

Expo 57 makes it easier for anyone to develop and test Onlinja, as newer Expo Go versions expect strict Expo 57+ compatibility.

Centralized animation and other systems help when making consistent changes :)

Conclusion

This devlog (likely the last) demonstrates the most mature version of Onlinja singleplayer. As virtually no time is left before Stardance closes, and I won’t be able to implement multiplayer services, I want to conclude this project by saying a big Thank You to every supported and tester, and I hope I can see a big community grow when multiplayer eventually releases :P

Quite a late first post!

This project began quite a while ago, but I wasn’t devlogging. So let me show you around.

My plan with Resin

When I started out with Hack Club’s Sprig, I couldn’t really bear the software limitations. I always thought RPI Pico is more capable than how it’s portrayed with Sprig.

While this Hack Club initiative is great, inconsistencies between the web simulator and real firmware (many games don’t work on the console) mixed with quite a poor editor made me wonder about a Python alternative.
Its primary goal - beating current firmware:

1. No differences between simulation and real firmware, ensuring code works everywhere
2. HUGE performance improvement
3. Updated API, making Sprig feel like a real game console
4. Multiple-file workflow with imports
5. Image-based graphics (instead of bitmaps)
6. Better launcher experience

What have I already implemented?

By exploring MicroPython and testing the speed I saw something incredible - a seemingly equal setup had shockingly smooth perforemance, even reaching stable 60-ish fps!

All thanks to these solutions:

• Python handles calculations, C handles hardware access
• Small framebuffer allocations within Python, C code handles displaying the pixels
• Utilization of the DMA (direct memory access) chip - allows no CPU use for certain memory transfers, which doesn’t block game loop

In addition to this, Input, Rect drawing, persistent State store and general rendering now work flawlessly.

Out of screen objects are not rendered (culled), which also helps with smooth frame times. Sprig’s official colors are also transferred perfectly!

How did the development journey go so far?

Initial build setup was quite complex, as I’ve never made a MicroPython derrivative, so I had to carefully plan the architecture (to make Resin firmware build, include custom libraries, and have in mind publication to PyPI).

On top of that, the hardest part was getting hardware to register properly.

Screen requires some magic bytes to be sent to initialize. SPI bridge for communication made things easier (having to manage only a handful of pins), however getting it to render colors and do so in correct orientation was a nightmare.

Official repository was a great point for reference regarding to how hardware is configured and wired on the PCB, however I had to make my own research while implementing DMA chip framebuffer transfers.

The rest is pure python - when I implement the game launcher and write a small utility to make game transfers easier, I will finish defining the rest of developer API.

What’s next?

Resolving bugs, writing a launcher, and, of course, a simulator, so that anyone can develop games for Sprig without the real hardware. This way Resin can even become a choice for game developers and function as a standalone game engine!

Delta time for frametime-independent calculations and API guards to not overwrite important memory by accident are also one of my top priorities.

What you see below is a test Python file running - no C code for game’s logic. If you have a Sprig and want to help me test Resin, DM me on Slack!

Pre-ship devlog

This post is about everything that recently happened with Matcha Linux

1. New terminal app!

Yes, gnome-console got boring, so I replaced it! With none other than ghostty. It’s great - has hardware rendering support, native integration with Kitty image rendering (so fastfetch renders the logo properly) and MANY color themes, one of which happens to perfectly match Matcha’s look and feel.

2. Package management

Since ghostty is from Alpine’s edge repos, I had to find a native way of tagging the packages both while building the iso, and installing the system.

Previous approach blindly installed every package from live ISO. This works only when every package is designed to be sourced from the stable branch. One edge package and updates (or maybe the whole system) breaks!

Now, a helper file helps install the necessary packages both onto the ISO and later system’s disk. Since packages are installed by their names, not separate files from some medium, the installation can also be way more accurate and, in some cases, more compact.

3. OpenGL checks

Ghostty loves OpenGL. But it relies on OpenGL 4.3+, and on hardware that doesn’t support this - crashes. Luckily, if GPU bridge fails, CPU can handle OpenGL operations just as well!

Matcha Linux, starting from today, is expecting hardware to support OpenGL 4.3+ to utilize the GPU for OpenGL APIs. Anything older than 2013-ish (which goes on par with UEFI requirement) would fail. In case of that happening, I added conditional rendering to use the CPU as a fallback.

For now, however, it’s system-wide (to support any other software built with OpenGL 4.3+). OpenGL ES is not supported on the GPU at the moment.

4. Bugfixes!!

Who doesn’t love when their software just… Works?

The upgraded matcha-calamares installer now has a full cleanup stage, correctly catches errors regarding the install ISO presence, also has fixes for many other mount and install issues that could happen in earlier releases.

Bottom line

I love building this Linux distro. The challenges I have to face and the amount of operation ordering I have to do helps me improve. Structure is one of the skills I think humanity is yet to fully master, and i hope that one day, it can.

As for the future of Matcha, it will continue to grow! Tech never sleeps, new releases need updates, and Matcha mustn’t be left behind. I also have more ambitious stuff planned (like an update manager and distrobox install module for calamares), and they are the only thing I’m afraid of implementing.

For now, I’ll stick to making Matcha Linux as stable as possible, and then focus on something more exciting.

I hope more people find this distro to test, daily drive and share the feedback! Always exciting to engage with communities.

3GB RAM milestone!!

How I managed to achieve 3GB RAM usage in the live environment (but at the same time - break a couple things)

Stage 1 - package optimization

Probably not a surprise to you that Gnome desktop environment is a heavy beast. Well, as it turns out, it bundles a bunch of stuff that’s not technically required to run the system.

Alpine package gnome adds many apps (like calendar, weather and more) that aren’t relevant anymore. However, even though unused, they take up space, and in Alpine, the live environment installs every package onto ram to provide a diskless environment.

At first I tried making a filesystem capable of loading packages from mounted iso as it’s necessary for the install either way, but optimizing package selection turned out to be easier (besides - who has a 64bit system with less than 6GB ram these days?)

Stage 2 - package loading

The fact that package selection is optimized to reduce Gnome’s bloat wasn’t enough to make the install environment lighter.

Alpine has a file /etc/apk/world in which every package that should be installed is defined. Utilizing it I could control what packages must appear within the live system, and which - not (because you probably don’t need a heavy browser before installing the system).

Stage 3 - things break if you’re too brave

And they broke for me too. Certain admin functionality (like some polkit integrations) don’t work anymore due to the limited selection (and probably some hidden dependencies) of packages.

I think I have diagnozed the issue though - testing suggests that it could be the missing linux-pam package or some dbus initialization race conditions.

Other important updates

Besides implementing optimizations to the image (consequences of which I can hopefully fix), I also made sure to update extensions, as well as the matcha-calamares package that now has a broader support for systems and reduces crashes. The building pipeline was also slightly tweaked.

Either way, I’m off to fixing the issue, so see you in the next devlog!

Tested and working!

How (and why) I implemented tests in RedeeMOD

The reason behind “why”

My dad is a high profile developer, and many new things I try are influenced by him. While I always liked setting up CI/CD pipelines and other automations, one thing my projects lacked was testing.

Turns out, many tech jobs require knowledge about tests, because they guarantee several things:

1. They assure that your application works as it should
2. They document your working concept
3. They let you make refactors that don’t hurt the functionality

So, after considering these benefits, I started reading how tests are implemented.

How did I implement tests for RedeeMOD?

There are 3 main types of tests:

• Unit (where one small component is tested)
• Integration (where several combined components and their behaviour is tested)
• End to End (where full system flow from start to finish is tested) (they take a long time, so I didn’t even consider them for RedeeMOD)

First thing any testable software should have is clear dependency injection.

Dependency injection is a pattern where you don’t call dependencies directly, but pass them externally. I opted for implementing method argument injection that I could later use in tests.

Why is DI required? Well, during testing, the external environments must be mocked and created virtually to test different use cases (things like sys.* calls and more). Luckily, RedeeMOD already had a nice and semi-testable architecture where very few things needed to be changed.

Writing tests is a tedious and rather boring process, because all the edge cases must be defined. Don’t hate me for this, but I handed over writing tests to AI. My arguments for why AI is appropriate for this are:

1. You can’t test software that hasn’t been previously written (by people)
2. Repetitive work takes away precious time, and AI just performs checks

While one could argue that Test-Driven Development exists, after trying it out I can confidently say that I’m not a fan of TDD.

However, giving very broad instructions, like “Make me tests for this project” usually doesn’t go well, because AI can’t retain project philosophy and tests what doesn’t need to be tested (things that don’t contain logic, thus can’t really fail).

RedeeMOD currently has a test suite based on pytest with integration and unit tests written.

How tests could benefit you?

With tests, instead of clicking around (and often forgetting) every edge case manually, you can offload it to a machine that does hundreds of calculations extremely fast. Not only is it a well-regarded pattern within the developer community, but also helps with coding efficiency and guards from failed refactors.

Quake fans - I got you!

Thought RedeeMOD would only be available for niche titles? Not exactly!

Which Quake?

Most people would probably agree with me that Quake 3 Arena was the best entry of the series for multiplayer games.

After seeing just how many Quake 3 mods there are (some even being standalone games) I had to implement an adapter for it with support for both standalone games and mods!

I resorted to the IOQuake 3 engine support due to its extra capabilities and being the modern choice for most, so original Id Tech 3 might not work.

How does it work?

IOQuake 3 inherits cvar support (and adds more!) from Id Tech 3 engine. Utilizing com_basegame, i could bypass Quake 3 Arena file presence for standalone games.

What about Quake 3 MODS that are not standalone?

The new adapter follows an interesting edge-case detection logic:

1. If a mod has default.cfg file somewhere within its .pk3 files, it’s considered standalone. Other games are required to have genuine Quake 3 Arena present, about what RedeeMOD will warn.
2. IOQuake 3 requires Quake 3 Arena or Team Arena files to be in baseq3 and missionpack directories. This adapter handles warning users against such restriction.
3. Quake 3 Arena can’t be launched through RedeeMOD as a mod. Everything else works perfectly fine (based on testing).

All mods I tested worked fine. If you find one that does not, kindly report it on GitHub issues 😄

The most challenging adapter of all

No doubt, the amount of testing that was required to get this working is absurd, and definitely it was the most challenging adapter of all.

Pre-ship devlog!

Maitenance pre-ship revealed 3 more bugs that I couldn’t live with…

Bugs? What bugs?

Actually, very counter-intuitive!

1. UT99-specific: Turns out, when Unreal Tournament ’99 reads configuration and finds duplicate filenames in different directories, FIRST ENTRY DEFINED WINS, which, from coding perspective, is very unusual! Usually, if you define a variable, it can be redefined later. UT99 does not work like that, so I made the mods override any system files if they do override any.
   I noticed this by trying to load one of my favorite mods ever - the HD pack, which overrides system textures. Glad this bug got noticed!
2. UT2004 skins not working: Some skin mods would not work due to the correct files not being imported on game runtime. By adding an extra file extension to the list of import files, I was able to fix this!
3. Label truncation fails: Previously I had implemented an ElidedLabel that truncates a string and replaces the ending with ... if it is too long. In some rare instances however it failed and set a boundary on window size instead of truncating. However, it’s not an issue anymore!

Error handling is better now

I ran into an issue that got me confused - I couldn’t launch a game. I panicked, thought that my launcher was broken again, and only then did I realise that the game wasn’t installed!

Launcher did not notify me and I got frustrated. Since I want the UX to be flawless, the best decision was to make a pop-up in case of a critical error.

I gotta say - the ship is finally truly 100% ready!

Code, break, fix, repeat!

Here’s what the final 1.0.0 release of RedeeMOD brings:

Fully tested and documented!

I built RedeeMOD not only as an app to manage Unreal Tournament games exclusively (though at first, that was the plan), but also as a framework to create more games in the future compatible with RedeeMOD!

I recently wrote a Contribution guide that lets anyone create adapters and expand RedeeMOD by following a detailed guide!

Also, as a standard practice, GitHub actions were added to help with releases. Both Windows and Linux builds work perfectly, but are unsigned, so Windows might throw Smart Screen or Smart App Control warnings. These are safe to ignore, and if they bother you too much, you can always resort to launching RedeeMOD directly through Python!

Changes in code

The code is formatted with Black formatter. It’s way easier to format the code using a tool than doing so manually.

Also, I found some bugs that weren’t immediately noticeable. Things like:

• An uninitialized variable being still required in code (produces a TypeError)
• Image painting events overriding each other
• Much more

They are now fully fixed. Some inconsistencies between files have also been resolved.

This latest build now features logos to feel more professional. User interface has been updated with more detailed card subtitles, so the app is easier to navigate.

Overall, RedeeMOD is in its stable form for the first time ever. Now it’s just the matter of whether more adapters will be created for other games by the community!

Does RedeeMOD lack something?

Well, the mod management is very simple - adding, removing and enabling/disabling a mod probably doesn’t sound like the most sophisticated mod manager on the earth, but I am planning to later add a pop up that lets users customize the mods even further, like adding custom launch options, paths, even image customization, but that will require more time and I feel confident enough that the current feature set is good for the first ship.

For more info on RedeeMOD, visit its GitHub repository!

Finally, it feels complete!

What I’ve been through and why do I feel relieved

So, after a LOT of trial and error, and MANY wrong paths taken, Unreal Tournament 2004 adapter is functioning!

Why it took so much effort for such a simple thing

UT2004 differs from UT99 in many different areas, even its modding system:

• It now has a dedicated -mod flag instead of using an overriden .ini file
• Every mod has its own mandatory structure, and UT2004 doesn’t like multiple mods loaded
• Mods can load diffs of system .ini files

My plan was to replicate what I was doing with UT99 - building a custom mod at runtime that would bundle every enabled mod together.

Since this game is quite old, so are its development sources. I resorted to the best source there is - proven to work mods.

My top 3 problems with UT2004, ranked:

1. Using empty files or ones that are with LF line endings instead of CRLF produces either a segfault or a Bad Mod error
2. UT2004 creates a LOT of mod-specific runtime files, and they need to be cleared to be regenerated (I hate caching, as going through them all is difficult)
3. I couldn’t get mods with heavy custom GUI usage to work, unless they’re being launched standalone, using UT2004 Community tab (which defeats the point of my launcher)

Since I wanted to use the modern -mod flag, I had to make my own mod, which needs such files to function:

• ModDir/UT2K4Mod.ini (Name and description)
• ModDir/System/Default (Diffs of what to add/remove)
• ModDir/System/DefUser (Can be left empty, but requires at least one \r\n line)

I’m thankful to whatever or whoever made me as patient as I am, because DefUser being absolutely empty causing a segfault or files requiring CRLF even in Linux was very unexpected, and required hours of investigation.

On top of said implementation, backend framework also needed changes to ensure stability and flexibility. New methods returning more data to the game adapters were added, as well as improvements in attribute names and path handling.

Bugs are always present…

After testing with some edge cases, I found bugs that got resolved shortly after.

Windows, as of now, works flawlessly, but I’ll be performing more tests when I distribute a full build.

What’s that, some new GUI?

Yes! I wanted to implement logos since the day 1 of starting this project. Surprisingly, that was one of the easiest modifications to date.

Screen state tracking was also improved to provide no visual bugs after adding, removing, selecting and deselecting added material.

Finally shipping, finally stable?

Again, yes. All the intended functionality is verified to be working, and you can already try it out for yourself!

Running python -m frontend.app from the project’s root will open up this GUI for you to play around! Over the next few days I’ll finish making all the necessary branding, README and ensure licensing is correct. Then I’ll push a final devlog and make a ship.

Thank you for everyone following RedeeMOD’s journey. Keep rocking, and make the world truly Unreal!

Last devlog before shipping!

Final changes

Before pushing any major update I tend to test all the things myself to ensure that user-facing compatibility is pristine. However, when I went on and tried engaging one of the main features of my installer - parallel installs, I began to face a problem - the extension wasn’t installing!

My guess is that Google family of browsers (Chromium, Chrome and Chrome Canary) have some protection or sandboxing, and trying to initiate an install across multiple browsers is disallowed deep inside Chrome’s code.

Another possibility is that my code is broken or the server that runs locally to install the extension isn’t configured properly. This is probably more likely, as I could’ve overlooked things.

Either way, the easiest fix for that was to disallow concurrent installs and only let users select one browser at a time to install the extension for. This works surprisingly consistently, as I wasn’t able to encounter any issues.

Thanks for anyone who keeps an eye on this project. It was more of a pain than actually something useful, but I don’t regret my efforts.

Stay creative, stay open source!

UI tweaks!

This looks better in my opinion

After taking a look at the previous design I thought it looked quite ugly and inconsistent when some cards have center-aligned elements and others don’t. This update fixes these issues!

You really spent so many hours on simple UI tweaks?

Yes and no. While the primary purpose of this devlog IS to describe subtle interface change, under the hood many quality of development improvements hide as I’m trying to implement and fiddle with Unreal Tournament 2004 game adapter, which required a more streamlined API of adapter creation rather than what was previously developed.

So, this devlog has hours logged from both a fully developed interface and half-developed new game adapter implementation. Stardance was warning me about getting close to 10h limit, so I must post this before diving deeper into Unreal Tournament 2004, which has way more twisted stuff within its modding system.

Stay tuned and wish me luck!

A fresh look

Expanding on the design I like, I decided to add some improvements.

What improvements exactly?

All these things:

1. The launcher now supports adding multiple games (even though currently the only game supported is Unreal Tournament ’99 (more to come))
2. A sidebar was introduced for better UX
3. A more user-friendly card design was expanded to become the main component interface relies on
4. Backend experienced a bit of an overhaul too to support game/mod branching
5. Safeguards were implemented to disallow adding multiple copies of the same mod OR directories that do NOT contain Unreal mod content
6. Config is now stored in local paths for saving/loading added material
7. Library tab disappears if no games are detected

Wow! This is really awesome! Is it ready to be shipped?

I could ship the current version, but there are exactly 3 things stopping me from doing so.
I need to:

1. Verify functionality on Windows (so it doesn’t become another Linux-only project of mine)
2. Add verification for game paths and prompt user to enter location for both executable and config (if applicable/not found)
3. Add Unreal Tournament 2004 functionality to leverage multiple game selection and see if it works (as well as possibly other games of the franchise, like Unreal and maybe even Unreal Tournament 2014)

Interface update

A functional UI demo has just been made!

Following a design language similar to Unreal Engine 5, I was able to make a functional UI, that can launch the game with selected mods!

The UI is written with PySide6, which allows for Qt6 API to be used on Python, giving a modern development workflow, with customizable stylesheets and cross-platform capabilities.

What’s next?

I want to rewrite the launcher a bit to support more games in the future and be more architecturally correct, at the same time feeling more premium both from the user-facing app, and the source code too.

Discovery - done!

With the installation discovery done, I can finally focus on the real provisioning and frontend.

How does it work?

Utilizing common installation paths of Unreal Tournament, I could build a simple config.json file that has all this information for Windows and Linux.

Then, I wrote a simple json parser, and methods to use as a simple interface for the frontend.

What else currently exists?

The current source tree has this functionality implemented:

• Filesystem utils for finding and sanitizing paths (required by Unreal Engine to load paths relative to the executable)
• .ini file editor (because Unreal Engine operates on .ini files for configuration, one of which allows for custom file discovery. Editing it allows injecting custom mod files)

Next plans?

I will try and build a user-facing application that does exactly 3 things:

1. It discovers the installation directory (so the frontend can also act as a launcher)
2. It lets you add folders with mod files
3. It lets you load one or more mods (and the base game) by constructing a .ini file on the go

Maybe something more will come to my mind as time passes.