TrueCombat:Elite (TCE) is a modern world total conversion of the free, popular, stand-alone third-person shooter, Wolfenstein: Enemy Territory. That is, TCE is an entirely free game, made by gamers, for gamers.

I was one of the community leaders of TeamNeelix (later GoNe), we owned a couple of game servers which were quite popular.
Unfortunately, when the mod was first released, it had some exploits and nuke vulnerabilities that could be used to crash a server.
Obviously when you own a few servers, you’re going to get targeted by people who want to harm it. So with help of the community we found out how the exploits worked.

Since TCE was a closed-source project, we needed a way of fixing it without the source code.
Fortunately the commands used to exploit were all server commands, meaning we could intercept them by a hook between the engine and the mod.

We used Quake3 Multimod(QMM) to create a plugin which checked all the commands and ignored them when it was an exploit.
The plugin would also optionally automatically ban nukers.

GameMonkey Scriptmod featured;

• 100% scriptable admin Interface
• Scriptable Rcon-like interface
• Interface for clan Members. (beside ref login)
• Interface for clan Friends. (beside ref login)
• Access to your filesystem by .gm script Functions
• Works with ALL Enemy Territory Mods (etmain/etpro/etbub/shrubmod/tce/etc.)
• Easy to modify. No C/C++ knowledge necessary.
• Change your ServerMod scriptfile without Server restart.
• Easy Script Syntax. Not as complicated as LUA.
• A lot of Script Examples.
• Fast. GameMonkey is one of the fastest script languages.
• Define your own “/” commands. Example: “/ban ID”, “/kick ID”, “drop ID”
• Create an individual gameserver mod. Personalize your Server.
• Exchange your script files with other serveradmins.
• Client to client private chat
• IRC-like channel chat

I developed this project with another developer: Apologet.
Apologet started the project and later involved me. Later we got help from im2good4u and Dr.Evil.

Four years ago, we started with the idea to create a QuakeLive clone for Enemy Territory. We thought QuakeLive did an amazing job on the following components;

• Onboarding players is easy (one simple setup),
• Having a proper player/clan/community website
• A simple server browser
• Automatically download of new content
• A simple but effective friends and chat system
• A statistics, achievement and ranking systems

Back then, the ET community was(and still is) divided over multiple ET versions, mods and suffering from ghost servers(redirect and ‘full bot’ servers). Also new players would not know what to download or which server to go to. A new centralised community combined with official servers would solve a lot of issues. And thus the idea of ETLive was born.

We quickly had a nice little prototype working with one static HTML page and a FireBreath (NPAPI) plugin. The plugin was responsible for rendering the game inside the HTML canvas and forwarding input from the browser to the game.

After that it was vital to create a login system from we could expand and implement more features. We started with a simple CakePHP page, later ASP.net and finally switched to Python with the amazing Django framework.

During the development of ETLive it became clear that Google and Firefox decided to stop supporting NPAPI plugins. We were unsure how long this would take so we kept on developing hoping one browser would still support it as an exception. In the end it was clear NPAPI would be gone forever, we had to change tactics.

By then we were already using the amazing ETLegacy project, which was an open-source, optimized Enemy Territory. One of our team members, Toni, suggested we could change the engine so it could be used as a protocol, eg. etlive://some-ip. This way we could start the game from the browser and become more like a launcher, like Battlenet.

The launcher proved to be working and we even had communication between the servers and back-end. The back-end would later run inside Docker containers thanks to help of one of our team members, Marcus.
However, due to the lack of proper project-management, too often switching technologies, lack of time and a non-coherent team, we decided to kill the project after 4 years. There was simply not enough progress or inertia to continue.
Despite the fact we had to kill the project, we did learn a lot regarding project (mis-)management, Django, EmberJS, Docker and the ET engine.

A longer blog post containing the post-mortem of the ETLive project is still pending. This will contain information about our process and what technology we used.