CHARACTER_SERVICES
Paid character rename and gender change
Two paid services on one capability. They travel as grants, through the same applyGrant path and
the same command journal as DELIVER_ITEM_GRANT — and in
the same envelope: what follows is the grant object, nested under grant in the command payload
documented there, with the character under target.
{ "type": "l2.character_rename", "schemaVersion": 1, "newName": "Ravenblade" }{ "type": "l2.gender_change", "schemaVersion": 1, "newSex": "female" }Before touching anything, validate: the name against ^[A-Za-z0-9]{1,16}$, that it is not a
reserved NPC name, and that no other character holds it. newSex is male or female and is the
gender the character will have, not a toggle — a stale toggle would be applied as-is.
Forgeport refuses a gender change on a Kamael before it is ever sent, in the purchase dialog and again at purchase: those classes come in gendered pairs, so flipping the gender alone leaves the character inconsistent.
When the client shows the change
The change is durable as soon as it is applied; rendering follows on its own schedule, and each family has its own answer. The extender described here returns the character to the selection screen, so the client rebuilds it with the new name and model. On L2J a rename shows immediately — the live character is updated and its info broadcast. A gender change is durable at once, but the client builds a character's model at selection, so the new model appears after a relog.
That is a property of your pack, which is why it is documented here for you rather than shown to the player — the portal sees the same applied grant either way.
Implementing it
The same applyGrant method, handling l2.character_rename and l2.gender_change.
For a rename, change the live character, update whatever name index the pack keeps — Mobius has
CharInfoTable, and a rename that skips it leaves the character findable only under the name it no
longer has — then persist and broadcast.
For a gender change, set the appearance and persist.
Do not try to force the model to refresh
Mirroring the built-in //set sex decay-and-respawn cycle so the new model appears without a
relog causes a client-side protection fault: self-decaying the locally-controlled character is
not safe in the classic client, even though decaying other players is. Apply a plain appearance
update instead. The change is durable either way; only the rendering waits for the relog the
player is getting anyway.
Verification
Connector check sets the character's gender to the value it already has — a real command with no visible effect. A connector that declines a change doing nothing passes on that answer: it proves the same round trip without writing. A Kamael test character is reported as skipped, since it can never be the target.