Latest and greatest

How RedeeMOD’s last improvement before Stardance wraps up looks like:

1. Stability

CLI had an option to specify missing paths, but specifying paths manually usually comes with the intention of overriding them no matter what.

Unfortunately, for the backend it didn’t matter - if defaults are specified, the custom-set paths in CLI were disregarded. Now it’s fixed, bringing stability for server environments, where control is preferred!

2. Control

Alongside the previous improvement, paths can also be overridden within the Settings menu, together with custom launch flag specification!

This lets anyone preserve the mod libraries if installation path changes instead of requiring a full re-addition of a game.

3. Looks

Looks were also slightly modified - both internally and externally.

Internal classes changed in order to maintain simplicity, and externally - cancel/delete buttons have a vivid border. This helps with distinction and makes buttons stand out/differ.

Bottom line

I really like the current shape of RedeeMOD and I hope more people discover it and help me with the ecosystem growth.

Every game deserves preservation and appreciation through mods. Let’s make loading them simple!

More posts!

As Stardance comes to an end, I want to finish some of my plans for DoMax.lt.

Added content

I finished a post about one of my most anticipated projects this year - RedeeMOD. You can check it out on Stardance as well.

Within the post you can find detailed insights about the development project and original intention for RedeeMOD, I think it’s worth checking out!

You can read the latest blog here.

Restructuring

It’s always important to think about some sort of scaling. With the increasing amount of content within DoMax.lt, the file structure became really messy. That’s why I decided to restructure it by year, which made the source tree easier to navigate.

Future plans

Sadly, I couldn’t implement dark mode just yet. However, I’m not putting the idea aside and it will surely be added after I finish writing my latest ideas as of today.

So stay tuned!

Server is online!

You can connect to it by opening ut99.domax.lt on Unreal Tournament ’99 (has to be OldUnreal-patched)

What changed?

Very little. I added a README, and reorganized the environment variables.

I also implemented server setting replacement logic, which empties unset values if they have no defaults on startup.

This was done to leave no stale settings lingering inside of the .ini file.

What’s on the server?

It’s an only-deathmatch server with a plugin to vote for maps at the end of round, nothing more, so a pretty vanilla experience. Bots are tuned to be 6/8 difficulty, so you’ll have to practice a bit ;)

If something’s malfunctioning, reach out to me on Slack, and I’ll try to help fixing the problem.

MODS!

How I integrated mod support into the server (I’m very excited)

1. Why so many hours?

Adding mods would seem a fairly easy task, regarding that I had already built a mod launcher that supports CLI. Most of that time was spent debugging why the server image stopped immediately after starting.

RULE NUMBER 1: Learn from my mistakes, always check if your entrypoint process continues, or if it exits.

Turns out, my CLI app spawned a process… And exited! Which means that no matter what else was running, since the main container process no longer exists, the whole container shuts down.

The solution was to monitor the container’s SIGTERM/SIGINT signals that are handed upon stopping, and only THEN kill the RedeeMOD task. Otherwise, keeping it alive is necessary.

2. How did I actually add modding?

That was simple. I exchanged the executable from base UT99 server binary to RedeeMOD’s CLI and limited Python to disallow exiting early.

RedeeMOD handles everything natively, making me only supply the mod folders and nothing more.

The server runs, there’s just one annoying bug, but I believe it’s an issue in the executable itself. Using open {map_name} through server console instead of servertravel {map_name}?game=BotPack.{game_type} makes the whole server throw a segmentation fault and require a manual restart.

And the web admin panel is quite poor in terms of functionality. Some time in the future I might write an updated web panel and try to get a PR merged to OldUnreal’s upstream, but that’s not a priority for now.

Other than that, I’m feeling confident, and no more major overhauls await. Just the integration of GitHub actions for automated container builds, and some automation stuff (like pre-commit hooks).

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!