Since then the complete Season 6 skill set has gone through it, including all six master skill trees. That's enough contact with the actual game to see whether the promise survived it.

A short refresher

For those who don't want to read the old post first, the vocabulary in three sentences. An attribute definition describes a kind of value - "Strength", "Maximum Physical Damage", "Ice Resistance". An attribute relationship says how one value feeds another ("every point of Strength adds 1/4 to maximum damage"), and an aggregate type says how it's applied: added to the raw value, multiplied, or added to the final value. Power-ups from items, buffs and passive skills plug into the same graph.

The important consequence: nothing in the game logic computes a character's damage from a formula. It asks the attribute system for a number, and the number is the result of whatever relationships the configuration happens to contain.

The real test: master skill trees

Master skills are a good stress test, because they're not skills in the usual sense. Most of them modify something that already exists: more damage on a skill you already have, more defense, longer buff duration, and sometimes something structural, like an additional arrow on Triple Shot.

In a hardcoded design, every single one of those is a special case somewhere in the combat code. Here's how the additional arrow works instead. The master skill is declared like this:

this.AddMasterSkillDefinition(
    SkillNumber.TripleShotMastery, /* ... */,
    Stats.ExtraProjectiles, AggregateType.AddRaw);

Higher-level bows grant the same attribute, as a plain item power-up:

item.BasePowerUpAttributes.Add(
    this.CreateItemBasePowerUpDefinition(Stats.ExtraProjectiles, 1, AggregateType.AddRaw));

And the code which actually fires the arrows contains exactly this:

extraProjectiles += (int)player.Attributes![Stats.ExtraProjectiles];

Three places that know nothing about each other: a master skill tree, an item definition, and a skill action. The skill action doesn't know whether the extra arrow comes from the master tree, from the bow, or from something we haven't invented yet - a buff, an event, a server-specific item. Add another source in the configuration and it just works.

There are over 170 master skill definitions in the Season 6 configuration now, and that's how all of them work.

What the system needed to grow

It would be a boring post if I claimed nothing had to change. The core stayed, but it needed a few extensions, and each of them came from a mechanic that couldn't be expressed otherwise:

• A Maximum aggregate type. Some values must not add up. If you wear three rings with ice resistance, MU doesn't sum them - only the highest one counts. So next to "add to raw", "multiply" and "add to final", there's now "take only the highest value".
• Relationships whose operand is an attribute. In 2020 a relationship multiplied an input attribute by a constant. Now the operand itself can be an attribute, so "this value scales with that other value" is expressible in data instead of in code. Several master formulas need exactly that.
• More operators. Multiply and add weren't enough - the official formulas contain exponentiation (in both directions), and minimum and maximum, so those became input operators too.
• A lot more attributes. Stats holds over 280 attribute definitions today. Among them the seven element resistances, each mapped to its damage bonus counterpart, which is how the jewelry system ended up being pure configuration as well.

That's the honest list. Four extensions in five years, all of them additive, none of them a redesign. Meanwhile the project files themselves - the composable attribute, the elements, the relationship evaluation - are still the ones the 2020 post described, and in the last year they only saw trivial changes.

I'll take that as the promise holding.

The unglamorous half: migrating data

There's a part of the data-driven approach which I underestimated in 2020.

If the game's mechanics are configuration, then adding a mechanic means changing configuration - and the configuration of a running server lives in its database, not in the source code. Shipping a new attribute in Stats.cs does nothing for anyone who already has a server. Their database has to learn about it.

So OpenMU grew a mechanism for that: configuration update plugins. Each one has a version number, a description, a creation date, and an ApplyAsync which does the change against an existing configuration. The elf one, for example, creates the new attribute definitions, adds power-ups to existing magic effects and fixes skill values:

var extraProjectiles = context.CreateNew<AttributeDefinition>(
    Stats.ExtraProjectiles.Id, Stats.ExtraProjectiles.Designation, Stats.ExtraProjectiles.Description);
gameConfiguration.Attributes.Add(extraProjectiles);

There are over 100 of these updates by now. It's the price of the design: data which behaves like code has to be migrated like a schema. If you build something similar, plan for this from day one - it's much less pleasant to add later.

Thanks, ze-dom

The system only proves anything if someone fills it with the actual game, and since September 2024 that someone has mostly been ze-dom. He worked his way from spawn points and jewelry options through the damage and defense calculations right into the master skill trees, each as an update plugin, each with whatever the attribute system was still missing for it.

That was the last big gap in Season 6 feature completeness, and it is exactly the kind of work nobody sees: no new subsystem, no impressive screenshot, just hundreds of small values which have to be right, in a game where the community notices immediately when one of them isn't. Thank you.

Would I build it the same way again?

Yes - with open eyes about the cost.

The cost is indirection. When a damage number is wrong, you don't read a formula; you walk a graph of relationships that four different configuration files contributed to. The tooling for that is better than it was (the admin panel can show you the attributes of a player), but it's still harder than reading twenty lines of arithmetic. And, as above, the configuration needs migrations forever.

The benefit is everything in this post. Six master skill trees, elemental jewelry, pets, buffs, event modifiers and a good number of server-specific customizations went in without touching the core of the system, and mostly without touching the game logic either. Server owners change values in the admin panel that would be a source code change in most other emulators.

Five years in, the attribute system is the OpenMU design decision I'd defend the most.

OpenMU can now populate itself. Since this summer the server can run bots: persistent characters which hunt, level up, spend their points, keep their buffs up, wear the gear they find, restock in town, group up, and log in and out over the day. The feature was built by nolt and is off by default - switching it on is a deliberate decision by the server admin.

I want to write about it because the design turned out more interesting than "fake players walking around", and because most of the hard parts had nothing to do with making a character move.

No client involved

Years ago I wrote about a demo console client - a program which connected to the server and spoke the protocol like a real client would. That is the obvious way to build a bot, and it's the wrong one for this purpose: a thousand of them means a thousand connections, a thousand encryption pipelines, and a thousand copies of a client's state, to simulate players who are already living in the server's own memory.

So a bot here isn't a client at all. It's an OfflinePlayer - the same class that keeps a character playing after its owner logs out, which is what MU Helper's offline mode does - with a navigator on top. No connection, no packets, nothing to encrypt.

Two ticks make up its mind. The offline helper AI runs twice a second and does the close-up work: attack, heal, buff, pick things up. The navigator runs once a second and decides the things an offline session never had to answer: where to hunt, when to travel, when to go shopping, whom to follow.

And bots are ordinary accounts. Each one is a real Account with an IsBot flag, its characters saved in the database like anyone else's, reloaded on the next start. A bot's progress belongs to the server's data, not to a process.

The rule which holds the whole thing together is this: a bot acts through the regular player actions. Moving an item, talking to a merchant, consuming a jewel, joining a party - all of it goes through the same code path with the same validations a client's packet would trigger. A bot cannot do anything a player couldn't, and when a rule changes, it applies to the bots for free. It's the same principle as the attribute system: don't build a second version of the game next to the game.

The interesting problems

Almost none of them are about walking or hitting things.

Everybody went to the same map. The obvious rule - always hunt the best map you can survive - turns every bot of a level band into the same answer, and leaves the rest of the band deserted. So the map is drawn instead of maximized: the best option still wins about a third of the picks, the runners-up split the rest, and the population spreads out the way players of that band would. Only maps which are actually an improvement take part in the draw.

A map can pass every check and still pay nothing. The monsters a bot is allowed to fight might be rare there, or other hunters get to them first. A bot notices this the way a player does - it hasn't landed a hit in minutes - and steps down one notch at a time until it finds something it can farm. The normal map choice carries it back up when its level and gear recover.

A mastered bot wants the weakest monsters, not the strongest. Master experience is only granted above a monster level threshold, and it barely grows with the monster's level after that. So the cheapest kill above the line is the best one - the opposite of what a bot does for the rest of its life. Those monsters still carry 40.000+ health, which is far beyond what a bot's found gear normally budgets for, so the hit budget is stretched for them. Its survivability isn't: a monster whose hits it can't take is still refused.

A veteran can own a skill it cannot cast. On a reset server, a reset keeps every learned skill but takes back the level which unlocked it. A character back at level 12 still owns Swell Life, which asks for 120. The game refuses such a cast silently - so a bot which kept trying would stand there forever, buffing something that never takes effect and never getting as far as attacking. Skills which can't currently be cast are passed over, in the attack rotation and in the buff rotation alike.

Being broke is a trap. A merchant trip only pays off if the bot can pay for something. A broke bot buys nothing, comes back as poor as it left, and would set out again instead of hunting - which is the only way it could have earned the money in the first place. Restocking therefore needs the means to pay, or loot worth selling once it's there.

A pet is not a stat. Plasma Storm draws its damage from the Fenrir, but the attribute behind it is derived from the character's own stats - nothing except the pet slot distinguishes a mounted character from one riding nothing. So pet skills are excluded unless the pet is really equipped, and the same goes for skills the game only activates during a castle siege.

My favourite of the lot is the PvP rule, because it's defensive in an unusual sense: a bot fights back only as far as the game's own rules allow - inside the self-defense window, or against someone already flagged as a killer. That means it can never be provoked into becoming an outlaw which players could then farm for free. It does remember who hit it, though, and a killed bot walks back to its killer to wait for a legal opening.

A population is a deployment question

The part I didn't expect to be interesting: bots count towards the player count of their game server, exactly like players do. And a server which reached its maximum player count turns new connections away. So a bot population large enough to fill a server would lock out the humans it was supposed to attract.

Hence a Bot capacity % - 60 by default - which is the share of a server's player limit its bots may occupy, with the rest reserved for players. And because OpenMU can run each game server as its own process, the split has to work without the servers negotiating: which accounts a server animates is a pure function of the account index and the set of configured game servers, so every server computes the same answer on its own. What doesn't fit stays offline until the deployment has room.

The cost, measured on a 12-core host: about 0.35 core and 760 MB for 250 bots, about 1.7 cores and 1.2 GiB for 1100. Generating a fresh population costs roughly a second per account - the password hashing dominates - and starting an existing population of 1100 takes some 15 seconds.

The honest part

Yes, this is a feature which can make a server look busier than it is. There's no point pretending otherwise, and it's why it ships disabled: turning it on is the admin's decision, not something OpenMU does behind anyone's back.

What surprised me is the other direction. A thousand characters playing at once is the load test nobody ever bothered to write, and it found real problems in the engine: neither MagicEffectsList nor ComposableAttribute is thread-safe, and a population that size runs into those races far more often than human players do - a few caught exceptions per minute. The bots deal with it pragmatically, by counting failed ticks and restarting themselves after twenty of them, which is what a player would do too. But the fix belongs in the engine, and now there's a reproducible way to hit it.

The limitations are documented rather than hidden. Bots never buy equipment - they wear what drops for them, so a bot at maximum level is weaker than a player of the same level would be. They do no quests and don't trade with players, the latter deliberately, because trading would be an abuse surface. Master skills which cost ten points at once are never learned, because a bot spends every point as it earns it.

Thanks

The bot feature is nolt's work - the initial one in July, and then a series of changes which turned a set of characters into something that behaves like a population. Eduardo added, among other things, the fresh-start option, which lets generated bots begin at level 1 with starter gear like a real new character instead of appearing with a random level and upgraded equipment.

Reviewing a feature of that size is its own kind of work, and most of what's in this post came out of that review going back and forth. The details above - the drawn map choice, the skill a reset character can't cast, the bot that can't afford to go shopping - are the ones which took the longest to get right, and they're the reason a bot is hard to tell apart from a quiet human player.

This is the tour: how a packet is framed, what the three things called "encryption" actually are, how a client gets from a connect server into the world - and what we changed once we had a client of our own.

The frame

Every packet starts with a byte which says two things at once: whether the payload is encrypted, and how long the packet is allowed to be.

After the length comes the packet code, and for some codes a subcode. That's the whole framing, and it gets small: a packet can consist of nothing but its header. When you close an NPC dialog, your client sends three bytes.

C1 03 31

C1: unencrypted, one length byte. 03: three bytes in total, the header included. 31: the code, which means "I closed the dialog". There is nothing else to say, so nothing else is sent. A good part of the protocol looks like this - in OpenMU's definitions, 69 of the packets a client can send are four bytes or shorter.

With a subcode it's one byte more. This is the greeting the connect server sends right after a client connects:

C1 04 00 01

Code 00, subcode 01, no payload: "hello, I'm here". A game client answers it by asking for the server list.

Subcodes are not a sign that the code space ran out - roughly half of the 256 possible codes are still unused today. They group what belongs together. F1 is the session: 00 for having entered the game server, 01 for login, 02 for logout, 03 for the logout the client sends when its own cheat detection triggers. F3 is everything about a character - list, creation, deletion, selection, stat points - and features which came later got a code of their own with the whole feature behind its subcodes: B2 for castle siege, F6 for quests, AA for duels, 3F for player shops. In OpenMU's definitions, the server sends 129 distinct codes, 25 of which carry subcodes; F3 alone holds 48 different packets. And, as I mentioned in an earlier post, the same message can have a different code depending on which localized client the player runs - the hit packet is 0x11 in the English client and 0xD6 in the Japanese one. The protocol has no version field to ask; the server has to know.

One more detail in encrypted packets: the first byte of the decrypted payload is a counter which runs from 0x00 to 0xFF, so that two identical packets never look identical on the wire. It makes replay attacks harder - at least for attackers who can't count.

Three things called encryption

"MU packet encryption" refers to three different mechanisms, applied in different places and in different directions.

SimpleModulus is the block cipher behind C3 and C4. According to a Korean change log it appeared in version 0.74.01, originally with 16 keys encrypting blocks of 32 bytes. Somewhere between 0.75 and 0.97 the block size was reduced to 8 bytes, so each block is now touched by 4 keys instead of 16. I wrote about how it works in detail and later revisited it.

Xor32 is a rolling XOR with a 32 byte key, applied on top of SimpleModulus in the client-to-server direction. Webzen changed those keys during maintenances, which tells you how much they trusted them. They're also really easy to be calculated, if you have the encrypted and unencrypted content of at least one longer packet. Hint: When you send a long chat message, the client sends it encrypted. The server sends the same message back, but unencrypted. Additionally, a chat message structure is so simple, the unencrypted content can be guessed.

Xor3 is three bytes - 0xFC 0xCF 0xAB - and it protects your login credentials. That is not a typo, and those three bytes have been public for two decades.

Which is the honest summary of this whole layer: the algorithms and keys have been known in the server and cheater community for well over ten years, and the keys can be derived from known packet content or brute-forced in a fraction of a second. This is obfuscation, not security. Everything arriving from a client is hostile input, and the server has to validate every single thing a packet claims - which is exactly why item duplication bugs were possible in the first place. If you run OpenMU for real, the encryptors sit behind interfaces so you can replace them, and you should.

From connecting to standing in Lorencia

The path a client takes is short and worth knowing, because most "I can't connect" reports fail somewhere in the middle of it.

First, the connect server. It's a separate, tiny service whose only job is to tell clients where the game servers are. The conversation is four packets: the server says hello, the client asks for the server list, the server answers with the list plus a load percentage per server, the client asks for the connection info of the one it picked, and gets an IP and a port back.

Then, the game server. The client opens a second connection, this time encrypted, and sends its login with the credentials wrapped in the three-byte Xor3, wrapped by SimpleModulus. The server answers with the character list, the client picks one, and after a short exchange the character enters the world - which is the moment the server starts sending the endless stream of "these objects are now in your scope" and "this one moved" packets that make up the actual game.

We describe packets as data, not as code

The interesting part of maintaining this protocol isn't any single packet - it's that there are so many of them. OpenMU currently defines 195 packets sent by the client, 281 sent by the game server, 11 for the connect server and 7 for the chat server.

Nobody wants to write and maintain that as hand-written parsing code, so we don't. Every packet is described in XML - its code, its subcode, its fields with their types and offsets, what it does, and what it causes on the other side - and everything else is generated from that description: the C# structs which wrap the raw bytes without allocating, the extension methods for sending, the tests, the 500 markdown files in the repository's docs/Packets folder, and these days even the C++ bindings the client uses. I wrote about that machinery when it was new, in handling packet structures in .NET and generating message structs by data.

The practical effect is that "the protocol" isn't spread over the codebase. It's four XML files, and everything which speaks it derives from them.

What we changed

For most of OpenMU's life, all of the above was fixed: the client was a binary we couldn't touch, so the protocol was a given. Since we have our own client, it isn't anymore.

The extensions are the ones the old format made impossible. Damage and experience are no longer capped at 16 bits, so a big hit is one packet instead of a loop of them. Items are serialized dynamically in 5 to 15 bytes with a flags byte, instead of squeezing every property into a fixed 12-byte bit puzzle. The appearance of a character gets 27 bytes instead of 18. Monsters send a health bar after being hit. The server tells the client which chat commands it may use.

None of that breaks the original client, because the server picks its view implementations per client version: an original Season 6 client gets the original packets, and our client - which announces itself as season 106 - gets the extended ones. Same server, same game logic, different bytes on the wire.

If you want to look at it yourself

Two things in the repository are worth knowing about. The docs/Packets folder contains a markdown page per packet, generated from the definitions, including when it's sent and what it triggers - that's the closest thing to a protocol specification that exists. And the network analyzer sits between a client and a server, shows the traffic live, resolves it against the packet definitions and shows you the values instead of raw bytes.

Both of them exist because reading someone else's protocol is normally a lonely activity with a hex editor. It doesn't have to be.

I've written a fair amount of interop code over the years, but I have never seen this particular combination anywhere else, and until recently it wasn't even possible. So it deserves its own post.

The problem: two implementations of one protocol

OpenMU has a network library, MUnique.OpenMU.Network. It knows the packet structures, it knows the two encryption schemes (SimpleModulus and the Xor stuff I wrote about years ago), and it's the part of the project which is best covered by tests, because getting a byte wrong there means nothing works at all.

The client had its own C++ implementation of exactly the same thing. So every protocol change meant doing the work twice, in two languages, with two chances to get the bit shifting wrong. And since I had just started extending the protocol, "twice" was going to be a lot of work.

The obvious idea - let both ends use the same library - has an obvious problem: one end is a 20-year-old C++ program and the other is .NET.

Why this only works now

The traditional answer is to host the runtime: link against nethost/hostfxr, start CoreCLR inside your process, load an assembly, get a function pointer, and ship a runtime with your game. That works, and it's a lot of moving parts to put into a game client which players install by unpacking a zip.

Native AOT changes the shape of the problem. The library is compiled ahead of time into native code, it's self-contained, there is no JIT and no runtime to install, and - the important part for this use case - it can export ordinary C entry points that any native program can resolve with GetProcAddress or dlsym. From the client's point of view it is simply a native DLL. It doesn't know or care that the code inside was written in C#.

And here's the detail which made this a "newest .NET" story rather than something I could have done in 2023: the client is 32-bit. Native AOT on Windows supported x64 and Arm64 in .NET 8 - x86 was added in .NET 9. A 20-year-old game client is exactly the kind of program that is still x86, and before that table gained its third entry, this whole approach was off the table for it. The library targets .NET 10 today, and CMake picks the runtime identifier

• win-x86, win-x64 or linux-x64 - from the build it's producing.

How it fits together

Three pieces: the exports, the loading, and the code generation which writes most of it.

The exports

The managed side is a static class whose methods carry [UnmanagedCallersOnly]. That attribute makes a method callable directly from native code, with a chosen export name, and no marshalling magic in between - you get what a C function gets. Connecting looks like this:

[UnmanagedCallersOnly(EntryPoint = "ConnectionManager_Connect")]
public static int Connect(
    IntPtr hostPtr,
    int port,
    byte isEncrypted,
    delegate* unmanaged<int, int, byte*, void> onPacketReceived,
    delegate* unmanaged<int, void> onDisconnected)

Two things to notice. First, the return value is an int handle, not a pointer to anything managed - the C++ side never holds a reference to a .NET object, it holds a number, and the library keeps a dictionary of connections behind it. Second, the last two parameters are function pointers back into C++. That's how received packets and disconnects get delivered: the managed side reads from the socket, decrypts, and calls the client's static handler with the handle, a length and a pointer to the bytes.

Around that there are ConnectionManager_Send, ConnectionManager_BeginReceive, ConnectionManager_Disconnect - and then one export per packet type. Currently that's over 200 exported entry points.

The loading

No hosting API, no coreclr_initialize. The client loads the library the way it would load any other DLL, on first use:

inline HINSTANCE get_munique_client_library_handle()
{
    static const HINSTANCE handle = LoadLibrary(L"MUnique.Client.Library.dll");
    return handle;
}

On Linux it's dlopen of MUnique.Client.Library.so, resolved through /proc/self/exe so it's found regardless of the working directory. Each exported function is then resolved once into an inline function pointer, and the call sites just call it.

The construct-on-first-use pattern above isn't decoration, by the way. The function pointers are inline globals in other translation units, and they resolve their symbols during their own dynamic initialization - a plain global handle would have been a static initialization order fiasco waiting for a full moon.

The code generation

I was not going to write 200 exports by hand, and I was not going to write their C++ counterparts by hand either.

The packet definitions live in XML - the same XML the server generates its packet structs from, which I wrote about in Generating message structs by data. The client library pulls them in as a NuGet package, so it's pinned to a version of the definitions instead of copy-pasted from somewhere.

From that XML, five XSL transformations produce:

• the C# methods with their [UnmanagedCallersOnly] attributes,
• C++ headers and sources with a nice class-based API for the client,
• C++ binding headers with the typedefs and symbol lookups,
• and the enums, for both languages.

The generated C# for the client-to-server direction alone is about 6.700 lines. On the C++ side, sending a chat message ends up as:

void PacketFunctions_ClientToServer::SendPublicChatMessage(
    const wchar_t* character, const wchar_t* message)
{
    dotnet_SendPublicChatMessage(this->GetHandle(), character, message);
}

which is exactly as boring as it should be. The client code calling it has no idea that the next stop is a garbage-collected language.

What bit us

wchar_t is not wchar_t. On Windows it's 2 bytes and holds UTF-16, on Linux it's 4 bytes and holds UTF-32, while Marshal.PtrToStringAuto always decodes UTF-16. The result of that mismatch, when the client was first brought up on Linux, was that the server address turned into nonsense, connect() hung on the main thread, and the game looked like it was frozen on a black screen. The library now decodes by the platform's real wchar_t width.

Cross-compilation has a hard edge. A Linux dotnet cannot AOT-publish a Windows library. The build has to distinguish between the build-time C# tools (which run on any host and generate C++ source) and the AOT publish step (which can't cross the OS boundary). We learned that by having the CI fail on missing generated headers.

MSBuild will happily redo everything. The XSL transformation target had no Inputs/Outputs at first, so it re-ran and rewrote every generated file on every single build, which in turn made CMake think the world had changed. Incremental builds are a feature you have to ask for.

And the usual Native AOT rules apply: no runtime code generation, trimming is part of the deal, and every managed exception has to be caught before it reaches the C++ frame above it. The exported methods are all wrapped accordingly.

Was it worth it?

Yes, and not by a small margin. There is exactly one implementation of the protocol now. When I add a packet, I add it to the XML, rebuild, and both sides have it - the server because it always did, the client because its bindings are generated from the same file. The encryption is maintained once. The tests which cover the server's network code cover the client's network code, because it is the same code.

The strange part is how unexciting it feels from the inside. A C++ game from 2005 calls a function pointer, and on the other side of that pointer sits modern C# with pipelines and spans, doing the actual socket work. The two halves are about twenty years apart and they get along fine.

The short answer: because for the last ten years the client was the one part of the system we couldn't change, and almost every ugly thing in OpenMU's network code exists because of that.

The client is the specification

When you write a server emulator, you don't design a protocol. You obey one. The client is a compiled binary from another decade, it expects certain bytes in a certain order, and if you send something it doesn't like, it either ignores you or crashes. That's the whole design space.

A good part of this blog is a monument to that: how the packet encryption works, how SimpleModulus was analyzed, the network analyzer I built to see what's going over the wire, and the packet structures which I ended up generating from data because there are so many of them.

None of that work is wasted - the original client is still supported, and supporting it stays a goal. But everything above is the cost of not owning one end of the connection.

What that costs, in bytes

Three examples, all from the server code as it is today.

Damage doesn't fit. The hit packet carries the damage as a 16 bit value. That's a hard ceiling of 65535 per hit. Modern servers hand out far bigger numbers than that, so the workaround has been in OpenMU for years: send the packet more than once until the damage is used up.

// do/while, so that a 'miss' with 0 damage sends a message, too.
do
{
    var healthDamage = (ushort)Math.Min(0xFFFF, remainingHealthDamage);
    var shieldDamage = (ushort)Math.Min(0xFFFF, remainingShieldDamage);

    await connection.SendObjectHitAsync(/* ... */).ConfigureAwait(false);

    remainingShieldDamage -= shieldDamage;
    remainingHealthDamage -= healthDamage;
}
while (remainingHealthDamage > 0 || remainingShieldDamage > 0);

A 200.000 damage hit is four packets. Experience gain has exactly the same problem and exactly the same loop. It works, and it's nonsense.

An item is a 12 byte bit puzzle. In Season 6 an item is serialized into 12 bytes, and there is no room in them. The item level sits in four bits of byte 1, so it can't go beyond 15. The option level is split up: two bits go into byte 1, the third bit is smuggled into bit 6 of the "excellent" byte. My comment in that code has been there for years:

// The item option level is splitted into 2 parts. Webzen... :-/

To support more than 256 items per group, the 9th bit of the item number is parked in yet another free bit. The item group takes the high nibble of byte 5, and the guardian option flag lives in the low one. Every bit in those 12 bytes is spoken for. If you want to add a new item property to your server - go find a bit.

For comparison, the same item in the old versions: 3 bytes in 0.75, 4 bytes in 0.95. The character appearance, which decides what everyone around you looks like, is 9, 11 and 18 bytes respectively. The whole visual state of a player fits into 18 bytes, and that's why some things simply cannot be shown.

The same packet has different codes per language. Not per version - per localized binary. The hit packet is 0x11 for the English client, 0xD6 for Japanese, 0xDC for Vietnamese, 0xDF for Korean and Filipino, 0xD0 for Chinese and 0xD2 for Thai. So the server doesn't only have to know which season you're running, it has to know which regional build you downloaded.

And the bugs you can't fix

The other half of the cost isn't the protocol, it's everything the client decides on its own. If the Dark Lord's raven is drawn wrong when he walks, if an item label is broken, if a window doesn't show a value the server has known all along: there is nothing you can do about it from the server side. You can't add a UI element for a feature you invented. You can't show a number the client has no field for. You can only work around it, and the usual workaround is a chat message.

That's the real reason. Not the missing bits - the missing say.

So I took the sources

In March 2023 I started to clean up the Season 5.2 sources which were made public, with the goal of getting them to Season 6 Episode 3. This doesn't replace the original client, full support for the original Season 6 client stays a goal of OpenMU. Most people running an OpenMU server will keep using the original client, and that's fine. The point is that there is now one client we can change, so we can find out what a MU server looks like when nothing forces it into 12 bytes.

What opened up

The nice surprise was how little the server needed for it. OpenMU has had a plugin system since 2019, and its whole purpose is that view implementations are selected by the client version at runtime - that's how 0.75, 0.95 and Season 6 clients can be served by the same server. So the new client just became another version: it announces itself as season 106, and about two dozen view plugins and serializers are registered for it, right next to the old ones. No fork of the server, no #if, no second code path in the game logic. The game logic doesn't even know.

What those extended plugins do differently:

• Damage and experience are sent once, with the values they actually have. The loops above are gone.
• The item serializer is dynamic, 5 to 15 bytes, with a flags byte that says which parts follow: option, luck, skill, excellent, ancient, harmony, guardian, sockets. The item number is a real 16 bit number, the level is a real byte. No bit smuggling, and there's room to grow.
• The appearance got 27 bytes instead of 18, which is what makes it possible to show things the old format had no space for.
• Monsters have a health bar after you hit them.
• The server tells the client which chat commands exist, so the command window can list them instead of expecting players to memorize them.
• Character list, stats, level, master stats, quests, mail, player shops - all got extended versions.

Was it worth it?

Honestly, it doubled the amount of code I look after, and the second half is a C++ codebase from 2005 with all the charm that implies. I've spent evenings on wchar_t widths and fclose calls instead of on game features.

But the ceiling is gone. When we now want damage to exceed 16 bit, we change a packet definition and both ends follow, instead of writing a loop that lies to the player. That's worth a lot of evenings.

Next time I'll write about how the client got rid of its C++ network code entirely and loads a .NET Native AOT library instead - which is the part where "one packet definition, both ends" actually becomes true.

My first attempts decrypting a captured packet using the newer SimpleModulus variant failed miserably. The provided dat-files (they contain the encryption keys) of the game client were too big to make sense for me, too. After a while, I realized they contain more keys than newer variants. The key files were also encrypted (simple XOR) and of course, the encryption key for the files was longer in earlier versions. To find the longer key, I searched in the old main.exe for the first values of the known key and found the others. I had luck that Webzen just shortened the key.

After a while I managed to decrypt the captured packet and refactored my code so that it's possible to support both variants.

To make a long story short, I summarize the difference to newer versions:

• The block size. In 0.75 it used a block size of 32 decrypted and 38 encrypted bytes, instead of 8 decrypted and 11 encrypted. One 16 bit value needs 18 bits in encrypted state (because the multiplication result is bigger), so you can basically calculate the encrypted block size as follows:

blockSize_encrypted = (blockSize_decrypted * 18 / 16) + 2

Cuando se busca una camiseta de club, es útil comparar medidas, corte y detalles de confección antes de decidir. Una referencia como comprar camiseta del Atlético de Madrid puede servir para revisar opciones generales sin depender de una sola característica. Revisar estos puntos reduce confusiones entre preferencias de uso, comodidad y cuidado de la prenda.

• More keys. Because blocks were bigger in earlier versions, they used more keys. Every 16 bit value is encrypted separately, so it uses 16 keys ( 32 decrypted bytes / 2 bytes).
• The missing counter. The old variant didn't use a counter in its header. The first byte in the first encrypted block was already the content. Webzen probably has added the counter in a later version to make replay attacks harder.

It's pretty interesting that Webzen actually decreased security in one aspect (key size/count) and increased it by a counter. I can just assume that they wanted to reduce the required network traffic and CPU utilization back at the time (~2002). Needless to say, this algorithm isn't secure, no matter which variant is used.