Is There a Cleaner Way to Develop for Metin2 Servers?

[klimexx 0]

Hey everyone,

I've been working with Metin2 server files, and I’ve started to wonder – is there really no cleaner or more structured way to program for Metin2?

Right now, the process feels extremely fragmented. I’m running a FreeBSD server on VirtualBox, then using my Windows environment to compile and rewrite files.
I'm constantly switching between PuTTY for SSH access, WinSCP for file transfers, and MySQL tools for database changes.
On top of that, I still need to manually edit .py scripts and other configuration files.

It often feels like I’m searching for a needle in a haystack, trying to figure out what to edit, where to click, and how to compile or reload everything just to see one small change.

I just can't believe that modern (or even well-maintained old) servers are still operated in such a messy and chaotic environment.
Has anyone here found a more efficient or streamlined workflow?
Maybe using containers, automation tools, or even IDEs configured to work directly with the server?

I’d really appreciate if someone could share their setup or tips to simplify and clean up the development process.

Thanks!

[Gurgarath 3694]

Hello,

People just got used to it, with modern IDE, you can easily set-up CMake and compile from within your VM, or use Rsync for that matter. I assume this is what most people do. I personally have my server on Linux, which makes it way easier for WSL2 on Windows and simply for my native desktop to work, on the server only, as the client is by default really hard to cross compile. You can also very much run a Windows server (Metin2 server has Windows support so you can run it easily on your desktop rather than in a VM) and it will make your daily use easier. Having to boot your VM just to push the changes you made locally on your Windows server.

I would advise you to first look into CMake (or Meson if that's your thing) and set-up a modern IDE. This will already limit the fragmentation and wasted CPU / Ram that the VM overhead is costing you.

[msnas 2346]

@ Gurgarath already gave you some useful tips. I just want to emphasize that having your project set up with CMake makes it significantly easier to maintain a unified structure for compiling both on Windows and FreeBSD (or even Linux, assuming compatibility).

What I’d also recommend is setting up a pipeline that automatically compiles the server source whenever you push a commit to your repository. This pipeline should upload the updated files directly to the vm and compile them there. That way, you eliminate the need to manually transfer files back and forth.

If your server vm and compile vm is the same, you can even automate stopping the server before the process begins and starting it again at the end, all triggered by a simple git push.

As for the best repo structure in my opinion, 4 repositories are enough to have the pipelines working efficiently:

• Server Source
• Client Source
• Client
• Common (tool sources like dump_proto, world editor, etc)

2 pipelines, one for server and one for client (commit -> compile client source and push the binary to client repo) should do the trick. 

[klimexx 0]

Many thanks @ Gurgarath and @ msnas!

I had this idea to have everything on one system, perhaps Windows (can work in Linux as well, but executing exe through wine is problematic), but the truth is that I'm developer in SAP ABAP for 5-6 years, and this is something new for me.

C++ or Python, dealing with server side compiling as well as developing client side...
That's why I wondered if there's some documentation for Windows server setup to be able to connect it in one system.
Just to make sure that I'll be able to keep everything consistent and clean.

The pipeline idea came to my head as well, but again, I don't know how it would work with Git to have repository as I know that on FreeBSD there're alliases to start the server and compiling the data, which is still hard for me to wrap my head around.

I don't have such a system at work, everything I code, I can compile in the same system/directory, and then execute it as well.
Which is something I would kill to have, repository where I would be able to work and with ease compile and test my changes.

Many thanks again.
Perhaps I will find some documentation here to do this and create some robust system in order to create well-made server

[Takuma 270]

Hi ! 

One thing to watch out for with Windows servers: if you compile your server on Windows, there’s a good chance you’ll lock yourself into that environment. And in production… running and maintaining a FreeBSD system is way nicer—and cheaper—than dealing with Windows. Seriously.

And if you're using FreeBSD (for various reasons... Personally I prefer it), you can still use Samba.. It lets you easily access your VM files directly from Windows through Explorer.

 

If it’s just for reading files, you can also look into shared folders with VirtualBox, which work quite well (https://www.freshports.org/emulators/virtualbox-ose-additions)

 

And one more thing: when it comes to IDEs—if you're using something like PyCharm, you can cofigure it to automatically sync your files over SFTP. So you can work on the files locally, and PyCharm will handle the synchronization each time you edit them.

I assume other IDEs offer similar features too. It's another valid option.

[Gurgarath 3694]

Facts, VMWare also have such capacities and I use them (I actually most of the time compile my client on a VM and the rest on my native OS) as well and it comes in clutch to easily move files or even sync them without having to go lengths and set-up a RSync.
I would also rejoin with Takuma on what he said, which is locking yourself into a specific environment, unless you ONLY work on Windows for the testing and dev and then push into your active FreeBSD compile machine and or server and keep that discipline (or use a script, some sync, git and some CI/CD or anything msnas said). It can be boring, but most of the workflow on Metin2 is pure ass and you usually just end up into what works for you and it might be way different than what the other guy would use.

Please note that the Windows server has actually a few small issues with signal handlers (I shared something for that so it should be fine, or just set-up boost::signal) and with random algorithms, so take that into account when developing. If you fix that (which is not that hard to be fair, just add proper C++11 random into libthecore) you can have a fairly solid Windows Server and actually run remotely your server on a Windows server itself and avoid having to deal with FreeBSD at once, but I would also not recommend that considering how powerful FreeBSD is, but it's a boost in convenience if that is your thing.

You can find documentation on Windows on the forum, it's not that hard, compile the .sln (or best, set up a CMake) and just host a local database using Xamp, Wamp or anything and you are good to go. If you want to move on Linux, the network stack should be changed, but now it is released, so you will be fine with that as well.

[Distraught 9996]

Just compiled the server for Windows in VS when developing something. That way you can easily debug things since VS has the best debugger.

I recommend moving to CMake for the server and client too, so you have a unified build system.

Also, when you're done with a feature and wanna test it on a FreeBSD env, I suggest using Jenkins and creating jobs to easily pull, build and deploy with just a click on a web panel.

Edited July 26, 2025 by Distraught

[LethalArms 639]

Hi, i'm not as expert as those we have wrote on the topic such as @ Gurgarath@ Distraught@ Takuma but i would like to share my experience, by far the cleanest way i have found to have a better work flow is actually using Linux, more specifically using KDE, the distro itself i've tested ubuntu based, fedora and arch based and its pretty much the same for this example.
Dolphin (kde file explorer) can access directly the VM folders using ssh (like winscp), so its like any other folder on your system without extra tools
About putty, in windows you can also do this, use the terminal instead, it has ssh by default and you can create a shortcut on the desktop to just run the command line.
As for executing the client, wine for me has been actually very simple, i just open cmd and type wine metin2client.exe and works, and you can even create a shortcut for it.
And etermanager also works under wine (but UI is a bit messy) and packmakerlite works too and i believe with some configuration it can even be put on the context menu (right click) like on windows
The only problem when running on Linux is that you need a Windows VM to compile src, but you can also share folders between VM and host and trigger building via CMD with ssh without needing to even opening windows GUI (you can even consider using windows server no gui but its harder to install things)
I only still have windows on my 2 pc's cuz some games dont work on linux and my laptop is very slow to have a windows vm active and already have it all setup and optimized

Oh and you can also test other editors such as Zed, i find VSCode/VSCodium to be very slow, specially on my laptop, while notepad++ (windows) or zed (linux) are way smoother

And on Linux you can use KVM which is a faster virtualization option (faster than vmware and virtualbox) like Hyper-V on Windows

Edited July 26, 2025 by LethalArms

[mmorse 0xrayz mmorse3399 1134]

If you're still messing around with VirtualBox, WSL1/2 hacks, or syncing back and forth between Windows and a VM, you're unnecessarily complicating your workflow. The cleanest and most professional way to develop for Metin2 in 2025 is to use Visual Studio with remote Linux compilation. You're writing code on Windows, compiling natively on Linux. Anything less is just unnecessary friction.

 

CMake is designed for managing cross-platform builds, especially when targeting multiple systems like Windows, Linux, macOS, mobile, or embedded devices. That’s not the case with Metin2. For Metin2 development, you only have two targets: a FreeBSD server and a Windows client. There’s no need for complex platform abstraction or build generation layers. The existing Makefiles for the server and Visual Studio solutions for the client are already purpose-built and effective. Introducing CMake here adds unnecessary complexity with no practical benefit. From my perspective, CMake is completely unnecessary here. I don’t use it, and I don’t plan to.

 

 

Spoiler

Visula studio witll do everything for you automatically.. Sync files, compile, set flags

Edited July 26, 2025 by Metin2 Dev International
Core X - External 2 Internal

[Mitachi 3368]

The ‘cleanest way to work’ is the way that, as you will obviously agree with me, allows you to spend less time doing your work.

From my point of view: At first, it's very easy to increase your productivity by using good practices in your work environment, but after a while, the improvements you'll see will be minimal, so there's no point in striving for “perfection”.

Essentials:

1. Write code and debug exclusively on Windows, use FreeBSD only for production (this is stated in the ymir docs itself, and is nothing new).
(However, this requires you to have debugging skills; if you don't know how to do it, it's useless). Windows makes no sense for running the server, more expensive machines, and 20 years of production on FreeBSD.

2. Use GitHub, never do a backup again in your life, GitHub has dozens of features, but even at an amateur level it's fine to use it, to have file versioning and keep everything under control (if you don't know what it is or how it works, we're wasting our time). Edit the code directly from the GitHub folder, so you always know what you're doing, what are the pending changes, and so you don't have to move the files inside. It is also useful if you do not use it fully but keep it updated, so that if an experienced developer comes to your AnyDesk to fix an error, they can go back to previous commits, run tests, and read your latest additions to understand where ‘that bug’ came from. (Do many but small commits)

3. Avoid wasting time where possible; create batch files to quickly compress your scripts. I see many people compressing files in a folder and manually moving the compressed file to the root directory or another location on the client. In an hour of work, you will realise that you have spent at least 10 minutes just compressing and moving files. Eliminate this practice.

4. Compile on the same machine where the files are located. In the case of FreeBSD, create symlinks. Don't compile and then copy 120 MB of files to your desktop and then move them to the vps/vds. You'll lose your hair before you start the server. It may seem daunting, but if you do it for five years and then consider that you have wasted a week of your life uploading game and database files, it is quite sad.

5. For Python, if you need to create GUIs, use a module reload system. Don't pack root and reopen the client 28 times to reposition a button.

6. You can create a script that constantly pushes files to your VPS (without GitHub). This way, you won't have to transfer all the files to compile, make unnecessary pushes, or worse, manually select the latest modified files.

There are more advanced practices that do improve things in the long run, but I don’t recommend them to everyone because they’re often not always worth the effort.

For example, I no longer use extern for dependencies, I use vcpkg with manifest mode. This means adding a library is as simple as adding a line to my vcpkg.json. It saves time and keeps everything clean, organized, and maintainable. But is it really necessary? Does it save time? Yes but moderately.

Some people go a step further and integrate this with CMake, removing the need to maintain Makefiles or .vcxproj files. While convenient and elegant, the actual impact is still minimal. It’s not something that saves you hours of work, and no, you’re not suddenly going to need to compile on Linux or some random platform tomorrow. Realistically speaking, Metin2 has been running on FreeBSD and Windows for over 20 years, and it will likely remain that way. And to handle just some files you add to your project rarely or a lib link, seems that worth? If you like yes, but isn't an essential move.

Many things developers do are based on "best practices" or because "that’s how it should be done" not necessarily because they provide real value in the current context. Metin is over 20 years old, did I already said that ahah? improving it is good, but the market demands content, fixes and new systems, not new technologies. Most of the time, these are simple conventions that developers adopt because they like them or because they are used to them.

So, as I was saying, reduce the time as much as you can, then when you improve your skills, acquire better methods, but don't expect big impacts. What makes the difference is dedicating even just one day to improving the way you work rather than your server, and it depends on your starting level; the further you go, the more difficult it will be to improve the workflow.

For the rest, I agree with the other guys above