alteredcode

“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. 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. 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.

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.”

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: Understand the original server/client protocol. Rebuild the server stack in modern .NET. Keep compatibility with the existing Metin2 client. Replace old runtime assumptions step by step. Build a modern framework around it. 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 Update #001 — Why .NET? Update #002 — Hermes enters the dungeon Update #003 — Current technical state 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.