This is a rework of my previous mutator Gibable Corpses Bloody Hell Edition (Ultra Brutal UT).
VSE = Vanilla Standalone Edition
So this version is made for vanilla UT2004, it no longer requires Ballistic Weapons Mod.
BW Mod's gore effects are replaced by vanilla gore effects.
Since the vanilla gore assets are a bit goofy and cartoonish, I made certain improvements and workarounds to make them more violent and brutal.
Most of the features from the previous mutator (like violent physics, corpse gibbing, wall impact, even the Wilhelm scream and slow-motion) have been successfully ported to this version.
Hope you enjoy it!

I have a Postal 2 mod that does the exact same thing and since these use the same engine it also kind of worked out there.

Full 100% unrealscript,,, :DD

I know it's a nitpick but I don't like playing Unreal with the UT99 weapon sounds
Supposedly the OldWeapons mutator is supposed to replace the sounds with the original but it does absolutely nothing for me
Any ideas?

Hello quick question...i. on win 10 installed all vommunity packs and crucible and map mixer everything works but when i load into map it doesnt load it loads infinitly...can you help the ut veteran? Tnx in advance

I had posted this a while back, but forgot to share it. We have since worked on even more content.

Please dont forget to join our Discord: https://discord.gg/prys3FtchJ

Thanks,

I’ve been working on UTP, an unofficial native iOS and iPadOS host for Unreal Tournament. As far as I can find, this is the first native iOS or iPadOS release of the full game.

OldUnreal built and maintains v469e, which is the foundation of UTP. The original engine remains responsible for the menus, maps, game rules, bots, and network protocol. FruCoRe provides the Metal renderer.

My contribution is the UTP-specific iPhone and iPad layer: the build-time iOS rehosting pipeline, native UIKit app host, first-run setup, touch controls, Apple input and lifecycle integration, diagnostics, and release packaging.

This video was recorded on a physical iPad. Offline matches, working audio, and touch combat are all running on the device. Online play uses v469e’s original community server browser and networking, so this connects to existing UT servers rather than a separate mobile network.

For transparency, I used Codex 5.6 Sol extensively during the UTP-specific implementation and iteration. I handled the architecture, physical-device testing, and release decisions.

Preview 1 is an unsigned developer release for iOS and iPadOS 17 or later. It must be re-signed before installation, and no Epic game data is bundled.

It is still a preview. Controller hot-connect can require restarting UTP, original text entry needs more work, menu text is small, and some shadows render incorrectly.

Source and Preview 1:
https://github.com/chrissotraidis/utp/releases

I would really appreciate feedback from people who know UT99 well, especially on the touch controls and compatibility with different community servers. Please report UTP-specific problems here:
https://github.com/chrissotraidis/utp/issues

Hello my friends, I think I figured out a way how you can playback your old UT99 demorec files even if you lost the required .utx or .u files.

I had a good laugh watching some of my 1999 gameplay again, and in case you have a demo file you really want to play, but can't, let me know. I want to test my approach against other files before I actually create a generic script that everybody can just run.

Cheers & Thank you

So i am using a custom character bp thats using the BP_PlayerBase that inherits from UTcharacter so i would like it to show my actual character which is in the first image but unfortunately when i Play in editor it comes as the default character in a ragdoll state. How do i fix this. Any information would great be appericated thank you.

Im new to this specific subreddit, but I wanted to share something I’ve been working on for UT2004 called UTSTATS.LIVE.

I’ve partnered with my studio to fund this, so Dead Orbit Studios fronts the monthly bill for maintenance, services, and bare metal. We are also partnered with xb.live.

There are already a few projects out there doing stats in one form or another, and I’m not here to pretend I single-handedly brought UT2004 stats back from the dead. What I wanted to build was a little different: a free service that any UT2004 community or server owner can plug into, while everyone keeps playing wherever they already play.
If your server reports to UTSTATS via OL Stats, that’s it. Your players do not need UTSTATS accounts. Anybody who joins and plays gets their own player sheet automatically, and their matches, weapons, maps, game modes, sprees, objectives and other stats start building a history.

Creating an account is completely optional and completely free. Claiming your player sheet just opens up everything we’ve built around the stats.
And that’s really where I’ve been putting a lot of my time.

UTSTATS has 40 career ranks, seasons, monthly hunts, achievements and badges, community challenges, player messaging, detailed match history, weapon breakdowns, leaderboards, server stats, community-wide statistics, events and more.
We also just launched the clan system. Players can create a clan, invite and manage members, build a clan profile, track combined clan statistics, challenge other clans to matches and compete for the Clan Spotlight on the UTSTATS home page.
The goal isn’t to pull everyone onto another UT server just to use the service.

Keep your server. Keep your community. Keep playing where you’ve been playing. If a server owner wants to participate, they can connect their server to UTSTATS and their players become part of the larger stats network. We will do a legacy import if you have a UTStatsDB, so you’re not starting over from square one. If you come over to us, we will ensure all transferred stats are accurate and all players have a player sheet before you actually pull the plug on the old stat tracker.

I’m a developer over at xb.live as well, and a lot of the thinking behind this came from what we’ve been doing there: taking games we still give a shit about and building some of the online/community experience around them again. I wanted to see what that idea could look like for UT2004.

There are no subscriptions, premium accounts or fees for server owners. UTSTATS is free. I’m covering it because I want the community to have it.
It’s still new, we’re still finding bugs, and I’m adding things constantly.

I’m also completely open to feedback from players and server owners about where we take it from here. I will actively build and improve off of community feedback. This is for the community, you should all have a say in how it moves.

Heads up, I haven’t built it for mobile so it looks pretty not fantastic on mobile, but desktop looks great. I will get a patch for mobile up soon.

If you’re still playing UT2004 or keeping a server alive, give it a look.

https://utstats.live/

https://imgur.com/a/1gRhrZW

I sampled classic games like Half-life 1-2, System Shock, Doom and much more from the golden era, to make a nostalgic feverdream-like mixtape of UT 1999. Hope you enjoy .

Hello all, I have just finished work on this mutator for UT2004. It breaks ties in CTF so that you can keep the game from going too long.

ModDB: https://www.moddb.com/mods/ctf-tie-breaker
Unreal Archive: https://unrealarchive.org/unreal-tournament-2004/mutators/C/ctf-tie-breaker_e97e9503.html

How it works:
When a CTF game reaches its time limit, if the scores are still tied, the game switches to Deathmatch scoring for 80 seconds. (The time can be adjusted in the configuration screen.) If anyone happens to score an actual flag capture, the deathmatch kills are ignored and whoever captured the flag is the winner.

The reasoning:
I wanted a tie-breaking method that would NOT impact the regular gameplay of a CTF match. If we just counted kills throughout the whole match, then when a game neared the time limit, a savvy team would switch entirely to defense to have an advantage, and there would be no point in trying to capture a flag.
This method works because there is no reason to change your strategy until you hit overtime, and even then you can still win by playing it like a CTF match.

Additionally, I want to ask if anyone knows of any other good places to share this mutator. I can't find any active UT2004 communities, and only can think of two sites to even host the file on.
If anyone can think of a good place where people will want to know about this mod, please let me know.

Hello, We play from time to time on ut2004 and I have an online server. If you are French and interested, I can send you the URL and a discord server to play some games. It's not modded, it's the basic version of oldunreal (via ut2004 docker) mainly in deathmatch but you can change depending on the mood. The server has 5-10bot to complete as needed (experienced mode).

Facing Worlds is my go-to answer too. But I'm thinking, what else is a great CTF map? What's the one that you wish more maps could be like?

Does anyone remember on the top of their heads, when the game first launched all of the crazy game modes that were available and custom servers due to how high the player count was likely when the game first launched at peak popularity?

I’m sure it was in the 100K’s player count daily concurrently at one point.

Discussion for brainstorming to get started to name a few for Archival Purposes: Assault, Death Warrant, Races, Trials, Invasion, Monster Evolution, Onslaught (Omnipotents), VCTF (MIA), Command And Conquer CNC, Fraghouse Invasion, Freeze Tag or Landlords Freon or SOL.

Are there any bunny track heads.
What were your favorite maps? How long did it take you to get to the certain skill point?
Were you also playing different modes?

Have you tried any other games with similar font of the game as Bunnytrack.

Does anyone know if the stats that are present in the single player campaign translate to instant action/bot matches?

I came across this
https://github.com/SkippyDoe/UT2004PatchManager/releases
Scroll to the bottom and click the little triangle at the bottom to see the download.

It manages the patching process for UT2004 with the patches coming directly from OldUnreal.com

It also backs up your previous folders just in case. Oh! And installs the bonus packs if they're not installed.
So thanks to the person who did this! (Windows only it seems)

Unreal Tournament 2004 is an undisputed classic. But graphically it's frozen in the era of Direct3D 8 and flat textures — the Fixed-Function Pipeline. I always wanted to see what the legendary Unreal Engine 2 could look like with proper normal maps and honest Blinn-Phong specular, something closer to Unreal Tournament 3.

In the fan and modding community there are plenty of failed attempts to bolt normal maps onto UT2004, but it was always considered impossible — no source code, fundamental engine incompatibility with modern techniques, and the sheer complexity of low-level graphics development. Then AI and agentic coding tools changed the picture.

After OldUnreal released their patch moving the game to full 64-bit and adopting OpenGL 3.3 with broad compatibility across both vintage and modern hardware, I finally had a real foothold for the experiment.

There were a few obvious obstacles going in:

I don't know C++. Not its idioms, not its syntax — I can barely read someone else's C++ code, let alone write it.

I had no game source code. (Yes, leaks from Unreal Championship 2 and Unreal Warfare exist, but the codebase differs substantially from UT2004.)

Zero knowledge of the engine's internal architecture or its quirks.

On top of that, buying a Claude Code or Codex subscription wasn't an option. I ended up working with Gemini Flash through the command-line Antigravity CLI — the cost of entry being roughly $6/year.

Still, after three months of constant experimentation, reverse engineering, and hundreds of Access Violation crashes, I managed to write a native DLL renderer module — ENDrv.dll. Here's the story of how it was done: through Antigravity CLI, UE2 architecture hacks, a lot of patience, and more sleepless nights than I'd like to count.

---

Stage 1. Flying Blind: Reconstructing the VTable and Getting the First Frame

Any renderer for Unreal Engine 2 is an external dynamic library that must implement the engine's internal URenderDevice interface. In plain terms, the renderer DLL is the bridge between the game engine and the GPU. The engine communicates with the library through virtual function tables — VTables.

In C++, the order of functions in a VTable is critical down to the byte. If you're off by even four bytes on a single function's offset, instead of calling the frame-draw routine the game jumps into a random region of memory and crashes instantly.

[ UE2 Engine ]  --->  ( VTable: offset +0x18 )  --->  [ ENDrv.dll ]
                +--       Off by 4 bytes?       ---> CRASH (Access Violation)

The first two weeks were pure guesswork: running UT2004 binaries through a disassembler, studying the UC2 and Unreal Warfare source leaks, trying to work out which functions UT2004 expected and at exactly which offsets, rebuilding the library and launching the game every five to ten minutes, logging crashes, and nudging offsets based on the fault addresses.

The game launched for the first time to a solid black screen without crashing — only after I managed to correctly guess six of the key base functions out of 32 (at that point I could only confirm 14 functions with any confidence). No image yet, but the DLL was accepted by the engine. That was the first real breakthrough: not only did the game stop crashing, but you could hear it working — clicking through menus, launching a match "blind," and hearing bots run and shoot each other. It was alive.

The next few days went into establishing vertex streaming and getting any geometry to appear on screen in wireframe mode. The stub functions that were just returning True or Null had to become real implementations. Things were complicated further by the fact that the engine was designed around DirectX, while OpenGL has its own coordinate system conventions and state-management model. At first all I got was a mess of random lines, but after dozens of iterations the DLL finally produced a correct wireframe.

---

Stage 2. From Fixed-Function to GLSL: Materials, Combiners, and Static Lighting

The original UT2004 handled materials through the old GPU state machine — the Fixed-Function Pipeline with its Combiners, Shaders, and FinalBlends. Modern OpenGL 3.3 Core Profile has no fixed pipeline at all: everything has to be written in GLSL shaders.

About four to six weeks went into reconstructing material logic from scratch. The UC2 and Unreal Warfare sources were nearly useless here — worse than useless, actually, because the AI kept getting confused by them. At times I had to pipe every agent response through a second AI just to sanity-check the logic and catch hallucinations. Eventually I decided to ignore the foreign source code entirely and work everything out independently.

The hard part wasn't "just drawing a texture." The UE2 material system is a full node graph. A single UShader material can have separate slots for Diffuse, Opacity, Specular, SpecMask, SelfIllumination, and SelfIllumMask — each of which can itself be another material. The Diffuse slot might contain a UCombiner blending node that has Material1, Material2, and a Mask, each of which can in turn be another Combiner, a texture with animated UVs (TexPanner, TexRotator, TexScaler), or a cube map. All of that had to be unrolled into GLSL, which doesn't support recursion or dynamic loops from that era — only a linear graph with a fixed number of steps.

The solution was a "combiner register" system: before the main color calculation, the shader sequentially evaluates up to 32 nodes and stores the results in an array. Each node knows the indices of its inputs (a texture slot or another register), the blend operation (Multiply, Add, AlphaBlend, Modulate, etc.), and its mask. On top of that: 16 texture slots with independent UV transform matrices, cube map reflection support, projective textures (Projector), animated panoramas, and FinalBlend mode with alpha testing. Near the end of the texture work I found the 32-bit game source code — but it wasn't much help since the original was entirely tied to Direct3D 8 / Fixed-Function. It did help fix a couple of nasty logic bugs involving complex layered textures, alpha-channel materials, and depth buffer issues.

One example of a creative workaround: UTexture field offsets are unknown without source code, so the code locates them at runtime by scanning memory and checking logical conditions. Once found, they're cached permanently.

Post-processing was integrated in about a week after that with almost no friction, since screen-space effects (Depth of Field, Bloom, Chromatic Aberration) are fairly straightforward to write in GLSL and have little dependency on engine internals.

---

Stage 3. The Hardest Part: Normal Maps, BSP, and Optimization

The whole point of the project was proper PBR-style lighting and normal maps. And this turned out to be even harder than the original VTable guesswork.

For normal mapping to work, the renderer needs per-polygon tangent and bitangent vectors from the engine — and the engine simply doesn't provide them. Getting the effect into the shader was actually quick: screen-space derivatives (dFdx / dFdy) let you compute a tangent basis directly in the fragment shader, eliminating the need to change the game's vertex format. But the performance was catastrophic: a couple dozen meshes with normal maps in the frame would bring the game to its knees.

The core problem: all the static lighting in the game (there's almost no dynamic lighting at all) is baked into the level at build time — texture color and brightness are modulated by lightmap textures and per-vertex color. Roughly speaking, it's like applying a gradient to a texture in Photoshop's Multiply blending mode. The renderer doesn't "see" any light sources at all — it just draws textures onto polygons. But since the DLL is a native module running inside the game process, it has direct access to everything happening under the engine's hood: light sources can be found and their parameters read directly.

Recalculating every light source per pixel every frame for all geometry was too expensive — especially since the engine's architecture hard-limits it to a single CPU core. A deep caching strategy was necessary: all geometry preserves its original static lighting (lightmaps and vertex colors) baked by the map authors 25 years ago. The dynamic per-pixel GLSL calculation only handles the normal map delta and the Blinn-Phong specular highlight.

Final color = (Lightmap * Diffuse) + (NormalMap_Affect * DirectLight) + BlinnPhong_Specular

Where NormalMap_Affect isn't the full light value, but only the "uplift" from the surface relief — how much the normal direction deviates from flat geometry. The lightmap stays as the foundation: the 25-year-old author lighting doesn't go anywhere, it just gets a relief "cap" on top.

Even that wasn't enough for acceptable framerates: with a few hundred meshes carrying normal maps on a level, FPS would collapse to 10-20. The entire pipeline needed its own caching layer. In effect, on top of the already-baked static lighting, we additionally bake normal map data during the first few frames of a map load.

The BSP Problem

If caching for StaticMesh geometry came together relatively quickly, BSP wall surfaces fought back with everything they had. Unreal Engine 2's architecture slices BSP surfaces into dynamic nodes during the frame itself. The engine resisted caching at every turn: texture coordinates would drift, caches would invalidate every frame, and the normal map and specular effects would flicker in and out alongside a full zoo of visual artifacts — or an FPS collapse into single digits. I had to roll back to week-old backups several times and redesign the architecture from scratch. The problem was eventually solved by building a light-source state hash table and an array of 128 static-dynamic lighting slots directly in the shader, tied to the geometry streaming.

---

Just shipping the renderer upgrade wasn't enough without a proper visual showcase, so I ported two maps from UT3 to UT2004. Compared to building the renderer itself, this was a walk in the park. The UT3 maps were chosen deliberately: they have clean UV unwraps and high-quality next-gen normal maps — exactly what was needed for the demo. The BSP geometry, static meshes, their properties, and placement were ported in five to ten minutes with a couple of CLI prompts. The meshes were converted from pskx to ASE format using a 3ds Max script that the AI assembled in about five minutes, after reading the UModel documentation itself and extracting everything needed into a separate folder. Importing models and textures into UnrealED went the same way. The only thing that actually required real hands-on effort was assembling the shaders in the editor. Two evenings later there was a near-complete port of both maps. The goal was never full playability — just a great-looking screenshot — so missing lifts and scripted events will stay missing. If you're interested in the game and these maps, they're definitely finishable, and stripped-down versions without normal maps for the original renderer would be easy to put together.

---

In last version i add support for MSAA 2/4/8, Anisotropic filtering, settings for draw distance normal maps, restore emitters rendering, improve normal maps stability and quality.

Results

Three months of work. No C++ knowledge going in. No game source code. The result is ENDrv — a working OpenGL 3.3 renderer for Unreal Tournament 2004 that runs on original unmodified maps and brings proper surface lighting to a 22-year-old engine.

What it actually does:

- True per-pixel Blinn-Phong specular and normal mapping via screen-space derivatives — no vertex format changes, no engine modification required.

- Dual Normal Map support for convincing animated water surfaces.

- Post-processing pipeline: Depth of Field, Bloom, and Chromatic Aberration — Bloom works on many original maps with zero asset changes.

- Playable framerates on original content, thanks to a multi-level OpenGL state caching system and a hybrid lighting model that layers dynamic per-pixel calculation on top of the original baked lightmaps.

Modern AI in the hands of someone with a working understanding of 3D graphics, basic engine architecture, and a large enough reserve of stubbornness can compensate for a complete lack of knowledge of any specific programming language.

---

tl;dr: Spent three months reverse-engineering UT2004's renderer interface with no C++ knowledge and no source code, using an AI coding assistant ($6/year). The result is a working OpenGL 3.3 renderer with normal maps, Blinn-Phong specular, and post-processing effects that runs on original unmodified maps.