I’ve also added download counts for every item in the store. Now you can see how many times each file has been downloaded, which gives a clearer picture of what’s popular. This is useful for both me and for you, because it highlights the designs that resonate most with the community. The download count adds a layer of transparency and helps you spot trending items at a glance.

Social sharing is now available on blog posts and store items as well. You can easily share your favorite finds on platforms like Facebook, or BlueSky. This makes it simple to spread the word about something you love, whether it’s a tutorial, a new product, or a behind-the-scenes story. I’ve also added embedding to blog posts, so I can include images and videos directly in the posts. This means richer, more engaging content without needing to click away to other sites. Photos of finished projects, step-by-step video guides, and close-up details can all be part of the reading experience now. It makes the blog feel more alive and connected to the crafting process.

Right now, the focus is on serial connections. That is the primary way these radios talk, so that comes first. I am also looking at adding Bluetooth support down the line. That would cover a lot of newer radios and make the tool even more useful in the field.

The goal is to offer a proper alternative to carrying around a laptop just to change a frequency or update a setting. With PocketProgrammer, you can connect directly to the radio, read its current configuration, and write new settings. It is designed to be straightforward and practical.

The app is still rough around the edges. There are features to add, bugs to fix, and a lot of testing to do. But the foundation is there. If you work with serial radios and have wanted a more portable way to manage them, this is something to keep an eye on.

I will share more as development continues. Feedback from people who actually use these radios will be very valuable, so feel free to reach out when the time comes. For now, this is the start of something promising.

I am still figuring out my next move. One option is to stop distributing Pocket25 in Texas through the Google Play Store. I could keep offering it for side loading from pocket25.com instead. That way, users in Texas can still get the app directly from me without any store enforced age gates. I am not sure yet. I need to weigh the hassle against the risk.

For now, I will not update my apps to use the Play Age Signals API. I will not collect or pass along any age data to Google. If Texas wants to track users, they can do it without my help. I built Pocket25 for a specific audience, and age checks are not part of that vision. I will find a workaround or simply pull the app from the Texas storefront. Side loading is simple and keeps the control where it belongs. With the user. Not with the state or the store.

I am slowly replacing those apps now. Each one requires careful attention. I need to get them signed properly, which is a step I should have taken from the start instead of panicking. The signing process ensures that the apps are trusted and secure, and it aligns with the new policy requirements. It is tedious work, but it is necessary.

At the same time, I am updating them with our new versioning API. This is a feature I have been meaning to implement for a while. The API allows the apps to tell you if there is an update waiting for it. Instead of you having to check manually or rely on outside sources, the app itself will notify you. It is a small improvement, but it makes a big difference in keeping everyone on the latest and safest version.

Rebuilding takes time, and I have to remind myself that progress is still progress even if it is slow. The apps are coming back one by one, each better than before. The rash move cost me some convenience and trust, but it also taught me a lesson about acting on fear. Now I am focused on doing it right, with proper signing and better update management. The forge will be fully stocked again, and this time it will be built to last.

Imagine having an AI assistant that lives inside your WordPress admin. You can talk to it just like you would with any chat bot. But instead of just answering questions, this AI can actually take action on your site. It can create posts, update pages, manage users, adjust settings, and much more. The 41 tools cover almost every aspect of site management.

Getting started is simple. You install the DeepWP plugin like any other. Then you add your DeepSeek API key from your account. Once that is done, the chat bot appears in your admin panel. You type a command or ask a question, and the AI responds. If you ask it to do something, it will use the appropriate tool to make it happen.

The power here is in the tool set. The AI can write and edit content. It can change themes and plugins. It can handle media uploads and user roles. It can even run database queries if you need that. Each tool gives the AI a specific ability, and together they cover the full range of what you can do in WordPress.

This is useful for busy site owners. You can delegate routine tasks to the AI. You can ask it to schedule posts or optimize images. You can have it check for broken links or update your site’s SEO settings. The AI works fast and follows your instructions precisely.

DeepWP turns your WordPress admin into a command center. Instead of clicking through menus and forms, you just tell the AI what you need. It handles the rest. For anyone who manages a WordPress site regularly, this plugin saves time and effort. The 41 tools give DeepSeek AI complete control, and that control is exactly what you need to run your site efficiently.

Starting today, every product page now shows a version number right next to the title, so you know exactly what you're getting. Below the screenshots, you'll find a full changelog a running timeline of every update, what changed, and when it dropped.

No more guessing whether you have the latest build. And to tie it all together, each product now exposes a lightweight API endpoint your apps can call to check for updates automatically. Give it your current version and it'll tell you if there's something newer waiting.

Dead simple.

Here's what that looks like in practice:

• Buy a product once, never wonder if you're out of date
• Apps can ping the API and alert you when an update is available
• Full changelog history lives right on the product page This is the kind of polish I want baked into everything that leaves the Forge. More to come. — Sarah

The good news is that the developers are not walking away. The official website, pocket25.com, still has the APK file available for anyone who knows where to look and is willing to manually install it. That keeps the app alive for now, but it is not a long term solution. Google’s new policies and the increasing friction around side loading mean that relying on that method is becoming less reliable and more confusing for users who just want to listen to trunked radio traffic without jumping through hoops.

So the team behind Pocket25 has a plan. They are preparing to bring the app into the Google Play Store. This is a significant step because it changes how the app is distributed, how updates are handled, and how safe users can feel about downloading it. Instead of hunting down an APK file and enabling unknown sources, users will be able to find Pocket25 in the Play Store, tap install, and have it work like any other app on their phone. It will be released for free with no ads. That part matters. There will be no subscription fee, no banner ads cluttering the interface, and no paywall blocking access to the features that make the app useful. The goal is to keep it open and accessible to the same community that has supported it all along.

For anyone who relies on monitoring public safety communications, fire departments, police, or other agencies that use P25 Phase 1 trunking, this change is a welcome one. It means fewer headaches with compatibility, easier updates, and a smoother experience overall. The developers are working through the Play Store submission process now, which involves meeting Google’s requirements for privacy, security, and functionality. It takes time, but the end result will be a cleaner, more stable way to run Pocket25 on any compatible Android device.

If you have been using the side loaded version, keep an eye on the Play Store in the coming weeks. The official release will appear there, and when it does, you can simply install it over your existing setup or start fresh. For now, if you still need the APK directly, pocket25.com remains the place to get it. But that will change once the Play Store version is live. The transition is not about abandoning the old method entirely. It is about adapting to a shifting mobile ecosystem so that a useful tool does not get left behind.

But Google recently made a change to how APKs are registered on your device, and the implications for side loading are more significant than most people realize. To understand what happened, you need to look past the technical jargon and see what is actually different about the way your phone now treats these files.

In the past, when you downloaded an APK from a website and tapped on it, Android would ask for permission to install it. Once you granted that permission, the app would install and appear on your home screen. It was a straightforward transaction between you and the file. The app did not need to be registered with Google in any special way. It just worked.

The new change involves something called the Android App Bundle and a shift toward requiring apps to be registered with Google Play’s servers before they can be installed on newer versions of Android. This does not mean you cannot side load at all, but it means that the APK file you download must now match a verified signature that Google holds on its servers. If the app developer has not pushed that specific version through Google Play, your device may reject it.

At first glance, this sounds like a security measure. And in many ways, it is. Malicious actors have long used side loading to distribute fake versions of popular apps that contain malware or spyware. By requiring a verified registration, Google can ensure that the app you are trying to install actually came from the developer it claims to represent. For the average person who only side loads occasionally, this is probably a good thing. It adds a layer of protection that was previously missing.

But for the dedicated side loading community, the change feels like a tightening of the screws. If you enjoy using apps like NewPipe, which offers an ad free YouTube experience, or if you rely on a banking app that is only available in another country, this new registration requirement can become a wall. The developers of these alternative apps often do not register their builds with Google Play, either because they cannot or because they do not want to. So when you try to install their latest version, your phone may simply refuse.

There is also a practical inconvenience here. When you side load an app today, you are not just dealing with the file itself. You are dealing with the entire ecosystem that Google has built around app verification. If the app was originally uploaded to the Play Store by a developer, even if you then download that same APK from a third party site, it will likely install because the signature matches. But if the app was never on the Play Store, or if the version you have is a modified fork, your phone will block it.

What does this mean for the future of side loading? It means that the open nature of Android is slowly being replaced by a more curated experience. Google is not shutting the door completely, but they are adding a lock that only they hold the key to. The days of freely installing any APK you find on the internet are fading for users of the latest Android versions. You can still side load, but only as long as the app you are installing has been blessed by Google’s registration system.

Some will argue that this is a reasonable trade off for increased security. Others will feel that it undermines the very reason they chose Android over iOS in the first place. The truth likely sits somewhere in the middle. If you are careful about where you get your APKs and you understand the risks, you may never notice the change. But if you rely on apps that exist outside the official storefront, you may find yourself searching for workarounds or holding onto an older phone that still respects the old rules.

The change to APK registration is a quiet one. It did not make headlines like a new phone launch or a major software update. But it speaks to a larger shift in how Google views the relationship between the user and the device. They are moving from a philosophy of trust the user to a philosophy of trust the store. And for anyone who values the freedom to install what they want, when they want, that is a change worth paying attention to.

The projects I share on my blog are not quick little tasks I finish in an afternoon. They are the kind of projects that take days, sometimes even weeks, to complete. I pour myself into them. I work through the hard parts, solve the tricky problems, and finally get to the satisfying moment where everything comes together. By then, I am tired. The last thing I want to do is sit down and write a long, detailed post about something that I have already lived through in my head a hundred times. The excitement is still there, but the energy for typing it all out is gone.

That is where RozeFox comes in. It is a Firefox plugin that has become a quiet little helper in my workflow. The best part is that I did not have to sign up for anything new. It uses the DeepSeek API key I already had, sitting there unused in my account. I write a short post, just the bare bones of what I want to say. A few sentences. The key points. The heart of the story. Then RozeFox takes that short post and rewrites it into a full length article.

I do not just publish it right away. That would be too easy, and honestly, it would not feel like my voice. Instead, I read through the expanded version carefully. I tweak the parts that sound off. I add in details that the plugin could not have known. I smooth out the rough edges. It feels like having a collaborator who takes my messy first draft and hands me back something that looks like a real blog post, ready for me to make it truly mine.

For someone like me, who loves to create and share but hates the slow grind of typing, this has been a small gift. It lets me focus on what I do best. Building things. Figuring things out. Making progress on the next project. And when I am ready to share, the writing part does not feel like a burden anymore. It feels like the natural end to a good story.

Below is the original text I input:

When it comes to blog posts I have a hard time keeping up these days. It takes a long time to type out a full post and often I'm posting about projects I've been working on for days or even weeks.

When it comes to projects like that it's nice to have RozeFox, it's a firefox plugin that uses the deepseek api key I already had to re-write my short posts to full length posts that I read through and tweak.

If you walked into my high school's computer lab after hours, you wouldn't hear the clicking of people typing essays. You'd hear the frantic, rhythmic slamming of mice and keyboards, punctuated by the faint, muffled sound of the announcer screaming, "M-M-M-MONSTER KILL!" through someone's cheap headphones.

Unreal Tournament 2004 wasn't just a game for me—it was the game. It was the defining multiplayer experience of my high school years. Between dodging Shock Rifle combos, mastering the chaos of Onslaught mode, and the sheer adrenaline of Instagib matches, UT2004 cemented itself as one of my all-time favorite games. It was fast, it was unforgiving, and the netcode was legendary for its time.

Fast forward to today. The gaming landscape has changed, GameSpy is a relic of the past, and Epic Games eventually pulled the plug on the official master servers.

The community, as always, found a way. Projects like OpenSpy stepped in to emulate the old GameSpy infrastructure, keeping UT2004 and dozens of other classic games alive. But recently, I wanted to dig deeper. I wanted to host my own infrastructure and see exactly how this classic game communicated under the hood.

There was just one problem: OpenSpy’s master server implementation isn't open source.

If you know anything about engineers driven by nostalgia, you know that closed source isn't a roadblock—it's an invitation. So, I decided to build my own. Here is how I reverse-engineered the UT2004 master server protocol and built OpenUT2k4MasterServer from scratch.

Diving Into the Matrix: Wireshark and Ghidra

Without access to the original server source code or OpenSpy's repository, I had to figure out how the game client and game server talked to the master server. This meant tackling the problem from two angles: observing the network traffic and decompiling the game's binary.

I started by routing my UT2004 client and a dedicated server through Wireshark to capture the packets talking to utmaster.openspy.net. Seeing the raw hex dump of GameSpy’s "enctype 2" protocol was like reading an ancient dialect.

To make sense of the bytes, I dropped UT2004's IpDrv.dll into Ghidra. By piecing together the decompiled C++ code with the packet captures, the puzzle finally started coming together.

The Game Client Protocol

When you click the "Internet" tab in UT2004, the client initiates a TCP connection to port 28902. It's a strict handshake process:

1. Challenge: The server sends a challenge string.
2. Auth: The client responds with hashes.
3. Approval: The server replies with an APPROVED packet.
4. Verification: The client sends a verification string (starting with !).
5. Request: Once VERIFIED, the client asks for either the MOTD (news) or the server list.

The Game Server Uplink

If you're hosting a server, it needs to tell the master server it exists. This also happens over TCP 28902 but behaves completely differently after the auth phase:

• After approval, the master server sends "state 2" session keys.
• The game server enters "state 3," keeping the connection alive.
• It sends heartbeats and, after about 60 seconds, fires off a massive refresh packet containing the server name, port, and gametype.

Building OpenUT2k4MasterServer

Armed with the protocol specifications, I fired up Go. Go is fantastic for network applications, making it incredibly easy to handle concurrent TCP connections, binary packing, and UDP listeners.

I built OpenUT2k4MasterServer, a fully open-source drop-in replacement for the UT2004 master server.

Core Features I Implemented:

• TCP Master Server (Port 28902): Handles both the intricate game client server list queries and the persistent game server uplinks.
• UDP Heartbeat Listeners (Ports 27900 & 28902): Catches the lightweight UDP pings servers send to prove they are still alive.
• MOTD / News Support: I even reverse-engineered the GameSpy color codes (e.g., \x1b\xff\xff\xff) so the in-game News tab populates correctly with custom messages.
• HTTP Management API (Port 8090): Because it’s 2026, I added a modern JSON API to manually register servers and check the network status via the browser.

The Quirks of 2004 Tech

Working on this project reminded me of the fascinating quirks of older game engines. For example, UT2004 categorizes 127.0.0.1 servers strictly under the LAN tab. If you're testing an internet master server locally, you have to use your actual network IP, or you'll be scratching your head wondering why your server isn't showing up in the Internet list. Furthermore, strings are often passed around with hardcoded length bytes and null terminators—classic early 2000s C++ networking.

Keeping the Legacy Alive

There is something profoundly satisfying about writing modern Go code to interface with a C++ game engine compiled over two decades ago.

By open-sourcing the master server, my hope is that the UT2004 community never has to rely entirely on a single point of failure again. Whether you want to host a private master server for a massive LAN party, or just poke around the GameSpy protocol out of curiosity, the code is out there.

High school me would be pretty thrilled to know we’re still finding ways to keep the tournaments running.

If you want to check out the code, host your own server, or contribute, you can find the OpenUT2k4MasterServer repository on my GitHub. Happy fragging!

Due to upcoming policy changes and tighter registration requirements from Google scheduled for November, we’ve decided to remove all Android apps previously distributed through Sarah's Forge. These changes introduce additional overhead and constraints that don’t align well with how we want to ship smaller, fast-moving tools and experimental software.

Going forward, we’ll be focusing our mobile releases on the official app marketplace instead. That means Pocket25 will be moving into the official app store ecosystem, with a proper, compliant release path and ongoing updates delivered through standard channels. This should make installation, updates, and trust far more straightforward for users.

Pocket25 will be the first project to follow this new distribution model, and it will serve as the baseline for how future mobile releases are handled.

Future software from Sarah's Forge will still be sold and distributed through official app store channels where applicable, rather than standalone Android packages. This should help streamline support, improve discoverability, and ensure long-term stability across devices.

We’ll continue building and shipping tools as usual—just with a more standardized distribution path moving forward.

Overview

I'm excited to share the latest updates to Pocket25, my Android application for decoding APCO Project 25 (P25) trunked and conventional radio systems. Build 1.0.0+4 brings significant stability improvements, powerful new features, and a much smoother user experience. Over the past few days, I've been laser-focused on eliminating crashes, improving performance, and adding features that real users actually need.

🚀 Major New Features

Advanced Scan Mode

One of the biggest additions is the new Advanced Scan feature, which gives power users complete control over DSD-Neo's command-line options directly from the app. Instead of being limited to the UI's quick scan presets, you can now input full command strings like:

-i rtltcp:192.168.1.240:1234:771.18125M -fp -H key_here -4

This means you can:

• Specify custom RTL-SDR or RTL_TCP configurations
• Add encryption keys on the fly
• Set custom decoder flags and modulation parameters
• Use any DSD-Neo option without recompiling the app

The Advanced Scan screen includes helpful examples for RTL-SDR direct USB, RTL_TCP remote connections, and encryption key usage. This is a game-changer for advanced users who know exactly what parameters they need.

HackRF One Support

is currently in testing, it's not complete and I don't recommend you use it, yet.

Enhanced Radio Reference Import

The Radio Reference import feature got some major love:

• Canada Support: Canadian users can now import systems from RadioReference.com
• GPS-Based County Lookup: The app automatically detects your county using GPS coordinates
• Improved Location Accuracy: Fixed the county detection algorithm to check ALL counties in your state instead of just sampling, dramatically improving accuracy
• Auto-Scroll to Trunked Systems: When you select a county, the UI now automatically scrolls down to show available trunked systems

Scan Grid with Category Filtering

Added a new Scan Grid view that organizes talkgroups by category (Law Enforcement, Fire/EMS, Public Works, etc.) with visual filtering. The grid remembers mute states and makes it easy to see what's active at a glance.

Web Programmer Feature

Introduced a multi-page Web Programmer interface for advanced radio configuration directly from the app. This is still experimental but opens up interesting possibilities for system management.

🛠️ Critical Bug Fixes

ANR (Application Not Responding) Crash Fixes

The biggest stability work went into eliminating ANR crashes that were plaguing users:

1. Site Switching Crash (FIXED): The app was freezing when switching between sites during GPS-based site hopping. The problem? Heavy database operations and distance calculations were running on the main UI thread, blocking user interactions.

   • Solution: Moved site loading to a background thread and distance calculations to a compute isolate with a custom haversine function
   • Result: Butter-smooth site switching even with 200+ sites loaded

2. Talkgroup Mute Crash (FIXED): Muting talkgroups during an active transmission was causing the app to hang.

   • Solution: Optimized the native-level audio filtering to handle mute state changes asynchronously

3. Native USB RTL-SDR Crash (FIXED): Switching control channels with a native USB RTL-SDR dongle would crash the app.

   • Solution: Proper cleanup and reinitialization of the RTL-SDR device during channel changes

4. Advanced Scan Input Device Bug (FIXED): When using Advanced Scan with custom -i device parameters, the app would ignore the setting and default to 'pulse' audio.

   • Solution: Re-apply custom arguments in nativeStart() to prevent settings from being overwritten

UTF-8 Crash Fix

Fixed a crash caused by invalid UTF-8 characters in DSD decoder output. The native C++ code now properly handles encoding issues before passing strings to Flutter.

Talkgroup Name Lookup Fix

Corrected database field mapping for talkgroup name lookups, ensuring the right names display during monitoring.

Scan Grid State Persistence

Mute states in the scan grid now persist correctly between sessions and don't reset unexpectedly.

⚡ Performance Improvements

Stay on Control Channel for Muted Talkgroups

When a talkgroup is muted, the scanner now stays on the control channel instead of following the voice channel. This dramatically reduces unnecessary frequency hopping and improves overall performance.

DMR Audio Improvements

Enhanced DMR audio output quality through better buffer management and frame timing.

P25 Phase 2 Partial Improvement

Implemented frame-by-frame audio output for P25 Phase 2 systems. While Phase 2 audio is still choppy (upstream DSD-Neo limitation), it's noticeably better than before. Full details are documented in P25_PHASE2_AUDIO_ISSUE.md.

🎨 UI/UX Enhancements

• Overhauled Scanner Screen: Redesigned with scaled status display and better information density
• Network Screen: Added comprehensive display of patches, group attachments, and affiliations
• Signal Metrics: State-based signal quality indicators and improved adjacent sites display
• Custom App Icon: Pocket25 now has its own distinctive icon
• Fixed Icon Cropping: Disabled adaptive icons to prevent the icon from being cut off on some launchers
• DSD Log Screen: Removed the "jump to bottom" button (auto-scroll works better)

📦 Development Infrastructure

• Automatic Version Management: Build numbers now auto-increment, making release tracking easier
• Wakelock: App keeps the screen on while running to prevent interruptions during monitoring

🔜 What's Next?

I'm actively looking for sample recordings of non-P25 protocols (DMR, NXDN, D-STAR, YSF, dPMR) to improve multi-protocol UI support. If you have recordings or systems to test, please reach out!

Upcoming features on my radar:

• Better P25 Phase 2 audio
• Enhanced talkgroup database management
• Export/import of system configurations

📥 Download

You can download the latest APK from SarahsForge.dev/products/Pocket25

Source code is available on GitHub under GPL v3.

🙏 Acknowledgments

Pocket25 is built on the amazing DSD-Neo decoder engine by @arancormonk. Huge thanks to the open-source digital radio community for their support and feedback!

If you're using Pocket25, I'd love to hear about your experience. Feel free to open issues on GitHub or reach out with feedback.

73,
SarahRose

Sometimes nostalgia meets modern development, and magic happens. That's exactly what happened when I decided to build UTAdmin - a complete administration solution for Unreal Tournament 2004 servers that lets you manage your server from your phone. This project combines the ancient art of UnrealScript with modern Flutter development, all built on Windows.

The Problem

I've been running UT2004 servers on and off for years, and admin tools have always been... clunky. Most require you to be at the console, use awkward in-game commands, or rely on web interfaces from 2004 that barely render on modern browsers. I wanted something simple: manage my server from my phone while I'm playing or AFK.

The Solution: A Two-Part System

UTAdmin consists of two components:

1. A server-side mutator that exposes a TCP API server written in UnrealScript
2. A Flutter mobile app that connects to the API and provides a clean, modern UI

Let's dive into how I built this on Windows.

Part 1: The Mutator - UnrealScript TCP API Server

Setting Up the UT2004 Development Environment on Windows

First things first - I needed to get UnrealScript compilation working on Windows. Here's what I did:

1. Located my UT2004 installation (usually C:\Program Files (x86)\Unreal Tournament 2004\)

2. Created the mutator structure:

   UT2004\
   └── UTAdmin\
       └── Classes\
           ├── UTAdmin.uc
           ├── UTAdminAPIServer.uc
           ├── UTAdminConnection.uc
           └── UTAdminMessage.uc

3. Modified UT2004.ini to add the compile path:

   [Editor. EditorEngine]
   EditPackages=UTAdmin

4. Compiled using the command prompt:

   cd "C:\Program Files (x86)\Unreal Tournament 2004\System"
   ucc. exe make

Architecture: The Mutator Design

The mutator follows a clean three-class architecture:

1. UTAdmin.uc - The Main Mutator

This is the entry point. It initializes when the server starts and spawns the API server:

class UTAdmin extends Mutator config(UTAdmin);

var() config string AdminPasscode;
var() config int AdminAPIPort;
var UTAdminAPIServer APIServer;

function PostBeginPlay()
{
    Super.PostBeginPlay();

    Log("UTAdmin:  Initializing...");

    if (AdminPasscode == "" || AdminPasscode == "changeme")
    {
        Log("UTAdmin: WARNING - AdminPasscode not configured or using default value! Set AdminPasscode in UTAdmin.ini");
    }

    if (AdminAPIPort <= 0)
    {
        AdminAPIPort = 7778;
        SaveConfig();
        Log("UTAdmin: Using default port 7778");
    }

    APIServer = Spawn(class'UTAdminAPIServer');
    if (APIServer != None)
    {
        APIServer.Initialize(AdminPasscode, AdminAPIPort, self);
        Log("UTAdmin: API Server started on port" @ AdminAPIPort);
    }
    else
    {
        Log("UTAdmin: ERROR - Failed to spawn API Server!");
    }
}

defaultproperties
{
    FriendlyName="UT Admin API"
    Description="Exposes a clean REST-like API for external admin tools"
    GroupName="UTAdmin"
    AdminPasscode="changeme"
    AdminAPIPort=7778
    bAddToServerPackages=True
}

Key features:

• Configuration via UTAdmin.ini file
• Validation for security (checks for default password)
• In-game configuration support through the host game menu
• Clean initialization and teardown

2. UTAdminAPIServer.uc - The TCP Listener

This class extends TcpLink and listens for incoming connections:

class UTAdminAPIServer extends TcpLink;

var string Passcode;
var int APIPort;
var array<UTAdminConnection> Connections;
var Mutator OwnerMutator;

function Initialize(string InPasscode, int InPort, Mutator InMutator)
{
    Passcode = InPasscode;
    APIPort = InPort;
    OwnerMutator = InMutator;

    LinkMode = MODE_Line;
    ReceiveMode = RMODE_Event;

    if (BindPort(APIPort, true) > 0)
    {
        Listen();
        Log("UTAdminAPIServer:  Listening on port" @ APIPort);
    }
    else
    {
        Log("UTAdminAPIServer: ERROR - Failed to bind to port" @ APIPort);
    }
}

event GainedChild(Actor C)
{
    local UTAdminConnection NewConnection;

    Super.GainedChild(C);

    NewConnection = UTAdminConnection(C);
    if (NewConnection != None)
    {
        Connections[Connections.Length] = NewConnection;
        NewConnection.LinkMode = MODE_Line;
        NewConnection.ReceiveMode = RMODE_Event;
        NewConnection.SetPasscode(Passcode);
        NewConnection.SetOwnerMutator(OwnerMutator);
        Log("UTAdminAPIServer: New connection accepted, total connections:" @ Connections.Length);
    }
}

defaultproperties
{
    AcceptClass=class'UTAdminConnection'
}

The magic here:

• BindPort() opens a TCP socket on Windows
• MODE_Line tells UnrealScript to buffer incoming data line-by-line
• Each new connection spawns a UTAdminConnection actor
• The GainedChild event tracks active connections

3. UTAdminConnection.uc - The Command Processor

This is where the real work happens. Each client connection gets its own instance:

class UTAdminConnection extends TcpLink;

var string Passcode;
var bool bAuthenticated;
var string ReceiveBuffer;
var Mutator OwnerMutator;

event ReceivedLine(string Line)
{
    Line = Repl(Line, Chr(13), "");
    Line = Repl(Line, Chr(10), "");

    if (Len(Line) > 0)
    {
        ProcessCommand(Line);
    }
}

function ProcessCommand(string Command)
{
    local string CommandType, Payload;
    local int SplitPos;

    Log("UTAdminConnection: Processing command: " $ Command);

    SplitPos = InStr(Command, " ");

    if (SplitPos != -1)
    {
        CommandType = Left(Command, SplitPos);
        Payload = Mid(Command, SplitPos + 1);
    }
    else
    {
        CommandType = Command;
        Payload = "";
    }

    CommandType = Caps(CommandType);

    if (CommandType == "AUTH")
    {
        HandleAuth(Payload);
    }
    else if (!bAuthenticated)
    {
        SendJSON("{\"error\": \"Not authenticated. Send AUTH <passcode>\"}");
    }
    else if (CommandType == "PING")
    {
        SendJSON("{\"status\": \"pong\"}");
    }
    else if (CommandType == "STATUS")
    {
        HandleStatus();
    }
    else if (CommandType == "PLAYERS")
    {
        HandlePlayers();
    }
    else if (CommandType == "KICK")
    {
        HandleKick(Payload);
    }
    else if (CommandType == "SAY")
    {
        HandleSay(Payload);
    }
    else if (CommandType == "CHANGEMAP")
    {
        HandleChangeMap(Payload);
    }
    else
    {
        SendJSON("{\"error\": \"Unknown command: " $ CommandType $ "\"}");
    }
}

function HandleAuth(string AttemptedPasscode)
{
    Log("UTAdminConnection: HandleAuth called. Attempted='" $ AttemptedPasscode $ "' Expected='" $ Passcode $ "'");

    if (AttemptedPasscode == Passcode)
    {
        bAuthenticated = true;
        SendJSON("{\"status\": \"authenticated\"}");
        Log("UTAdminConnection: Client authenticated successfully");
    }
    else
    {
        bAuthenticated = false;
        SendJSON("{\"error\": \"Invalid passcode\"}");
        Log("UTAdminConnection: Failed authentication attempt");
    }
}

function HandleStatus()
{
    local GameInfo GI;
    local string Response;

    GI = Level.Game;

    Response = "{";
    Response = Response $ "\"gametype\": \"" $ GI.GameName $ "\",";
    Response = Response $ "\"map\": \"" $ GetURLMap() $ "\",";
    Response = Response $ "\"players\": " $ GI.NumPlayers $ ",";
    Response = Response $ "\"maxplayers\": " $ GI.MaxPlayers $ ",";
    Response = Response $ "\"timelimit\": " $ GI.TimeLimit;
    Response = Response $ "}";

    SendJSON(Response);
}

function HandlePlayers()
{
    local Controller C;
    local PlayerController PC;
    local string Response;
    local bool bFirst;

    Response = "{\"players\": [";
    bFirst = true;

    for (C = Level. ControllerList; C != None; C = C.NextController)
    {
        PC = PlayerController(C);
        if (PC != None && PC.PlayerReplicationInfo != None)
        {
            if (!bFirst)
            {
                Response = Response $ ",";
            }
            bFirst = false;

            Response = Response $ "{";
            Response = Response $ "\"name\": \"" $ EscapeJSON(PC.PlayerReplicationInfo.PlayerName) $ "\",";
            Response = Response $ "\"id\": " $ PC.PlayerReplicationInfo.PlayerID $ ",";
            Response = Response $ "\"score\": " $ PC.PlayerReplicationInfo.Score $ ",";
            Response = Response $ "\"ping\": " $ PC.PlayerReplicationInfo.Ping;
            Response = Response $ "}";
        }
    }

    Response = Response $ "]}";
    SendJSON(Response);
}

function HandleSay(string Message)
{
    local Controller C;
    local PlayerController PC;

    // Send message to all players - ClientMessage for HUD display
    for (C = Level. ControllerList; C != None; C = C.NextController)
    {
        PC = PlayerController(C);
        if (PC != None)
        {
            // ClientMessage displays on HUD
            PC.ClientMessage("[ADMIN] " $ Message, 'Say');
        }
    }

    Log("UTAdmin: Broadcasting message: " $ Message);
    SendJSON("{\"status\": \"Message broadcasted\"}");
}

function SendJSON(string JSON)
{
    SendText(JSON $ Chr(13) $ Chr(10));
}

function string EscapeJSON(string Input)
{
    Input = Repl(Input, "\\", "\\\\");
    Input = Repl(Input, "\"", "\\\"");
    return Input;
}

defaultproperties
{
    bAuthenticated=false
    LinkMode=MODE_Line
    ReceiveMode=RMODE_Event
}

Design decisions:

• Line-based protocol: Simple and easy to debug with telnet
• JSON responses: Even though UnrealScript doesn't have native JSON, I manually construct it (it works!)
• Authentication first: No commands work until you authenticate
• Direct game state access: Uses Level.Game and Level.ControllerList to query server state

The Protocol

The protocol is beautifully simple - send a command, get a JSON response:

CLIENT:  AUTH changeme
SERVER: {"status": "authenticated"}

CLIENT: STATUS
SERVER: {"gametype": "DeathMatch", "map": "DM-Rankin", "players": 4, "maxplayers": 16, "timelimit": 20}

CLIENT: PLAYERS
SERVER: {"players": [{"name":  "Player1", "id": 0, "score": 15, "ping": 45}, ... ]}

CLIENT: SAY Hello everyone! 
SERVER: {"status": "Message broadcasted"}

CLIENT: KICK 42
SERVER: {"status": "Player kicked"}

CLIENT: CHANGEMAP DM-Deck17
SERVER: {"status": "Changing map to DM-Deck17"}

Windows Firewall Configuration

Don't forget to open the port in Windows Firewall! On Windows 10/11:

New-NetFirewallRule -DisplayName "UT2004 Admin API" -Direction Inbound -LocalPort 7778 -Protocol TCP -Action Allow

Or through the GUI:

1. Windows Defender Firewall → Advanced settings
2. Inbound Rules → New Rule
3. Port → TCP → 7778
4. Allow the connection

Part 2: The Flutter App

Setting Up Flutter on Windows

On my Windows development machine, I installed Flutter:

1. Downloaded Flutter SDK from flutter.dev
2. Extracted to C:\src\flutter
3. Added C:\src\flutter\bin to PATH
4. Ran flutter doctor to verify installation
5. Installed Android Studio for mobile development

Project Structure

FlutterApp/
├── lib/
│   ├── main.dart                    # App entry point
│   ├── utadmin_client.dart          # TCP client library
│   └── screens/
│       ├── connection_screen.dart   # Server connection UI
│       ├── dashboard_screen.dart    # Main dashboard
│       ├── players_screen.dart      # Player management
│       ├── broadcast_screen.dart    # Broadcast messages
│       ├── maps_screen.dart         # Map changing
│       └── status_screen.dart       # Detailed status
├── android/                         # Android-specific files
└── pubspec.yaml                     # Dependencies

The TCP Client Library

The heart of the Flutter app is utadmin_client.dart, which handles all communication with the server:

import 'dart:io';
import 'dart:convert';
import 'dart:async';

class UTAdminClient {
  final String host;
  final int port;
  final String passcode;

  Socket? _socket;
  StreamController<String>? _responseController;
  bool _isAuthenticated = false;
  bool _isConnected = false;

  UTAdminClient(this.host, this.port, this.passcode);

  bool get isConnected => _isConnected;
  bool get isAuthenticated => _isAuthenticated;

  Future<bool> connect() async {
    try {
      // Close existing connections first
      await _cleanupConnection();

      _responseController = StreamController<String>. broadcast();
      _socket = await Socket.connect(host, port, timeout: Duration(seconds: 5));
      _isConnected = true;

      _socket!.listen(
        (data) {
          final response = utf8.decode(data);
          final lines = response.split('\n');
          for (final line in lines) {
            if (line.trim().isNotEmpty && _responseController != null) {
              _responseController!.add(line. trim());
            }
          }
        },
        onError:  (error) {
          _isConnected = false;
          _isAuthenticated = false;
        },
        onDone: () {
          _isConnected = false;
          _isAuthenticated = false;
        },
      );

      // Give socket time to establish
      await Future.delayed(Duration(milliseconds: 200));

      // Authenticate immediately
      await authenticate();
      return _isAuthenticated;
    } catch (e) {
      _isConnected = false;
      _isAuthenticated = false;
      await _cleanupConnection();
      return false;
    }
  }

  Future<void> authenticate() async {
    try {
      _sendCommand('AUTH $passcode');
      final response = await _readResponse(timeout: Duration(seconds: 5));
      final json = jsonDecode(response);
      _isAuthenticated = json['status'] == 'authenticated';
      if (! _isAuthenticated) {
        throw Exception('Authentication failed:  Invalid passcode');
      }
    } catch (e) {
      _isAuthenticated = false;
      throw Exception('Authentication failed: $e');
    }
  }

  Future<Map<String, dynamic>> getStatus() async {
    _sendCommand('STATUS');
    final response = await _readResponse();
    return jsonDecode(response);
  }

  Future<List<dynamic>> getPlayers() async {
    _sendCommand('PLAYERS');
    final response = await _readResponse();
    final json = jsonDecode(response);
    return json['players'] as List<dynamic>;
  }

  Future<void> say(String message) async {
    _sendCommand('SAY $message');
    await _readResponse();
  }

  Future<void> changeMap(String mapName) async {
    _sendCommand('CHANGEMAP $mapName');
    // Don't wait for response as server will disconnect
    await Future.delayed(Duration(milliseconds: 100));
    await disconnect();
  }

  Future<bool> reconnect({int maxAttempts = 10, int delaySeconds = 2}) async {
    // Ensure clean disconnect first
    await disconnect();

    // Wait before first attempt
    await Future.delayed(Duration(seconds: delaySeconds));

    // Try to reconnect multiple times
    for (int i = 0; i < maxAttempts; i++) {
      try {
        final success = await connect();
        if (success && _isAuthenticated) {
          return true;
        }
      } catch (e) {
        print('Reconnect attempt ${i + 1} failed: $e');
      }

      if (i < maxAttempts - 1) {
        final waitTime = delaySeconds + (i * 1);
        await Future.delayed(Duration(seconds: waitTime. clamp(2, 5)));
      }
    }

    return false;
  }

  void _sendCommand(String command) {
    if (! _isConnected) {
      throw Exception('Not connected');
    }
    _socket!.write('$command\n');
  }

  Future<String> _readResponse({Duration timeout = const Duration(seconds: 2)}) async {
    if (_responseController == null) {
      throw Exception('Not connected');
    }

    try {
      final response = await _responseController!.stream.first. timeout(timeout);
      return response;
    } catch (e) {
      throw Exception('Timeout waiting for response');
    }
  }

  Future<void> disconnect() async {
    _isConnected = false;
    _isAuthenticated = false;
    await _cleanupConnection();
  }

  Future<void> _cleanupConnection() async {
    try {
      await _socket?.close();
    } catch (e) {
      // Ignore
    }
    try {
      await _responseController?.close();
    } catch (e) {
      // Ignore
    }
    _socket = null;
    _responseController = null;
  }
}

Key features:

• Async/await throughout: Clean async code using Dart futures
• Stream-based responses: Uses StreamController to handle incoming data
• Auto-reconnect logic: Handles map changes that kill the connection
• Connection cleanup: Properly closes sockets and streams

The UI: Material Design 3

The app uses Flutter's Material Design 3 with a dark theme and orange accent:

import 'package:flutter/material. dart';
import 'screens/connection_screen.dart';

void main() => runApp(const UT2004AdminApp());

class UT2004AdminApp extends StatelessWidget {
  const UT2004AdminApp({super.key});

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'UT2004 Admin',
      theme:  ThemeData(
        colorScheme: ColorScheme.fromSeed(
          seedColor: Colors.orange,
          brightness: Brightness.dark,
        ),
        useMaterial3: true,
      ),
      home: const ConnectionScreen(),
    );
  }
}

Building the APK on Windows

Building for Android on Windows is straightforward:

cd FlutterApp
flutter pub get
flutter build apk --release

The APK ends up in build\app\outputs\flutter-apk\app-release.apk.

Pro tip: If you get Android SDK errors, make sure you have:

• Android SDK 36 installed
• NDK version 27.0.12077973
• Updated android\app\build.gradle. kts with correct versions

Testing the Complete System on Windows

1. Start the UT2004 Server

cd "C:\Program Files (x86)\Unreal Tournament 2004\System"
UT2004.exe DM-Rankin? Game=XGame.xDeathMatch? Mutator=UTAdmin. UTAdmin -server

2. Verify the API is Running

Use PowerShell to test:

$client = New-Object System.Net.Sockets.TcpClient("localhost", 7778)
$stream = $client.GetStream()
$writer = New-Object System.IO. StreamWriter($stream)
$reader = New-Object System.IO. StreamReader($stream)

$writer.WriteLine("AUTH changeme")
$writer.Flush()
$reader.ReadLine()  # Should return:  {"status": "authenticated"}

$writer.WriteLine("STATUS")
$writer.Flush()
$reader.ReadLine()  # Should return server status JSON

$client.Close()

3. Deploy to Android Device

With USB debugging enabled on your Android device:

adb install build\app\outputs\flutter-apk\app-release. apk

Or connect via the Flutter app and enter:

• IP: Your Windows machine's local IP (e.g., 192.168.1.100)
• Port: 7778
• Password: changeme (or whatever you configured)

Challenges and Solutions

Challenge 1: UnrealScript's Limited String Handling

Problem: Building JSON responses with UnrealScript's primitive string operations was tedious.

Solution: Created helper functions like EscapeJSON() and carefully constructed strings with proper escaping:

function string EscapeJSON(string Input)
{
    Input = Repl(Input, "\\", "\\\\");
    Input = Repl(Input, "\"", "\\\"");
    return Input;
}

Challenge 2: Map Changes Kill Connections

Problem: When you change maps, the server restarts and kills all TCP connections.

Solution: Implemented automatic reconnection in the Flutter app with exponential backoff:

Future<bool> reconnect({int maxAttempts = 10, int delaySeconds = 2}) async {
  await disconnect();
  await Future.delayed(Duration(seconds: delaySeconds));

  for (int i = 0; i < maxAttempts; i++) {
    try {
      final success = await connect();
      if (success && _isAuthenticated) {
        return true;
      }
    } catch (e) {
      print('Reconnect attempt ${i + 1} failed: $e');
    }

    if (i < maxAttempts - 1) {
      final waitTime = delaySeconds + (i * 1);
      await Future.delayed(Duration(seconds: waitTime. clamp(2, 5)));
    }
  }

  return false;
}

Challenge 3: Windows Firewall Blocking Connections

Problem: Local testing worked, but remote devices couldn't connect.

Solution: Configured Windows Firewall rules (see earlier section) and tested with both local and remote connections.

Challenge 4: No Native JSON Parsing in UnrealScript

Problem: UnrealScript doesn't have JSON libraries.

Solution: Manually construct JSON strings and rely on the Flutter app to do all parsing. Simple protocol design meant this was actually pretty clean.

Performance and Testing

The system performs excellently:

• Connection time: ~200ms on local network
• Command response: <50ms for most commands
• Reconnection after map change: 5-10 seconds
• Memory footprint: Negligible impact on UT2004 server
• Multiple connections: Tested with 5 simultaneous clients without issues

What's Next?

Future improvements I'm considering:

• HTTPS/TLS support (challenging in UnrealScript!)
• Multiple server management in the app
• Push notifications for server events
• Server logs viewer
• Scheduled commands (automatic restarts, etc.)
• iOS build (already Flutter, just need to test)

Conclusion

This project was a blast. Bridging a 2004 game engine with 2026 mobile development taught me a lot about:

• Protocol design: Simple is better
• Connection management: Handle failures gracefully
• Cross-platform networking: TCP is universal
• Legacy code integration: Sometimes you have to work with what you've got

The full source code is available on my GitHub at SarahRoseLives/UTAdmin. Feel free to use it, modify it, or learn from it. If you're still running UT2004 servers in 2026, you're my kind of person. 🎮

Now I can kick troublemakers and change maps from my phone while I'm getting a snack. Technology is beautiful.

Tech Stack:

• UnrealScript (Unreal Engine 2)
• Flutter 3.0+ (Dart)
• TCP/IP networking
• JSON (manual construction in UnrealScript, native parsing in Dart)
• Windows 10/11 development environment

Repository: github.com/SarahRoseLives/UTAdmin

Platform: Windows (server and development), Android (app), iOS-ready

Since launching PocketDigi, it’s been incredible watching you turn your Android phones and Bluetooth TNCs into portable APRS powerhouses in the field. We’ve seen setups at parks on the air (POTA), public service events, and field days.

But we also heard a consistent piece of feedback from the community: "I want to run an iGate from my basement shack, but I can't get a GPS signal down here!"

Up until yesterday, PocketDigi had a hard requirement for a GPS lock. It needed your precise location to send out beacons and, more importantly, to authenticate with the APRS-IS servers for iGating. If your phone couldn't see the satellites, the app wouldn't fully function.

We realized that for a tool designed to be flexible, relying 100% on GPS was actually pretty limiting.

Today, we are thrilled to roll out a major update that solves this problem entirely.

Introducing Manual Location Mode

We have updated PocketDigi to allow operators to manually specify their location using the system hams already know best: Maidenhead Grid Squares.

Whether you are operating from inside a concrete convention center, a dense urban canyon, or just your home shack where GPS reception is spotty, you can now get full functionality from the app.

How It Works

We’ve kept the interface clean and simple. When you open the updated app, look at the Operation card. You will now see a new toggle switch:

1. GPS Mode (Default): This works exactly the same as before. The app actively listens to your phone's GPS sensors to provide real-time, precise location data for mobile operations.
2. Manual Mode: When you switch to this mode, PocketDigi stops listening to the GPS (which is a nice battery saver if you are stationary!).

A new text field will appear below the toggle. Simply type in your Maidenhead locator—for example, EM79 for a general location, or a 6-character grid like FN31pr for higher precision.

PocketDigi instantly calculates the lat/long coordinates for the center of that grid square and uses that "spoofed" location for all your beaconing and iGate traffic.

Why This Matters

This update significantly expands where and how you can use PocketDigi:

• Indoor iGating: Set up a bi-directional iGate from your desk to help get local RF traffic onto the internet, even if you are indoors.
• Pre-Event Setup: Configure your station settings while inside the staging area before deploying to the field.
• Stationary Operation: If you are set up at a fixed location for the day, switch to manual mode to save your phone battery by turning off constant GPS polling.

This update is available immediately. We hope this makes PocketDigi an even more valuable tool in your ham radio toolkit, regardless of where you are operating.

73, Sarah Rose AD8NT/K8SDR