A Metin2 private server patcher is the executable players launch instead of the game client: it reads a two-layer config, downloads a manifest of every file's checksum, and pulls only what changed. Building that by hand means wiring a checksum-and-compression tool, a hand-edited config, and an FTP upload together, then repeating it every release. A hosted patcher keeps the same on-wire format and replaces the manual loop with a panel that does every step for you.
Players don't launch the Metin2 client directly on a private server — they launch a patcher, which launches the client once local files match what the server expects. On startup it reads a local config for one thing: the URL of a remote config, fetched and overlaid key by key. The merged result says where the patch manifest lives, where to check for its own update, and what to show on the loading screen.
The manifest is one line per file, each carrying a checksum, a size and a timestamp. The patcher hashes its own install and compares against it. Anything that doesn't match downloads and decompresses; anything that matches costs nothing — the whole reason a patcher exists instead of re-downloading the entire client every update.
Five mechanical steps, and each one is a place a release can go wrong.
01
Write one manifest line per file — checksum, size, timestamp. Miss a field and the client's parser drops the line without complaint; that file never gets flagged as changed.
02
Run each changed file through the compression the client expects — a compressed stream with a small size header, not a zip. A wrong container still downloads fine and corrupts on decompression.
03
Each release gets its own folder next to its own manifest, so an old build stays downloadable after a new one goes live. Flatten this and there's no way to hand a player back a working previous client.
04
The local config only points at the remote one; the remote config carries the patch location, the update location, and every piece of branding. Get it wrong and players lose a setting on the next republish.
05
Every file, every release, over a protocol with no atomic "release complete" signal — a dropped transfer leaves players mid-publish.
<crc> <size> <ftHigh> <ftLow> <relative\path\with\backslashes> # every compressed file on disk: [uint32 LE uncompressed size][bare LZO1X-1 stream]One manifest line per file, and the container every compressed file is wrapped in.
Step | By hand | Hosted |
|---|---|---|
Checksums | A CLI tool, run by hand | Computed for you on drop |
Compression | A separate pass, easy to skip | Automatic, changed files only |
Upload | The whole tree, over FTP | Only changed files |
Branding change | Rebuild and re-sign the exe | A form field |
Rollback | Re-upload the old build | Repoint the live version |
EasyPatcher keeps the same manifest and compressed-file format the client already reads — nothing about how players patch changes. What changes is who does the mechanical work: drop your client folder into the browser and only what differs from the live version is compressed and uploaded, straight into storage that belongs to your account alone.
Every tenant ships the identical signed patcher binary; the only file that differs per server is a two-line config pointing at your own generated remote config. Branding, links and feature flags live there and take effect on next launch with no rebuild or redownload. Multiple patch versions stay live side by side, so a bad release is a rollback, not a re-upload.
No. Every server ships the identical signed patcher binary; the only per-server file is a two-line config whose one real line points at your own remote config, where branding and patch source actually live.
Each version lives in its own folder that's never overwritten. Rolling back means pointing the live version at the previous folder — no re-upload, and the buggy version stays there to inspect.
No. The patcher only downloads files whose checksum doesn't match the manifest, so a build touching ten files costs ten files, not the whole client.
The client's parser drops a manifest line outright if it's missing a field, or if a timestamp half is signed instead of unsigned — no error, just a file never flagged as changed. A common reason a hand-built patch looks fine on upload and stays stale for players.
It's one signed binary shared across every server rather than a one-off exe from a forum thread — a single artifact to audit. The certificate is self-signed, so Windows can still show a first-run warning regardless of who hosts it; that's Windows' own behavior around unfamiliar publishers, not something hosting removes.
Yes — the free tier gives 100 MB of storage, keeps two versions, and allows one publish a day from a shared subdomain instead of your own CDN domain.
Drop your client folder in and get checksums, compression, upload and rollback without touching FTP or a CLI tool again.
No credit card · 100 MB free · set up in minutes