The Metin2 acce system is a costume-accessory mechanic that older servers never had but that has become almost standard on modern private servers. The idea is simple: you "socket" a regular item into a back accessory costume (the acce), and the acce absorbs a percentage of that item's bonuses and applies them to the character. In this guide I'll walk through how I add the mechanic from scratch, on both the server and client side.
What the acce system actually does
The classic costume system only changes the look; acce goes a step further. The player equips an accessory that changes the appearance, then puts a strong piece of armor, a weapon or another item inside it. The acce doesn't consume the item visually — it "absorbs" a fixed percentage of that item's bonus stats (for example damage against monsters, HP, critical chance) and grants them to the player as extra stats. So the player keeps the look they want and gains a hidden source of power. It's a great system that adds both collecting and power progression to your server.
Item proto: defining the acce costume
Everything starts in the item proto. Acce items are of type ITEM_COSTUME like a normal costume, but their subtype must be COSTUME_ACCE. In the item editor or the item_proto table:
- Type:
COSTUME - SubType:
ACCE - WearFlags: a flag for the equipment slot the accessory uses (usually a separate
WEAR_COSTUME_ACCEslot).
This subtype is what tells the server "this item is an acce and can hold another item inside it." You also need a .gr2 model and an icon for the visuals, but the mechanic relies entirely on the subtype and the sockets.
Sockets: storing the absorbed item
In Metin2 every item has a few socket slots (normally used for metin stones / diamonds). For the acce we reuse those sockets to store information about the item placed inside. The cleanest approach is to define which socket holds what with constants:
// item.h — what will the acce sockets hold?
enum EAcceSocket
{
ACCE_ABSORBED_VNUM_SLOT = 0, // vnum of the absorbed item
ACCE_ABSORB_PCT_SLOT = 1, // absorption percent (e.g. 50 = 50%)
};
So when the player absorbs an item in the acce window, the server writes that item's vnum to socket0 and the calculated absorption percentage to socket1. Because sockets are saved to the database along with the item, this information survives even if the server restarts — that's exactly what makes the acce system persistent.
Applying the absorbed bonuses to the player
The real work is calculating the absorbed item's bonuses and adding them to the character while the acce is equipped. We read the absorbed vnum from the acce's socket, look up that item's proto, and multiply its apply bonuses by the percentage:
// char_item.cpp — apply bonuses when the acce is worn / removed
void CHARACTER::__ApplyAcceAbsorb(LPITEM pAcce, bool bAdd)
{
if (!pAcce || pAcce->GetSubType() != COSTUME_ACCE)
return;
DWORD dwVnum = pAcce->GetSocket(ACCE_ABSORBED_VNUM_SLOT);
int iPct = pAcce->GetSocket(ACCE_ABSORB_PCT_SLOT);
if (dwVnum == 0 || iPct <= 0)
return;
TItemTable * pProto = ITEM_MANAGER::instance().GetTable(dwVnum);
if (!pProto)
return;
for (int i = 0; i < ITEM_APPLY_MAX_NUM; ++i)
{
BYTE bType = pProto->aApplies[i].bType;
long lValue = pProto->aApplies[i].lValue;
if (bType == APPLY_NONE || lValue == 0)
continue;
long lAbsorbed = (lValue * iPct) / 100;
ApplyPoint(bType, bAdd ? lAbsorbed : -lAbsorbed);
}
}
You call this function where the character recomputes its stats — that is, inside ComputePoints() while equipped items are processed:
// char.cpp — inside ComputePoints() while processing equipment
LPITEM pAcce = GetWear(WEAR_COSTUME_ACCE);
if (pAcce)
__ApplyAcceAbsorb(pAcce, true);
Since ComputePoints() rebuilds stats from zero, here we always add with true; when the player removes the acce, the next recompute clears the bonus automatically. The bAdd parameter is handy for un-applying live, without a full recompute.
The acce window: packet flow and client
For the player to drag an item into the acce, you need a UI window. This is drawn on the client with uiacce.py (a Python root file) and talks to the server through custom packets. The typical flow is:
- The player right-clicks the acce → the client sends
HEADER_CG_ACCE_REFINE_OPEN, the server opens the window. - The player puts the acce item and the item to absorb into the slots.
- On pressing "Combine," the client sends
HEADER_CG_ACCE_REFINE; the server calculates the absorption percentage, writes the sockets and reports the result withHEADER_GC_ACCE_REFINE_RESULT.
You must define these packet headers with the same number on both client and server in packet.h — a mismatch causes an instant client "crash." Also remember to add the required lines to locale_game.txt for the window's text.
Absorption rates and common mistakes
How you decide the absorption percentage is entirely a balance choice. Two common methods exist: a fixed rate (for example always 50%), or a variable rate read from a table based on the item's level/grade. A variable rate gives more balanced results because you can automatically cap how much very strong items absorb. Here are the most common mistakes:
- Sockets not saved: after the absorb operation, make sure you persist the item to the database after the
SetSocket()call; otherwise the bonus vanishes on restart. - Double bonus: if you call
__ApplyAcceAbsorbboth inComputePointsand again on equip, the bonus is doubled. Manage it from a single place. - Wrong equipment slot: if you don't define a separate
WEARslot for the acce, it collides with the normal costume. - Packet number mismatch: if the client and server headers differ, the window won't open or it crashes.
Frequently asked questions
Does the item placed in the acce disappear?
In the classic mechanic, yes — the absorbed item is consumed and only its bonus remains. Some servers make the item removable; in that case you also need to store the item's attributes in the sockets and give them back on a "remove" action.
Is the acce bonus affected by the worn item's level limit?
No. The acce's own LimitType fields (such as a level limit) apply; the absorbed item's level requirement isn't applied directly. You balance it through the acce's own limits.
Can this system be added to an existing source later?
Yes. The acce system is fully modular: a new subtype, a few functions, packet headers and a client window. It can be added without touching existing quest, item or costume systems.
Want a complete acce system on your server? From the proto to the client window, from absorption balance to database persistence, I can build the whole chain — get in touch.