[FILES] DDTank server on Linux, files in commentary Binaries Source

[kaiotcp1]

[EDITED - 2026-10-06] Files of DDTANK 3.0 ported for .NET10 and Nodejs + docker for run in linux

To view the content, you need to sign in or register

this version is the same DDTank 9.2 but updated for run in linux with .net10++ and nodejs

===================


Hi everyone,

I have been working on modernizing the DDTank server stack and wanted to share how the progress is going, as well as ask if this is something the community would be interested in.


What we're doing

• Moving the server off the Windows-only setup. Center, Fighting and Road services, plus the web/request site, now run as Docker containers on Ubuntu, orchestrated with Docker Compose.
• Porting the server code from .NET Framework 4.8 to [modern .NET (10)] so it runs natively on Linux, with no Wine and no Windows VM.
• SQL Server runs in the official Linux container, using the same database with no schema rewrite.
• The web layer sits behind [Nginx] as a reverse proxy.
• Configuration comes from environment variables and a single .env file, instead of editing IPs and connection strings in a dozen config files like xml's.
• The whole stack starts with docker compose up -d.
• The client side is unchanged for now ([Flash client through the Electron launcher]).

Why

• Cost. A Windows VPS means paying a license on top of the server, and Windows itself eats about 2 GB of RAM. The same stack fits on a cheap 4 GB Linux VPS.
• Reproducible setup. Anyone who has set up DDTank knows the pain: IIS, SQL Server install, the right .NET version, IPs hardcoded everywhere. With containers the environment is identical on every machine.
• Easier maintenance. Updating means pulling a new image, rollback means going back to the previous tag, and backups are just volumes.
• Security. Services are isolated on an internal network, and only the ports the game needs are exposed.
• Longevity. .NET Framework 4.8 is in maintenance mode. Moving to a supported runtime keeps the server alive and lets us use modern tooling (CI, logging, monitoring).

Current status

It boots and runs on Ubuntu in containers, and we're testing with. It is not production-ready yet, combat, instances and shop OK, im fixing events, database tables and for last Game master panel.

I used the files from the pinned post about DDTank 9.2 on the forum, but I have about ten other DDTank versions downloaded here; I want to try migrating the interface to at least version 5.5 and add the new items introduced from version 3.1 onwards. Unfortunately, most newer DDTank versions use compiled files—and while decompiling is easy, the actual work is exhausting. The pinned 9.2 version (which is actually 3.0/3.1) provided the source files for all the interfaces, so I chose that one to start with; I even bought a version 11.2, but it didn't contain the decompiled source files or the databases—damn scammer—though I did request a refund and it was accepted. Anyway, that's the situation; let's see how it goes, haha.

Questions for you

1. Would you run a DDTank server on Linux/Docker if it were available?
2. What is your biggest pain point today when setting up or hosting a server?
3. Say something haha

Feedback, criticism and "this already exists, look here" are all welcome. Thanks!

I forgot to post images, etc..

I still haven't touched the interface translation or the Electron launcher because those are the last steps

 

[caique3211]

Hey man, good afternoon, and congrats on the thread. It's nice to finally see someone else pushing this stack forward instead of reposting the same repack from 2014.

Yes to your first question, and it's not hypothetical, I'm doing it right now.

I'm building a pixel perfect clone of 337's DDTank BR, and the whole stack has run natively on Linux since day one of the project. No Wine, no Windows VM, no Windows host anywhere. It's a plain Ubuntu VPS with Easypanel installed on top of Docker, and from there center, fight, road, the web/request site and SQL Server all run as containers. Same idea as your Compose setup, I just get a UI for deploys, logs and rollbacks. Same reasons you listed too, the Windows license plus around 2 GB of RAM doing nothing, and a setup nobody can reproduce. Starting on Linux from day one was probably the best call I made, because it dragged the old IIS era ASP.NET problems and the case sensitivity traps into week one instead of letting them wait for deploy day.

One difference worth mentioning: I kept the .NET Framework code and run it under Mono instead of porting to modern .NET. Not because it's prettier, it isn't, but it got the whole thing onto Linux without a rewrite, and I'd rather spend my weeks on protocol work than on porting. Your route is the more correct one long term. If you actually get 4.8 to .NET 10 working, that's a much bigger contribution to this community than anything I'm doing.

On the files, I hit exactly the same wall you did. Client side I use the official DDTank BR files, all the SWFs come straight from 337's live Brazilian client, since the whole point of my project is that a window has to render the same way, same assets, same layout, same numbers as the live game. Server side I pulled from several bases instead of committing to one, mainly a 14.7 CN build and a 9.2, plus a handful of other versions scattered around the internet. None of them matches the BR client on its own, so most of the work has been cherry picking: take the feature set and the packet layout that line up with the BR SWFs, rewrite the parts that don't. And yeah, the newer versions are compiled. Decompiling is the easy part, making the result behave is where the weeks disappear. Sorry about the 11.2 seller, good thing the refund went through haha.

Which kind of answers your second question too. My biggest pain point isn't the install, it's the mismatch between a server build from one generation and a client from another. Everything boots, everything looks fine, and then the client just sits at 100% with no error at all. My favourite one so far: the server wrote a FightPower field as a 64 bit Long, the client read it as a 32 bit Int, and every field after it in the packet shifted. That one cost me weeks. If you're mixing a 9.2 base with 5.5 era interfaces, I'd plan for that class of bug to eat most of your remaining time, not the events or the GM panel.

I've had login, hall, PvP, PvE instances, guild, shop, bag, forge, dailies and quests working for a while now, so the approach does hold up. Happy to compare notes on packet layouts between versions if that's useful to you, it's the part nobody has documented and right now we're both paying for it separately.

Also, since the forum only lets me attach 5 images at a time, I took a few more screenshots of my build and dumped them all in a Drive folder instead:

To view the content, you need to sign in or register

Good luck with it.

Caique

 

[kaiotcp1]

Hey man, good afternoon, and congrats on the thread. It's nice to finally see someone else pushing this stack forward instead of reposting the same repack from 2014.

Yes to your first question, and it's not hypothetical, I'm doing it right now.

I'm building a pixel perfect clone of 337's DDTank BR, and the whole stack has run natively on Linux since day one of the project. No Wine, no Windows VM, no Windows host anywhere. It's a plain Ubuntu VPS with Easypanel installed on top of Docker, and from there center, fight, road, the web/request site and SQL Server all run as containers. Same idea as your Compose setup, I just get a UI for deploys, logs and rollbacks. Same reasons you listed too, the Windows license plus around 2 GB of RAM doing nothing, and a setup nobody can reproduce. Starting on Linux from day one was probably the best call I made, because it dragged the old IIS era ASP.NET problems and the case sensitivity traps into week one instead of letting them wait for deploy day.

One difference worth mentioning: I kept the .NET Framework code and run it under Mono instead of porting to modern .NET. Not because it's prettier, it isn't, but it got the whole thing onto Linux without a rewrite, and I'd rather spend my weeks on protocol work than on porting. Your route is the more correct one long term. If you actually get 4.8 to .NET 10 working, that's a much bigger contribution to this community than anything I'm doing.

On the files, I hit exactly the same wall you did. Client side I use the official DDTank BR files, all the SWFs come straight from 337's live Brazilian client, since the whole point of my project is that a window has to render the same way, same assets, same layout, same numbers as the live game. Server side I pulled from several bases instead of committing to one, mainly a 14.7 CN build and a 9.2, plus a handful of other versions scattered around the internet. None of them matches the BR client on its own, so most of the work has been cherry picking: take the feature set and the packet layout that line up with the BR SWFs, rewrite the parts that don't. And yeah, the newer versions are compiled. Decompiling is the easy part, making the result behave is where the weeks disappear. Sorry about the 11.2 seller, good thing the refund went through haha.

Which kind of answers your second question too. My biggest pain point isn't the install, it's the mismatch between a server build from one generation and a client from another. Everything boots, everything looks fine, and then the client just sits at 100% with no error at all. My favourite one so far: the server wrote a FightPower field as a 64 bit Long, the client read it as a 32 bit Int, and every field after it in the packet shifted. That one cost me weeks. If you're mixing a 9.2 base with 5.5 era interfaces, I'd plan for that class of bug to eat most of your remaining time, not the events or the GM panel.

I've had login, hall, PvP, PvE instances, guild, shop, bag, forge, dailies and quests working for a while now, so the approach does hold up. Happy to compare notes on packet layouts between versions if that's useful to you, it's the part nobody has documented and right now we're both paying for it separately.

Also, since the forum only lets me attach 5 images at a time, I took a few more screenshots of my build and dumped them all in a Drive folder instead:

To view the content, you need to sign in or register

Good luck with it.

Caique

Good afternoon man, and thanks — this is the reply I was hoping the thread would get. Someone
actually running it, not theorizing about it.

On Mono vs. porting: I don't think your call was wrong. You optimized for the thing that
actually matters (protocol work), and Mono buys you Linux without a rewrite. I went the other
way mostly because I wanted the container image to be a plain
mcr.microsoft.com/dotnet/runtime with no Mono layer to debug at 3am, and because I was
already going to have to touch every file for other reasons. Different bets, same
destination.

Where I actually am

Two trees, and it's worth separating them because they taught different things.

Tree 1 — Gunny92, a 3.0-era base. This is the one that's done, and it was the laboratory.
Thirteen C# projects, all multi-targeted net48;net10.0 so I could diff behavior between the
two legs on the same source. Center, Fight and Road all run in containers now. The
interesting part wasn't the compiler — it was everything that compiles fine and then quietly
does nothing on Linux:

- System.Drawing.Common throws on non-Windows in .NET 6+. Had to audit every GDI+ call: some
were dead code (anti-bot CAPTCHA generation, GM panel icons), some got pinned to the net48
leg, and the one that actually runs at startup got ported to SkiaSharp.
- Every reference type that's resolved by string at runtime. ScriptMgr.CreateInstance reads
class names out of the database and returns null silently when it can't find them — NPC AI,
bosses, PvE and quests all hang off that. PublishTrimmed=false is mandatory or you lose
all game AI with zero errors and zero log lines. Same trap for anything reflected via
GetTypes() — there were 15+ dispatchers doing that.
- Case sensitivity, as you said. Week one, exactly as you predicted.
- An ApplicationLog class that shipped every SQL error to the Windows Event Log inside an
empty try/catch. On Linux that's a silent black hole. Replaced with log4net.
- WCF: the client side is easy (System.ServiceModel.* packages), the server side isn't —
ServiceHost doesn't exist in modern .NET. CoreWCF 1.9.1, hosted in the executable, solved
it.

I also moved the whole legacy ASP.NET WebForms request layer (105 endpoints) to a TypeScript
API, endpoint by endpoint, diffing against the real IIS one.

Tree 2 — the one labeled "12.6", which is a lie. It's actually 11.5.9. It's in a string
literal in the code itself, only visible after deobfuscation: Console.Title = "DDTank
[11.5.9] [Road] ", and it prints 游戏版本:11.5.9 on startup. The folder keeps the 12.6 name
only so I don't break paths. Worth knowing if you're shopping for bases — the folder name a
seller gives you is not evidence of anything. I determine version by capability now, never by
name.

This one shipped as binaries only — no source. So: decompile, then rebuild into a compiling
tree. 4,359 files, 211 errors across 4 files at the start. Those are zero now. Eleven
projects compiling clean on both net48 and net10.0, and as of today the Center is up in a
container with all its configuration coming from environment variables — 435 config keys,
including the 411 that weren't in any .config file to begin with. No sed in any Dockerfile;
config injection happens in code before the first config read.

The Gunny92 tree is what made that fast. Everything I listed above I had already hit once.

On your FightPower bug — 64-bit Long written, 32-bit Int read, every subsequent field in the
packet shifted. That is a genuinely excellent war story and I'm stealing the lesson. My
equivalent measurement for why I stopped trying to backport features: the Gunny92 client's
language.txt has 3,948 keys and zero memoryGame.* entries. The 12.6 one has 9,078. I spent
real time moving server-side features across before admitting the client simply doesn't have
the screens to render them. Reverted the whole thing and flipped the direction: port the
11.5.9 tree, keep Gunny92 as the reference implementation.

So yes — I'd very much like to compare packet layouts. That's the one thing neither of us can
Google, and it's the thing that makes the difference between "it boots" and "it plays."

On the files: since you were straight with me about your sources, here's mine. The 11.5.9
("12.6") build I'm working from — pulled off a Chinese VM image — is here: [

To view the content, you need to sign in or register

]

Im using claude code for this job..
call me in linkedin > hpkaio and i send my discord for you

 

[caique3211]

Hey man, thanks for sharing the 11.5.9 files! I’ll take a closer look and see what I can extract from them to use in my project.

I tried finding you on LinkedIn but couldn’t find your profile. Here’s mine so you can reach out:

To view the content, you need to sign in or register

Feel free to connect with me there, and we can keep in touch, exchange ideas, and share our progress. Sounds good?

 

[levanhau03]

Hi everyone,

I have been working on modernizing the DDTank server stack and wanted to share how the progress is going, as well as ask if this is something the community would be interested in.


What we're doing

• Moving the server off the Windows-only setup. Center, Fighting and Road services, plus the web/request site, now run as Docker containers on Ubuntu, orchestrated with Docker Compose.
• Porting the server code from .NET Framework 4.8 to [modern .NET (10)] so it runs natively on Linux, with no Wine and no Windows VM.
• SQL Server runs in the official Linux container, using the same database with no schema rewrite.
• The web layer sits behind [Nginx] as a reverse proxy.
• Configuration comes from environment variables and a single .env file, instead of editing IPs and connection strings in a dozen config files like xml's.
• The whole stack starts with docker compose up -d.
• The client side is unchanged for now ([Flash client through the Electron launcher]).

Why

• Cost. A Windows VPS means paying a license on top of the server, and Windows itself eats about 2 GB of RAM. The same stack fits on a cheap 4 GB Linux VPS.
• Reproducible setup. Anyone who has set up DDTank knows the pain: IIS, SQL Server install, the right .NET version, IPs hardcoded everywhere. With containers the environment is identical on every machine.
• Easier maintenance. Updating means pulling a new image, rollback means going back to the previous tag, and backups are just volumes.
• Security. Services are isolated on an internal network, and only the ports the game needs are exposed.
• Longevity. .NET Framework 4.8 is in maintenance mode. Moving to a supported runtime keeps the server alive and lets us use modern tooling (CI, logging, monitoring).

Current status

It boots and runs on Ubuntu in containers, and we're testing with. It is not production-ready yet, combat, instances and shop OK, im fixing events, database tables and for last Game master panel.

I used the files from the pinned post about DDTank 9.2 on the forum, but I have about ten other DDTank versions downloaded here; I want to try migrating the interface to at least version 5.5 and add the new items introduced from version 3.1 onwards. Unfortunately, most newer DDTank versions use compiled files—and while decompiling is easy, the actual work is exhausting. The pinned 9.2 version (which is actually 3.0/3.1) provided the source files for all the interfaces, so I chose that one to start with; I even bought a version 11.2, but it didn't contain the decompiled source files or the databases—damn scammer—though I did request a refund and it was accepted. Anyway, that's the situation; let's see how it goes, haha.

Questions for you

1. Would you run a DDTank server on Linux/Docker if it were available?
2. What is your biggest pain point today when setting up or hosting a server?
3. Say something haha

Feedback, criticism and "this already exists, look here" are all welcome. Thanks!

I forgot to post images, etc..

I still haven't touched the interface translation or the Electron launcher because those are the last steps


View attachment 310755
View attachment 310756
View attachment 310757
View attachment 310758

Could you share the source code? I'm also seriously looking into it.

 

[kaiotcp1]

Could you share the source code? I'm also seriously looking into it.

Certainly; I’ve compressed the files into a ZIP archive and made them available at this link.

Basically, the package contains the decompiled .NET 10 code, a Node.js API, and a desktop launcher built with Electron. I’ve included a basic README file with instructions; with the help of an LLM, you can easily set up and run the environment using Docker Compose, test it, make any desired improvements, and build the source code within Docker.

I know there are still unresolved bugs, as I’ve shifted my focus to a newer version and am also migrating the ActionScript code to a new technology.

The .bak files are also included in the WinRAR archive, and only the README.md is in Portuguese—though it’s easy to translate...