A Dev Journal: Porting the Metin2 Server to .NET and Modern Technologies

[alteredcode 2]

Hello M2Dev,

I’m opening this thread as a public dev journal for something that started as a “small modernization idea” and, as usual with Metin2, instantly turned into a rabbit hole with teeth.

The short version:

I’m trying to port/rebuild the Metin2 server side into a modern .NET/C# stack, with the long-term goal of creating a proper framework for building and managing Metin2 servers faster, cleaner, and with modern tooling.

Not just “compile old files and pray to the FreeBSD gods.”

Not just “change some TXT files, restart channel, crash, cry, repeat.”

The idea is to create a modern foundation where server owners and developers can eventually manage things like:

• drops
• spawns
• shops
• items
• NPCs
• events
• server settings
• gameplay configuration
• logs
• accounts
• characters
• economy tools

from a proper visual control center / web dashboard, instead of manually spelunking through .txt, .sql, random config files, ancient scripts, and whatever else the Metin2 gods decided to scatter around the filesystem in 2008.

Basically:

Metin2 server development, but without needing to become a monk in a FreeBSD cave.

 

What this project is

This is a dev journal about building a modern Metin2 server framework.

The first big milestone is client compatibility:

Can we make the original Metin2 client talk to a modern .NET server stack?

If yes, then the next question becomes much more interesting:

Can we build a full modern backend around that compatibility layer?

 

That means:

• .NET/C# services
• modern protocol layer
• clean domain models
• safer persistence
• better testing
• GitHub-managed development
• WSL/Linux development instead of old FreeBSD-only deployment
• eventually a web-based configuration/admin center

The final dream is not just “a server that runs.”

The final dream is a framework where spinning up and configuring a Metin2 server is faster, safer, and less disgusting.

Because let’s be honest: half of Metin2 development is not “development.”
It is archaeology with a compiler.

 

What this project is NOT

This is not a release thread.

This is not a “download my serverfiles bro” thread.

This is not a fake “100% working source” post with three screenshots and a broken Mega link.

This is not me claiming I already replaced the whole server.

I will document progress honestly: what works, what breaks, what crashes, what is only synthetic-tested, and what works with the real client.

If something is broken, I will say it is broken.

If something is ugly, I will say it is ugly.

If something makes me question my life choices, I will probably post that too.

 

How this started

The original idea was not actually “let’s rewrite Metin2.”

The original idea was much simpler.

I had a Martysama 5.8-based source tree and I was thinking about modernizing the server side.

At first, the idea was:

“Maybe I can build a modern dashboard around the existing server.”

Something like a configuration center where you could visually edit drops, spawns, shops, items, events, etc.

A tool for people who are tired of jumping between database tables, TXT files, proto files, server configs, and 300 tabs of old forum posts.

Then the idea became:

“What if the old server is not the center anymore?”

And then, because apparently I enjoy suffering:

“What if we port/rebuild the server side itself into .NET?”

So now the project has become:

1. Understand the original server/client protocol.
2. Rebuild the server stack in modern .NET.
3. Keep compatibility with the existing Metin2 client.
4. Replace old runtime assumptions step by step.
5. Build a modern framework around it.
6. Later, build the visual control center on top.

Very reasonable.

Very normal.

Absolutely not insane.

 

The AI goblin in the basement

I’m also using an AI coding agent called Hermes for this.

Why?

Because I am, professionally speaking, a lazy fuck.

But the useful kind.

The idea is not “AI magically rewrites Metin2 overnight while I drink coffee.”

The idea is:

• I give Hermes big project goals.
• Hermes inspects the old C++/client/server code.
• It maps packet structures.
• It writes tests.
• It ports pieces into .NET.
• It commits/pushes to GitHub.
• I test the real client when needed.
• Then we fix the next explosion.

So this is also part of the experiment:

How far can a human + AI agent push a disgusting legacy MMO server into a modern architecture?

Maybe it becomes something serious.

Maybe it becomes a beautiful corpse.

Either way, it should be useful to document.

 

Current direction

The server is being rebuilt as a modern stack.

The direction is roughly:

Original Metin2 Client

↓

Protocol Compatibility Layer

↓

Modern .NET Auth/Game Services

↓

Modern Domain Model

↓

Modern Persistence

↓

Future Web Configuration Center

 

The old client compatibility is important.

The old database schema is not sacred.

The old FreeBSD dependency is not sacred.

The old architecture is not sacred.

The client experience is the compatibility target.

Internally, the server can become modern.

 

Why I’m posting this publicly

Three reasons.

1. Accountability

If I document it publicly, I’m less likely to abandon it when packet.h starts whispering demonic things at 3AM.

2. Feedback

M2Dev has people who actually understand weird Metin2 internals.

Packet order, client quirks, phase transitions, empire select behavior, item windows, old cryptography nonsense — all the stuff that looks simple until the client instantly closes without a syserr.

If someone has knowledge, I want this thread to become a useful place to collect it.

3. Proof over hype

If this becomes something big later, I want the history to be visible.

Not “trust me bro, I built a framework.”

But:

Here is the journal.
Here are the crashes.
Here are the fixes.
Here is the progress from zero to something real.

That matters.

Because in this scene, everyone has “the best files.”

Very few people show the work.

 

How updates will work

I’ll keep this first post updated with collapsible dev logs.

Each major update will also be posted as a separate reply, so the thread can be followed chronologically.

The format will be something like:

Update #001 — AuthServer talks to the client Update #002 — Character select stops exploding Update #003 — EnterGame crashes, obviously Update #004 — Items now move without duplicating like a casino exploit ...

I’ll include:

• what was attempted
• what worked
• what broke
• real-client test results
• synthetic test results
• screenshots/logs when useful
• architecture decisions
• funny disasters, because this is Metin2

 

Update index

Update #000 — The idea: from Martysama files to a modern framework

Spoiler

The project started from a Martysama 5.8-based source tree.

At first, the idea was to create a modern dashboard around the existing server. Something visual, where server owners could configure drops, spawns, shops, events, items, and other gameplay data without manually editing TXT files and praying.

Then the idea expanded.

Instead of only building tools around the old server, I decided to try rebuilding the server side itself into a modern .NET stack while keeping compatibility with the original Metin2 client.

The long-term target is a framework for creating and managing Metin2 servers faster, with modern development practices and a future web configuration center.

This is not a release yet.

This is a public dev journal documenting the attempt.

Update #001 — Why .NET?

Spoiler

The goal is not to shove Metin2 into ASP.NET controllers like a monkey with a keyboard.

The game server itself needs dedicated TCP/game services, packet handling, sessions, phases, world state, runtime entities, and proper protocol compatibility.

ASP.NET makes sense for the admin/control/web side.

.NET/C# makes sense for modern services, domain models, testing, tooling, and maintainability.

The target is:

• AuthServer as a dedicated service
• GameServer as a dedicated service
• Shared protocol library
• Shared domain model
• Persistence layer
• Future Admin/API/Web configuration center

The idea is to modernize the internals without breaking the old client.

Update #002 — Hermes enters the dungeon

Spoiler

I’m using Hermes, an AI coding agent, to help with the boring and painful parts.

It reads old C++/client/server sources, maps packets, writes tests, ports pieces into C#, commits to GitHub, and generally does the kind of work that makes normal people close the IDE and go outside.

This does not mean “AI solved Metin2.”

It means I’m using an AI agent as a very fast junior developer who never sleeps, but also occasionally needs to be slapped with very precise goals.

Current workflow:

1. Give Hermes a big target.
2. It inspects source.
3. It ports a vertical slice.
4. It writes tests.
5. I run/verify real client behavior when needed.
6. We fix the next weird client expectation.

So far, this has been surprisingly useful.

Update #003 — Current technical state

Spoiler

The modern stack has already reached a synthetic test state where several important pieces exist:

• encrypted AuthServer flow
• AuthServer to GameServer handoff
• GameServer login
• character list/create/delete/select
• EnterGame bootstrap
• early world visibility
• inventory/equipment bootstrap
• item move/equip/unequip
• item drop/pickup
• minimal movement
• minimal chat

Important word: synthetic.

That means automated tests and local protocol simulations pass.

The real client has also been tested, and it reached account/character flow far enough to create a character/account.

Then it crashed before actually spawning in-game.

No useful new client syserr appeared.

So now the next real blocker is probably around:

• loading phase
• EnterGame transition
• map/world bootstrap
• main character spawn
• entity visibility
• packet order
• missing client-expected packets before rendering

Which is exactly the kind of cursed nonsense I expected.

 

Current status

The project is alive.

It is not finished.

The real client has already reached deeper than “can’t connect,” which is encouraging.

But it is not playable yet.

The current focus is moving from:

“client can reach character flow”

to:

“client can spawn in-game and not immediately explode”

After that, the next big targets are:

• stable world/session visibility
• NPC/mob spawn
• combat
• drops
• shops
• item usage
• persistence
• skills/affects
• quests/scripts
• admin/configuration tooling

The real fun has not even started yet.

Unfortunately.

 

Final note

This thread will probably contain code progress, failures, logs, screenshots, and occasional psychological damage.

If the project succeeds, it could become the base for a much faster and cleaner way to build Metin2 servers with modern tooling.

If it fails, at least we’ll have a very educational crime scene.

Either way:

Welcome to the dev journal.

Edited May 28 by alteredcode

[xHeaven 438]

Why did you decide to port it to C# instead of an arguably better language for the goal, such as Rust?

[kaysen 13]

38 minutes ago, xHeaven said:

Why did you decide to port it to C# instead of an arguably better language for the goal, such as Rust?

So far this is dead "project"

1. Exist Linux/Windows derivates + as bonus MacOS support (ARM + any ARM) + 64bit etc.. Just lot of unfinished works.. And this is one next.. Btw.. Still exist full C# Quantum core emulator, etc.. I dont know what he wanna explain because I didnt see something new before this exist..

2. When you can run server in any OS - windows, mac, freebsd, linux, so far whats a point for now????? (imaginare you hate FreeBSD - reason???)

This is a new ambicious project for nothing thats all. (just something like "in my head")

But well now I dont wanna be angry professor but stop doing more useless things than we can got ..
I think, would be beautiful make (just ask, weare here) for new client platform.. Already using dx10 (not yet all things all work properly as I want, Im not proof, but nowadays would be fine to tranform client in GL/Vulkan (fck Vulkan  enjoy porting -)  but when I have more experience with GL I think its easy transform it more 1:1 dx version.. (btw. can share any source in original client)

This is not hate but Im little bit confused, btw. sorry for my "english" xd

[alteredcode 2]

3 hours ago, xHeaven said:

Why did you decide to port it to C# instead of an arguably better language for the goal, such as Rust?

Fair point, Rust would definitely make sense for a low-level server rewrite.

But for me the choice is also practical: I use C# daily, I understand it, and I can actually review/debug the code myself.

Since I’m using an AI agent to accelerate the work, I don’t want to end up with a codebase where I’m completely dependent on the agent to understand what’s going on.

C# gives me the best balance for this project: modern stack, fast iteration, good tooling, great for future web/admin/config systems, and still something I can personally control.

So yeah, Rust is a strong option technically, but C# is the better strategic choice for me.

2 hours ago, kaysen said:

So far this is dead "project"

1. Exist Linux/Windows derivates + as bonus MacOS support (ARM + any ARM) + 64bit etc.. Just lot of unfinished works.. And this is one next.. Btw.. Still exist full C# Quantum core emulator, etc.. I dont know what he wanna explain because I didnt see something new before this exist..

2. When you can run server in any OS - windows, mac, freebsd, linux, so far whats a point for now????? (imaginare you hate FreeBSD - reason???)

This is a new ambicious project for nothing thats all. (just something like "in my head")

But well now I dont wanna be angry professor but stop doing more useless things than we can got ..
I think, would be beautiful make (just ask, weare here) for new client platform.. Already using dx10 (not yet all things all work properly as I want, Im not proof, but nowadays would be fine to tranform client in GL/Vulkan (fck Vulkan  enjoy porting -)  but when I have more experience with GL I think its easy transform it more 1:1 dx version.. (btw. can share any source in original client)

This is not hate but Im little bit confused, btw. sorry for my "english" xd

I understand what you mean.

I agree that “make Metin2 run on another OS” alone is not enough to justify a whole project. If the goal was only “FreeBSD bad, run server somewhere else,” then yes, that would not be very interesting.
The bigger goal here is not just portability.

What I’m trying to build is more like a modern server framework around Metin2: cleaner architecture, tests, modern persistence, easier tooling, and eventually a visual configuration/admin center for drops, spawns, shops, items, events, etc.
So the interesting part for me is not only:

“Can the server run in C#?”

but:

“Can i make Metin2 server development less painful and more tool-driven?”

About existing projects like Quantum Core: yes, I know similar ideas exist or existed. I’m not claiming nobody ever tried a C# core before. This thread is a dev journal of my attempt, with real progress, real client tests, crashes, fixes, and limitations shown publicly.

About the client: I actually agree that client modernization would be very interesting too. A modern GL/Vulkan client or cross-platform client would be huge. But that is a different monster.

For now I’m starting server-side because that is where I want the framework/configuration/control layer to live. Once the server foundation is real enough, client modernization could also become part of the bigger picture.

So no, I don’t see your comment as hate. The skepticism is fair. Many projects die as “nice idea in my head.” That’s exactly why I’m documenting progress step by step instead of just announcing “new core soon.”

Edited May 29 by alteredcode

[xHeaven 438]

8 hours ago, alteredcode said:

Fair point, Rust would definitely make sense for a low-level server rewrite.

But for me the choice is also practical: I use C# daily, I understand it, and I can actually review/debug the code myself.

Since I’m using an AI agent to accelerate the work, I don’t want to end up with a codebase where I’m completely dependent on the agent to understand what’s going on.

C# gives me the best balance for this project: modern stack, fast iteration, good tooling, great for future web/admin/config systems, and still something I can personally control.

So yeah, Rust is a strong option technically, but C# is the better strategic choice for me.

Makes sense, going with what you know and understand is usually the best choice. I was just interested whether there is a different kind of thought behind the choice. Thanks for your answer, good luck with your project!

[hvi 45]

Would've been nice if you took at least the time to write the posts yourself, instead of having an AI do it. I think people would appreciate talking to people instead of LLMs.

With that said you're rebuilding critical infrastructure, expecting a LLM to be able to do it is straight up delusional. Rebuilding such project requires architecture knowledge and understanding that LLMs will never be able to achieve.
And even if it were to manage to get something working you're only setting yourself up for security issues.

Still it is a nice project that can teach a lot and I'd really encourage you to write it yourself as you'd get a lot of experience out of it.
C# is fine for it as the server ticks every 40ms if I'm not wrong, so the garbage collector is not an issue. The real benefit of a rewrite would be making it multi threaded, to leverage all the cpu cores. But once again a LLM will not be able to do it.

Edited May 29 by hvi

[kaysen 13]

19 hours ago, alteredcode said:

Fair point, Rust would definitely make sense for a low-level server rewrite.

But for me the choice is also practical: I use C# daily, I understand it, and I can actually review/debug the code myself.

Since I’m using an AI agent to accelerate the work, I don’t want to end up with a codebase where I’m completely dependent on the agent to understand what’s going on.

C# gives me the best balance for this project: modern stack, fast iteration, good tooling, great for future web/admin/config systems, and still something I can personally control.

So yeah, Rust is a strong option technically, but C# is the better strategic choice for me.

I understand what you mean.

I agree that “make Metin2 run on another OS” alone is not enough to justify a whole project. If the goal was only “FreeBSD bad, run server somewhere else,” then yes, that would not be very interesting.
The bigger goal here is not just portability.

What I’m trying to build is more like a modern server framework around Metin2: cleaner architecture, tests, modern persistence, easier tooling, and eventually a visual configuration/admin center for drops, spawns, shops, items, events, etc.
So the interesting part for me is not only:

“Can the server run in C#?”

but:

“Can i make Metin2 server development less painful and more tool-driven?”

About existing projects like Quantum Core: yes, I know similar ideas exist or existed. I’m not claiming nobody ever tried a C# core before. This thread is a dev journal of my attempt, with real progress, real client tests, crashes, fixes, and limitations shown publicly.

About the client: I actually agree that client modernization would be very interesting too. A modern GL/Vulkan client or cross-platform client would be huge. But that is a different monster.

For now I’m starting server-side because that is where I want the framework/configuration/control layer to live. Once the server foundation is real enough, client modernization could also become part of the bigger picture.

So no, I don’t see your comment as hate. The skepticism is fair. Many projects die as “nice idea in my head.” That’s exactly why I’m documenting progress step by step instead of just announcing “new core soon.”

I understand you, and I definitely didn’t mean to offend you or anything like that. What I meant was that instead of starting from scratch, I would rather continue working on someone else’s existing work. Why? Because Metin is a complex system, and every person who starts this from the beginning is just wasting time.

The mentioned QuantumCore seems like a good starting point to me — a lot of things are already solved, it meets your requirements, and reworking it would probably be easier than starting with the Marty sources, where you have a lot of new code, especially systems.

However, regarding the client, with everything that already exists around the server, I see the biggest issue in the community mainly being the client itself, because nobody is really paying attention to it.

[Matteo 69]

Whats your exact issue with FreeBSD? It has one of the best native file systems (ZFS), also one of the best OS to handle large traffic and also the safest with least vulnerabilities than linux. FreeBSD is used by Netflix (also they are developing the kernel, making the networking much much better) and lot of others as background services. For this purposes, its much better than any Linux distro. (Just think about it, why would they choose FreeBSD over Linux back then? )

I leave a vulnerability statistics here for you:
 

+---------+---------+-------+
| Year    | FreeBSD | Linux |
+---------|---------|-------+
| 1999    | 18      | 19    |
| 2000    | 27      | 5     |
| 2001    | 36      | 22    |
| 2002    | 31      | 15    |
| 2003    | 14      | 19    |
| 2004    | 15      | 51    |
| 2005    | 17      | 133   |
| 2006    | 27      | 90    |
| 2007    | 9       | 62    |
| 2008    | 15      | 71    |
| 2009    | 11      | 102   |
| 2010    | 8       | 123   |
| 2011    | 10      | 83    |
| 2012    | 10      | 115   |
| 2013    | 13      | 189   |
| 2014    | 18      | 130   |
| 2015    | 6       | 86    |
| 2016    | 6       | 217   |
| 2017    | 23      | 454   |
| 2018    | 29      | 177   |
| 2019    | 18      | 170   |
| 2020    | 31      | 126   |
| 2021    | 25      | 158   |
| 2022    | 1       | 73    |
|---------|---------|-------|
| Total   | 430     | 2780  |
+---------+---------+-------+

 

[alteredcode 2]

17 hours ago, hvi said:

Would've been nice if you took at least the time to write the posts yourself, instead of having an AI do it. I think people would appreciate talking to people instead of LLMs.

With that said you're rebuilding critical infrastructure, expecting a LLM to be able to do it is straight up delusional. Rebuilding such project requires architecture knowledge and understanding that LLMs will never be able to achieve.
And even if it were to manage to get something working you're only setting yourself up for security issues.

Still it is a nice project that can teach a lot and I'd really encourage you to write it yourself as you'd get a lot of experience out of it.
C# is fine for it as the server ticks every 40ms if I'm not wrong, so the garbage collector is not an issue. The real benefit of a rewrite would be making it multi threaded, to leverage all the cpu cores. But once again a LLM will not be able to do it.

“LLMs can’t rebuild critical infrastructure because they lack knowledge.”

What knowledge exactly?

Hermes is not guessing Metin2 from astrology. It has the original Marty source as source of truth, checks how the old implementation works, writes the modern version, runs tests, then the real client decides if we are clowns or not.

So the contract is not “AI vibes.”

The contract is:

old source behavior + real client proof

Also this “AI = security issues” argument is funny.

When you write code by hand, are you magically vulnerability-free? Because from what I’ve seen in this scene, half the servers are held together by copy-pasted systems, raw SQL, and folders called `fix_final_no_bug`.

Security comes from architecture, tests, review, logs, transaction boundaries and abuse testing. Not from manually typing every semicolon like a monk.

And about AI/security: companies are literally building AI security agents now. Anthropic has Claude Security / Mythos-style tooling to find vulnerabilities humans miss, and somehow we are still pretending AI cannot help review/build software? Come on. This is not 2021 anymore.

About the posts: yes, I use ChatGPT. English is not my native language, I have limited time, and I pay for it. ChatGPT is my scribe until I die or until i run out of tokens. Whichever comes first.

About multithreading: why would that be protected by an anti-AI magic barrier?

Multithreading is architecture: state ownership, queues, isolation, scheduling, persistence boundaries. An agent can help with that. It just should not be blindly trusted.

Correct order:

compatibility → correct state → safe persistence → concurrency

If the state is wrong, multithreading just corrupts items faster on more cores.

7 hours ago, kaysen said:

I understand you, and I definitely didn’t mean to offend you or anything like that. What I meant was that instead of starting from scratch, I would rather continue working on someone else’s existing work. Why? Because Metin is a complex system, and every person who starts this from the beginning is just wasting time.

The mentioned QuantumCore seems like a good starting point to me — a lot of things are already solved, it meets your requirements, and reworking it would probably be easier than starting with the Marty sources, where you have a lot of new code, especially systems.

However, regarding the client, with everything that already exists around the server, I see the biggest issue in the community mainly being the client itself, because nobody is really paying attention to it.

I get your point, no offense taken.

QuantumCore might be useful to study, but it is not what I want to build.

I don’t want to start from someone else’s architecture and then spend the next months fighting decisions I didn’t make.

I want:

• Marty source as behavior reference
• old client as compatibility contract
• modern .NET backend
• my own framework
• future dashboard/config center

So yes, existing work can save time.

But sometimes “saving time” at the start means paying interest forever.

About the client: I agree. The client is a huge problem too.

But server rewrite + client rewrite at the same time is how projects die beautifully.

One dragon at a time.

5 hours ago, Matteo said:

Whats your exact issue with FreeBSD? It has one of the best native file systems (ZFS), also one of the best OS to handle large traffic and also the safest with least vulnerabilities than linux. FreeBSD is used by Netflix (also they are developing the kernel, making the networking much much better) and lot of others as background services. For this purposes, its much better than any Linux distro. (Just think about it, why would they choose FreeBSD over Linux back then? )

I leave a vulnerability statistics here for you:
 

+---------+---------+-------+
| Year    | FreeBSD | Linux |
+---------|---------|-------+
| 1999    | 18      | 19    |
| 2000    | 27      | 5     |
| 2001    | 36      | 22    |
| 2002    | 31      | 15    |
| 2003    | 14      | 19    |
| 2004    | 15      | 51    |
| 2005    | 17      | 133   |
| 2006    | 27      | 90    |
| 2007    | 9       | 62    |
| 2008    | 15      | 71    |
| 2009    | 11      | 102   |
| 2010    | 8       | 123   |
| 2011    | 10      | 83    |
| 2012    | 10      | 115   |
| 2013    | 13      | 189   |
| 2014    | 18      | 130   |
| 2015    | 6       | 86    |
| 2016    | 6       | 217   |
| 2017    | 23      | 454   |
| 2018    | 29      | 177   |
| 2019    | 18      | 170   |
| 2020    | 31      | 126   |
| 2021    | 25      | 158   |
| 2022    | 1       | 73    |
|---------|---------|-------|
| Total   | 430     | 2780  |
+---------+---------+-------+

 

I don’t have an issue with FreeBSD itself.

FreeBSD is solid. ZFS is great. Networking is great. I’m not saying:

"FreeBSD bad"

I’m saying:

"old Metin2 FreeBSD-only workflow bad"

The problem is the legacy development flow: old scripts, old assumptions, manual txt editing, restart channel, pray, crash, read syserr, repeat.

I want the framework to be cross-platform.

Windows/VS for development, WSL/Linux for development, Linux for deployment, and if someone wants FreeBSD, fine: .NET can run there too.

So FreeBSD fans can relax. I’m not coming for ZFS.

The goal is freedom from the old workflow, not replacing one religion with another.

Edited May 30 by alteredcode

[Denizeri24 43]

what you mean with "modern" bro, editing sqls - txts from website? many dev already have that, they can edit every sql and txt file from web.

 

metin2 sources (atleast server) already have windows port and made for unix so can be run on linux too.

[hvi 45]

16 hours ago, alteredcode said:

“LLMs can’t rebuild critical infrastructure because they lack knowledge.”

What knowledge exactly?

Knowledge and understanding. The exact thing your LLM is lacking, even in the response you posted to my message.
A LLM does not have the capability of understanding the words or the code it uses: it's purely statistics.
 

Quote

Hermes is not guessing Metin2 from astrology. It has the original Marty source as source of truth, checks how the old implementation works, writes the modern version, runs tests, then the real client decides if we are clowns or not.

So the contract is not “AI vibes.”

The contract is:

old source behavior + real client proof

Sure. But it's not understanding anything. And that's why your project is stuck at the enter game.
I did start a server rewrite in Go  in the past, just as a proof of concept, and I managed to get in game in about a week of work. Manually, with no AI. I'll release it if anyone is interested.
Hence my recommendation to do it manually, you're just shooting yourself in the foot by using AI.
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
 

Quote

Also this “AI = security issues” argument is funny.

When you write code by hand, are you magically vulnerability-free? Because from what I’ve seen in this scene, half the servers are held together by copy-pasted systems, raw SQL, and folders called `fix_final_no_bug`.

Security comes from architecture, tests, review, logs, transaction boundaries and abuse testing. Not from manually typing every semicolon like a monk.

Security comes from understanding architecture and surface of attacks. Something LLMs cannot do
 

Quote

And about AI/security: companies are literally building AI security agents now. Anthropic has Claude Security / Mythos-style tooling to find vulnerabilities humans miss, and somehow we are still pretending AI cannot help review/build software? Come on. This is not 2021 anymore.

AI security agents are just scanning mostly for buffer overflows: and sure, it's something that gets there by distraction but that a developer would find easily if they would just take the time to look for them.
It's just that nobody sits there and starts looking for it, not black magic nor exceptional capabilities.
The articles you can find online are just marketing and you can easily find examples of vibe coded software that gets immediately hacked.
Not being 2021 has nothing to do with it as, once again, LLMs are incapable of understanding what they're doing.
 

Quote

About multithreading: why would that be protected by an anti-AI magic barrier?

Multithreading is architecture: state ownership, queues, isolation, scheduling, persistence boundaries. An agent can help with that. It just should not be blindly trusted.

Correct order:

compatibility → correct state → safe persistence → concurrency

If the state is wrong, multithreading just corrupts items faster on more cores.

Because multithreading requires being able to understand the program flow. 

 

Quote

About the posts: yes, I use ChatGPT. English is not my native language, I have limited time, and I pay for it. ChatGPT is my scribe until I die or until i run out of tokens. Whichever comes first.

Yes, and frankly it's kinda offensive. It looks like you're not just limiting yourself to using AI as a translation tool, given your message structure but that you're letting it craft your answer and points. So this will be my last response here, since if I wanted to talk to chatgpt I would just go talk to chatgpt.

Best of luck
 

On 5/29/2026 at 11:37 PM, kaysen said:

However, regarding the client, with everything that already exists around the server, I see the biggest issue in the community mainly being the client itself, because nobody is really paying attention to it.

I wholeheartedly agree with you. The players see the client, not the server. They don't care about the backend as long as it does the job.
 

Spoiler

 

[Exynox 3536]

Hi,

This sounds like an interesting project, and as a matter of fact, I've been trying to the same lately:

I'm doing this from the perspective of a computer scientist: by the nature of our work, we pretty much have to stay on top of things and figure out what the state-of-the-art is, and right know I'm really interested in exploring the limitations of LLMs, and how useful are they really when coding.

I used to be a hater of AI and I still consider myself to be mostly so, but for different reasons: it's very commonly wrongly used. I see people everyday vibecoding without any clue for what their LLM actually does. LLMs also tend to not be that elegant in their "thinking" and I've seen them countless times produce bloated output that is hard to read and maintain. When it comes to it, human design is more concise and we can be sure that at least some thinking and consideration took place.

That is - if the developers actually think and know what they're doing. LLMs, by the gift of statistics, have the advantage of having "knowledge" of common pitfalls and do in fact usually avoid them. Given the amount of raw SQL, bad memory management, poorly thought out algorithms, memory waste etc. seen only on this forum alone, I can say that an LLM has a slight advantage over a junior developer.

(I guess the worst of both worlds is having junior developers use LLMs, since they don't have the experience required for auditing another person's code).

Another thing is that AI is expensive, especially Claude Opus - it's surreal how quick you can burn through tokens. And since I can't justify spending huge amounts of money on a hobby project, and since I don't have 4000€ to spend on a 5090, I had to make do with my existing 3060 and running qwen3.6 locally.

Getting it work was a PAIN, I spent pretty much all week trying to come up with a setup that is both reliable and needs minimal input or nudging from a human.

Having said that, here's what I've confirmed you can do with LLMs:

• Menial, repetitive work: translating comments, various refactorings such as converting c-strings to std::strings, c-pointers to shared_ptr etc.,
• Security audits: null pointer guards, checking for possible buffer overflows, SQL injection. The really basic stuff that everybody should have in their mind when coding, but Metin2's developers didn't. Clang linting also helps very much here.
• Coding style: LLMs can help bring code by different developers into the same coding style, formatting etc.
• Documentation: honestly this is where it excels, having the LLM go through all the files and documenting how they all work and come together (and then maybe making a wiki for a human to use) is extremely valuable.
• Testing: it seems it can also do testing to an extent, but I feel like the Metin2's codebase is notoriously hard to test. The various systems aren't that self-contained, nor do they use OOP that much so that you could fake various objects for testing purposes. We have the issue of having the server running on Linux (in my case) and the client on Windows. Yes, it can work in Wine, but coming up with a testing setup is pretty hard.
• CRUD controllers on websites - especially for Metin2, whose website logic is very simple, LLMs can do a pretty OK job at building website logic.

Everything I pointed above must be vetted by a qualified human, simply letting LLMs free won't give much results.

This was my two cents on this issue. I get where you're coming from, I don't have much time myself to work on the Old Metin2 Project, and whatever time I have, I prefer to use in order to get some rest.

I have thought a lot about rewriting the server, once in Rust and once in Go, but:

1. The amount of work required is enormous (especially for a single person or a small team). Interpret this as "one LLM" still has limited capacity, multiple orchestrated LLMs would be required. The orchestration should also be done by a human.
2. Nobody will use it. It's a chicken and egg problem. Pretty much all existing tutorials and guides online for Metin2 assume the existing codebase. Everybody knows it and is familiar with it. Experienced developers usually tend to have a lot of work to do, and don't really have the time required to get familiar with another codebase. Your only users will be just that. Users that want to set up a server and not much more, and existing serverfiles are already pretty painless to set up. 

As mentioned here before, nicer tooling for customizing game data already exists and/or can be written for the current codebase.

Yes, rewriting everything to C# is a nice experiment. I wish you the best of luck, but my opinion is that your time and especially your money is better spent elsewhere. To me, modernizing existing code is the way to go.

I have always wondered whether we could use LLMs to port the client from DirectX 8/9 to Vulkan or some sort of wrapper library like dxgl in order to get closer to running the client natively on Linux/macOS etc.

[Gurgarath 3699]

Hello!

Excellent project, good luck on that! My two cents on this, I think, can be summed by what Exynox said:

On 5/31/2026 at 5:13 AM, Exynox said:

1. Nobody will use it. It's a chicken and egg problem. Pretty much all existing tutorials and guides online for Metin2 assume the existing codebase. Everybody knows it and is familiar with it. Experienced developers usually tend to have a lot of work to do, and don't really have the time required to get familiar with another codebase. Your only users will be just that. Users that want to set up a server and not much more, and existing serverfiles are already pretty painless to set up. 

It is excellent either if you want to keep your own server, start a new field, an university / hobby project or the likes of QuantumCore for the OG's in the back. But for the end user, it might be an absolute pain, and I mean this also if we end up with newer sources in our hands.

I personally work on sources I have been meticulously stripping and updating since 2014. To the point that in 2022 I was already unable to provide systems working on other sources. Currently, my server is in Rust and my client is not having a single piece of their old EterX DX8 code. Which makes it really good for me and my own usage, but really bad for anyone else or even just me trying to sell or share systems that would work "as-is". 

All the resources exists for the 2014 sources, which makes it already extremely hard to maintain all the existing branches, some people already do not give support for Ava or N2 sources, some systems have a Marty version, some other have an Owsap version. The end user basically will not bother trying something that changes everything from the ground up because at the very first bump in the road, it will be them and only them and their knowledge. We even, to this day, have people asking for help on 2010 tutorials that are now outdated with the .txt protos and the knowledge base of pre-2013 wasn't even fully ported to the 2014 sources for the beginners. This is for the same reasons that most "advanced" users out there still recommend Marty's or TMP4 sources (or Owsap with support), because the potential of having something go south without any resources is lower than with other (leaked or sold by less advanced users) sources.

However, this is an interesting project to take upon!

[CONTROL 925]

Not using AI at all is like walking to work every day while refusing to use a perfectly good car.

Relying on AI for everything is like trying to drive that car across an ocean.

AI is a tool. Used correctly, it can dramatically increase productivity. Used blindly, it will eventually leave you stranded...