GMCP Packages

This document describes LegendMUD’s GMCP (Generic MUD Communication Protocol) support from the client’s point of view: how to enable it, what you can request, what the server pushes on its own, and the exact shape of every payload. It is written for people building or scripting MUD clients (Mudlet, TinTin++, custom clients, etc.). No knowledge of the server code is needed — or useful — here.

In-game, HELP GMCP covers the basics.

---

1. Enabling GMCP

GMCP is telnet option 201. On connect the server offers it:

server → client:   IAC WILL 201
client → server:   IAC DO   201     (enables GMCP)
client → server:   IAC DONT 201     (disables GMCP)

Most scriptable clients handle this negotiation for you and expose GMCP events directly. Nothing is sent over GMCP until you answer IAC DO 201.

All GMCP traffic — both directions — is framed as telnet sub-negotiation:

IAC SB 201  <package name> [<JSON payload>]  IAC SE

A single space separates the package name from the JSON when a payload is present.

2. Making requests

Send the package name, optionally followed by JSON arguments:

char.score
object.info {"oid":"0x1a2b3c4d5e6f7890"}

Rules:

• Package names are case-insensitive (Char.Score works), and must be dotted — at least word.word.
• JSON keys are case-sensitive, in both requests and replies.
• Most packages take no arguments; any request body they receive is ignored. The exceptions are object.info and char.inventory (an oid), help.topic (keywords), and char.journal.entry (vnum).
• Requests are size-capped: package name up to 49 characters, JSON body up to 399 characters.
• A malformed request, unknown package, or invalid JSON gets a logging.error reply (see §7) rather than silence.

Every reply arrives as its own GMCP message, tagged with the package name. One request can produce several messages (spells.all sends four).

3. Reading the reference: conventions

• Request-only — sent only when you ask. Most packages.
• Pushed — sent by the server when game state changes, whether or not you asked (§5 lists them).
• *.all packages are static reference data. They describe the game, not your character, and do not change during play. Request each once per session, cache it, and join the per-character packages against it by id.
• Ids are stable for your session but not guaranteed across server reboots for every package (each entry below says which field is the durable identifier). The safe pattern is: fetch *.all once per login, join on id from there.
• Empty means empty. Per-character list packages always reply, even when the answer is “none” — a non-chanter asking for char.spells gets {"spells": []}, not silence. You can rely on a reply to every valid request.
• All numbers are raw integers — no display formatting, no commas.

4. Package reference

4.1 Character basics

char.prompt — pushed on every prompt, also requestable

An object keyed by prompt tokens: hit points, mana, movement, position, room, gold, opponent condition, and everything else the text prompt can show. Immortal-only tokens are omitted for mortals.

By default the keys are the short prompt codes. Turn on the gmcplongpromptkeys config option in-game to get verbose, self-describing keys instead — recommended for new clients. See HELP GMCPLONGPROMPT.

char.prompt.delta — opt-in, pushed only

Off by default — nothing about char.prompt changes until you ask. Opt in with:

char.prompt.delta { "on": true }

Once opted in:

• Every prompt render — whether you typed something or game output re-rendered it — arrives as char.prompt.delta containing only the keys whose values changed since the last message you were sent. Do not expect a full after your own commands.
• Nothing changed → nothing arrives at all, not even an empty {}. Don’t use either package as a heartbeat — if your UI needs a “prompt happened” signal, use the telnet prompt line instead.
• Fulls are rare and always meaningful. You get a full char.prompt only: right after opting in (your starting baseline), when you request one, after SHOWPROMPT, or when the server must rebase you (reconnect, key-style toggle, immortal-status change, character change). If you want a full, ask for it.

Send char.prompt.delta { "on": false } to go back to full-every- render. The setting is per connection and does not persist — re-send it every session. The first prompt after opting in is always a full char.prompt.

Merging deltas: keep a cumulative baseline — your last full char.prompt, updated by every char.prompt.delta since — and apply each delta as a key-by-key overwrite; your model then always matches the server’s. No key ever disappears from the schema — a key absent from a delta simply hasn’t changed. A value that goes away (e.g. f/fighting_name when combat ends) arrives as JSON null rather than being omitted — treat null as an ordinary value, in both directions (null → value and value → null are both changes). Deltas use whichever key style (short or gmcplongpromptkeys) your connection is set to, same as char.prompt; toggling that setting mid-session forces the next message to be a full char.prompt under the new names.

Resync any time: request char.prompt and you get a full package; the server resets its baseline to match, so the deltas that follow are relative to that full — use this if you ever suspect drift. A full can still arrive unrequested (the rebase cases above) and always replaces your entire prompt state; never diff a full against your model, just adopt it.

Values in a delta are byte-identical to what the same key would carry in a full char.prompt — same types, same formatting, only the selection of keys differs. Immortal-only keys follow the same present-for-imms/absent-otherwise rule as fulls.

char.score — request-only

A single snapshot of the full score sheet, grouped:

{
  "identity": {
    "name": "Merlin", "pretitle": "the Great", "title": "Mighty Wizard",
    "posttitle": "of the Tower", "sex": "Male", "age": 156,
    "played": 5000000, "hometown": "Midgaard", "clan": "Archmages",
    "level": 25, "align": 450, "practices": 15, "redemptions": 0,
    "pvp": "PKE, PKOK", "area": "The Midgaard Forest"
  },
  "vitals":  { "hp": 180, "maxHp": 250, "mana": 400, "maxMana": 500,
               "move": 120, "maxMove": 150 },
  "stats":   { "str": 18, "min": 16, "dex": 17, "con": 16, "per": 14,
               "spi": 15, "prestige": 2 },
  "combat":  { "ac": -45, "hitroll": 28, "damroll": 35, "damcap": 400,
               "spellCrit": 12, "spellDam": 25, "concentration": 10,
               "manaReduction": 15, "damageShield": 8,
               "mitigation": { "cur": 120, "cap": 300 },
               "parry": 5, "wary": 0, "wimpy": 0, "rangedAccuracy": 0,
               "weaponSpeed": 2, "critChance": 8, "critBonus": 25,
               "meleeDamMod": 0, "dodge": 12, "block": 15 },
  "regen":   { "hp": 50, "mana": 80, "move": 40 },
  "xp":      { "total": 2500000, "toLevel": 150000, "eraSplitPct": 50,
               "era": {
                 "ancient":    { "exp": 750000, "levels": 15, "used": 10, "free": 5 },
                 "medieval":   { "exp": 1000000, "levels": 20, "used": 15, "free": 5 },
                 "industrial": { "exp": 0, "levels": 0, "used": 0, "free": 0 }
               } },
  "carry":   { "items": 25, "weight": 450, "maxWeight": 500,
               "rent": 1200, "maxRent": 2000 },
  "gold": 50000,
  "bank": 100000,
  "resistances": [ { "name": "fire", "value": 15 },
                   { "name": "cold", "value": -10 } ]
}

Nullable fields — treat null as “not applicable”:

• identity.clan — no clan; identity.area — unknown area.
• xp.toLevel — null above level 50 (no further levels). Below 50 it is XP to the next level; at exactly 50, XP to redeem.
• xp.eraSplitPct and every xp.era.*.exp — null below level 50 for non-remorts (the text SCORE shows ? there; the detail is hidden until you reach 50).
• carry.maxRent — null above level 50 (unlimited).

sex is "Male", "Female", or "Other". pvp is "PKE", "PKOK", "PKE, PKOK", or "none". resistances has one entry per nonzero damage modifier; empty array when you have none.

Conditions, affects, and timers are deliberately not here — see char.status.

char.status — request-only

{ conditions, affectedBy, timers }, each an array or null. Three sub-packages return one slice each, in the same shapes:

• char.status.conditions → { "conditions": ["hungry", …] | null }
• char.status.affectedby → { "affectedBy": [{ "time", "name", … }, …] | null } — time is remaining seconds; stacked copies of the same affect collapse into one entry. Each entry can also carry applies, grants, dmgMods, resists, immunities, and susceptibilities — see below. The affectedBy member embedded directly in char.status is built the same way and carries identical entries.

Affect payload — additive, no opt-in, no new package. time and name are unchanged; disposition is always present; every other new key is omitted when it would be empty, so a { "time", "name", "disposition" } entry is still normal and common (e.g. a flag-only or otherwise-inert affect). Example of a fully-loaded entry:

{
  "time": 512,
  "name": "armor of faith",
  "disposition": "beneficial",
  "applies":          { "ac": -20, "saving_spell": -2 },
  "grants":           [ "sanctuary" ],
  "dmgMods":          { "slash": 10 },
  "resists":          [ "fire" ],
  "immunities":       [ "poison" ],
  "susceptibilities": [ "cold" ]
}

• disposition — always one of "beneficial", "detrimental", or "neutral"; how the game classifies the affect (the same classification that colors the affect’s name green/red in the text affects list). If an affect somehow carries both classifications, detrimental wins. Exactly these three strings — but treat an unknown value as neutral rather than erroring, per the usual forward-compatibility rule. Beneficial affects are player-removable: a UI may offer a remove control on "beneficial" entries that sends removeaffect <name> (the entry’s name verbatim) — word the player-facing confirmation Remove <name>?, not the command name. Don’t offer it on detrimental/neutral entries; the server refuses those.
• applies — object, numeric stat modifiers this affect currently contributes. Keys are stat names (strength, saving_spell, hp_regen, ac, …); values are signed JSON ints (negative values are normal and mean the same thing they do everywhere else — e.g. lower ac is better).
• grants — array of flag names this affect grants (e.g. "sanctuary", "detect_invis").
• dmgMods — object of damage-type → signed percent modifier, e.g. { "slash": 10 } means +10% slash damage. Its damage-type names heavily overlap with resists / immunities / susceptibilities (flame, poison, slash, …) but the sets are not identical — each key’s vocabulary comes from its own server table. Don’t build one fixed shared list; treat each key’s names as its own open vocabulary and ignore unknowns.
• resists / immunities / susceptibilities — arrays of damage-type names this affect resists, grants immunity to, or makes the character more susceptible to.
• All key/value vocabularies are mechanical lowercase of the game’s internal names — the same information STATUS full shows a player for that affect, just structured instead of prose. Key names are the server’s mechanical internal names, which sometimes differ from the friendly labels STATUS prints (e.g., mod_buf_hitroll is the HITROLL line). This is forward-compatible: new names can appear with no protocol change, so ignore any key or value you don’t recognize rather than treating it as an error.
• If an affect contributes to the same stat/damage-type more than once (e.g. two stacked sources folded into one entry), the value you receive is already the summed total — you never need to add entries together yourself.
• char.status.timers → { "timers": [{ "name", "time" }, …] | null } — skill/ability reuse timers.

char.offer — request-only

Mirrors the OFFER command: { "items": [{ "name", "rent", "count" }, …] | null, "totalRent", "totalItems" }.

char.colors — request, login push, and config-change push

The player’s own condition colors (the mud’s color slots 16–20) in compiled form, so you can tint hp/mana/mv gauges, prompt tiles, and group bars exactly the way the player’s text prompt does. Request with an empty body; also pushed once at login/reconnect and whenever the player’s color config changes (color set / color scheme / color set default). Every message is a full snapshot — adopt it wholesale, never merge. Always complete (scheme defaults fill slots the player never touched), never {}.

{ "condition": {
    "full":     { "fg": 2,  "bg": -1, "attrs": [] },
    "low":      { "fg": 10, "bg": -1, "attrs": [] },
    "medium":   { "fg": 3,  "bg": -1, "attrs": ["bold"] },
    "bad":      { "fg": 1,  "bg": -1, "attrs": ["bold"] },
    "critical": { "fg": 9,  "bg": -1, "attrs": ["blink"] }
} }

fg/bg are classic 16-color palette indices (0–7 normal, 8–15 bright) or -1 for terminal default; render through the same palette your output pane uses for ANSI SGR. attrs draws from "bold", "dim", "italic", "underline", "blink", "reverse" — same semantics as the SGR attributes in output text (bold can appear alongside a 0–7 fg instead of a bright 8–15 fg; render both like the output pane would; reinterpreting blink as a gentle pulse is fine). Ignore keys you don’t recognize, at both the group and color-object level — more groups may be added without a version bump.

Pick the tier with the server’s integer arithmetic, in this order, on the same cur/max you already have from vitals data — do NOT reformulate as percentages (rounding disagrees at the boundaries):

cur >= max            -> full
cur <= max / 10       -> critical
cur <= max / 4        -> bad
cur <= max * 2 / 3    -> medium
otherwise             -> low

If max <= 0 or the values are hidden, the mud shows ?? uncolored — fall back to your untinted rendering rather than guessing a tier. Full contract: docs/updates/2026-07-15-gmcp-char-colors-client-spec.md.

4.2 Room and world

room.info — pushed on movement and look, also requestable

{ "name": "...", "desc": "...", "area": "...", "vnum": 3001,
  "type": "indoors", "is_inn": false,
  "exits": [ { "dir": "north", "door": "closed",
               "to_name": "A Quiet Lane", "to_vnum": 3005 }, … ] }

• Darkness: if your character can’t see, name and desc are both "It is too dark to see..." and exits is omitted entirely.
• Blindness: exits is omitted while blind, whatever the light.
• area is present only when the room belongs to a known area.
• vnum is present for every room except rooms inside transient instances, whose recycled vnums are meaningless and suppressed. The same applies to to_vnum on exits. Don’t key persistent mapper data on instance rooms.
• type is always present: one of "indoors", "underwater", "aerial", "water", "outdoors".
• is_inn is always present and is character-dependent: whether you could rent here right now (false while fighting, for example). It is not a fixed property of the room. Immortals always see false.
• exits mirrors the in-game autoexit line, including its secrecy rules — hidden or unrevealed exits simply don’t appear. Per exit: dir always; door only for door exits ("open", "closed", or "locked"); to_name only when the destination’s name is visible.

4.3 Objects, inventory, equipment

Objects are identified by OID — an opaque 64-bit id rendered as a hex string with a mandatory 0x prefix (e.g. "0x1a2b3c4d5e6f7890"). Always send it back exactly as you received it, prefix included. OIDs are how the three packages below link together.

You can only look up objects your character can actually see — the same visibility rules as in-game. An unknown, invalid, or unseen OID gets { "oid": "<what you sent>", "found": false }.

object.info — request with {"oid": "..."}

Full detail for one object. The reply always echoes the requested oid. When found and visible:

• Core fields: oid, name (keywords), short, desc, type (item-type name), weight, rent, size, ac, timer.
• condition: { "dam", "damMax" } — only when the item has a damage / repair ceiling.
• flags[] — every item flag set on the object, present only when at least one is set. Names are the lowercase flag words: "glow", "magic", "invis" (the item is invis but you can see it anyway — style it accordingly), "no_repair", "no_backstab", "unique", and so on. New flags appear automatically as the game adds them, so ignore names you don’t recognize.
• wearFlags[] — wear-position names.
• A per-type block keyed by the item type, with named fields for that type. Nearly every item type in the game has one; the ones you’ll see most:
  • weapon: { attack, maxDam, quality, speed } — speed is the effective base speed factor. Weapons with an on-hit spell add spellChance, spell, spellLevel; weapons with a secondary attack add secondaryAttack, secondaryMaxDam (and secondarySpellChance/secondarySpell/secondarySpellLevel when the secondary carries a spell). Plain weapons omit all of those.
  • armor: { acApply, material }
  • container: { capacity, capWeight, capSize, flags, keyVal, weightReduction }
  • gun: { numDice, diceSize, charges, maxCharges, ammoType, jamChance, explodeChance, accuracy }, ammo: { ammoType, shots[, affect] }
  • light, drink, food, wand, staff, scroll, potion, pill, money, key, oil, powder, rune, spelltool, spellbook, instrument, fountain, furniture, boat, bundle, vehicle, currency, currencyPile, tool, fuel, manaStore, map, lock, board, note, seeds, bandage, medicament, medicalTool, dressing, portal, attack, grenade, corpse (NPC corpses: { mobVnum, undead, skinVnum }), and a few more — every field is a named integer (or string where noted), so render what you receive.
  • Item types without an interpreted block (decorative/misc items, and a few whose values are internal state) simply omit it.
• affects[] — [{ "stat", "mod" }, …], plus { "stat": "dmgmod", "mod", "pct" } entries for damage-modifier affects.
• props{} — the object’s key/value property table, when it has one.

char.inventory — request, two modes

• No arguments → your base inventory (held, unworn items): { "items": [ { …object detail… }, …] }. Each row is a complete object.info detail object — no per-item follow-up fetch needed.
• {"oid": "<container>"} → that container’s direct contents: { "oid", "items": [ … ] }, same full-detail entry shape. A closed container answers { "oid", "closed": true, "items": [] } (same rule as look in). Not found / not visible → { "oid", "found": false }.

Tell the two reply modes apart by the oid key: container replies have it, base-inventory replies don’t.

Paging: replies carry at most 100 rows. A capped reply adds "more": true and "offset": <n>; re-send the same request with that offset added (e.g. {"oid": "…", "offset": 100}) to get the next page, until a reply arrives without more. Most inventories fit in one page.

To walk someone’s whole carry tree, request base inventory, then request each container row’s oid as you (or the user) open it — one container level per request.

char.inventory is request/reply only — it never pushes. For live updates as your inventory changes during play, see char.items.update below.

char.items.update — pushed only, coalesced per moment

Tells you about every object-state change on your character’s person: picked up, dropped, given, worn, removed, moved in or out of a carried container, destroyed, and (over time) in-place changes like charges and condition. Changes are coalesced server-side — no matter how many things happen to your stuff in one game moment, you get at most one frame describing the net result, per moment. wear all, remove all, and death each arrive as one message with final state, not a hail of per-item deltas.

{ "changed": [
    { "loc": "inv",                    "item": { …object detail… } },
    { "loc": "worn:head",              "item": { … } },
    { "loc": "in:0x1a2b3c4d5e6f7890",  "item": { … } }
  ],
  "removed": [ "0xaabbccddeeff0011" ],
  "more": true
}

• item is exactly an object.info detail object — the same one char.inventory rows and char.equipment items use.
• loc says where the object now lives: "inv" (carried, unworn, top level), "worn:<slot>" (the same slot vocabulary as char.equipment, below), or "in:<container-oid>" (direct container only — for nested bags, reconstruct the tree by following each object’s own loc oid).
• removed — oids no longer anywhere on your character. Dropped, given away, put into a container that isn’t carried, or destroyed: all identical here. It means “off your person,” not “gone from the world.” Removal of an oid you’ve never seen is a no-op — silently ignore it, never error (an item picked up and dropped in the same moment can arrive only as a removal).
• An oid appears in exactly one of changed/removed per frame. Both keys are omitted when empty — treat a missing key as []; every frame has at least one of them.
• more: true means a large burst is being delivered across several frames and the rest follows within the next second or so. Each frame is self-contained and correct on its own; more is a hint (e.g. to debounce a re-sort), not something you must handle.
• Coalescing means final-state-only: if an item is worn and removed in the same moment, you get one changed row with its final location — intermediate states are never sent.
• There is no replay. char.items.update only carries deltas from the moment you’re connected forward. On login or reconnect, request char.inventory and char.equipment as usual to get your baseline, then let pushes keep it current.

Recommended model: one oid-keyed map (oid -> {loc, item}) for everything on your character. changed upserts by item.oid; removed deletes by oid. Inventory panel = entries with loc == "inv"; equipment panel = entries with loc starting "worn:"; a bag’s contents = entries with loc == "in:<bag's oid>". Full detail, including an incremental adoption ladder (you don’t have to build the full merge on day one), is in docs/updates/2026-07-14-gmcp-char-items-update-client-spec.md.

char.equipment — request-only

Request (no arguments) → full snapshot:

{ "full": true,
  "equipment": [ { "slot": "wield", "item": { …object detail… } }, … ] }

item is exactly an object.info detail object. Empty equipment array when nothing is worn.

Slot keys are unique per body position (left and right are distinct, so keying your equipment map by slot never clobbers a pair):

light, finger_l, finger_r, neck_1, neck_2, body, head, face, legs,
feet, hands, arms, shield, about, waist, wrist_l, wrist_r, wield,
held, ear_l, ear_r, arm, aux, amulet

A slot the server can’t classify reports as "unknown" rather than being dropped.

2026-07-14: no more pushed deltas. char.equipment used to also push per-item "full": false deltas as you wore/removed things, coalesced during bulk wear/remove into one full: true snapshot. Those pushes are gone — equipment changes now arrive through char.items.update (above), which covers your whole person, not just worn items. char.equipment is request/reply only now: fetch it for your initial snapshot and whenever you want to resync your equipment map from scratch.

4.4 Skills

skills.all — static reference, request once per session

{ "skills": [
    { "name": "kick",    "slot": 63, "type": "fight",  "trainLevels": [] },
    { "name": "bandage", "slot": 12, "type": "druid",  "trainLevels": [15, 25] }
] }

• One entry per skill, in slot order. slot is the durable identifier — join char.skills on it.
• type is the school: weapon, fight, merchant, rogue, thief, druid, medical, bardic, gun, mage, runic, ranger, miscellaneous, or none.
• trainLevels — character levels where extra training tiers unlock (the raw schedule, not adjusted for your character); empty for single-tier skills. Total tiers = trainLevels.length + 1.
• Spells are not in this table — see §4.5.

char.skills — your skill standing

{ "skills": [
    { "slot": 63, "qualifies": true,  "known": 1 },
    { "slot": 12, "qualifies": false, "known": 2 }
] }

The union of the SKILLS and ALLSKILLS views. A slot appears iff you’ve learned it or currently qualify for it:

state	qualifies	known
qualify, haven’t learned	true	0
learned and still qualify	true	> 0
learned, lost the prerequisites	false	> 0

known is the trained tier count, not a percentage.

4.5 Magic: spells and words

spells.all — static reference; one request, four replies

Requesting spells.all sends four messages, one per school batch: spells.know, spells.create, spells.cause, and spells.noschool (wordless spells — includes affect-carriers and procs, so you can name any slot you ever see). Each has the same shape:

{ "spells": [
    { "name": "identify", "slot": 530, "mana": 10, "listed": true,
      "words": [1], "categories": ["utility"], "element": "none" },
    { "name": "immolation", "slot": 657, "mana": 52, "listed": true,
      "words": [5, 14, 20], "categories": ["dd"], "element": "fire" }
] }

• slot is the durable identifier — join char.spells and char.spell.update on it.
• mana is the base cost. listed = appears in ALLSPELLS.
• words — word ids in chant order (0–3 of them; always empty in spells.noschool, never empty in the other three). Join against words.all.
• categories — what the spell does: dd (direct damage), dot (damage over time), buff, debuff, heal, summon, utility, necromancy. A spell can carry several (drown is ["dd","dot"]); placeholder slots carry [].
• element — the damage flavor for dd/dot spells: fire, ice, magic, death, or other. Always present; "none" for non-damage spells.

words.all — static reference

{ "words": [
    { "id": 1,  "name": "vid",  "meaning": "know", "circle": 1 },
    { "id": 14, "name": "agni", "meaning": "fire", "circle": 3 }
] }

All words, in id order. The stat/level requirements for learning a word are deliberately not exposed — char.words’s qualifies field is the verdict.

char.words — your word standing

{ "words": [
    { "id": 1, "learned": true,  "qualifies": true },
    { "id": 3, "learned": false, "qualifies": true },
    { "id": 8, "learned": true,  "qualifies": false }
] }

Union of the WORDS and ALLWORDS views; same three-state logic as char.skills. Non-chanters get { "words": [] }.

char.spells — your spellbook

{ "spells": [ { "slot": 507, "level": 12 }, { "slot": 530, "level": 3 } ] }

Every spell you’ve cast at least once. level is the displayed spell level from SPELLBOOK. Non-chanters get { "spells": [] }.

char.spell.update — pushed only

A single-spell delta with char.spells field semantics, pushed when a spell’s level changes through play — first cast ("level": 0), mastery gain, or spellbook study:

{ "slot": 507, "level": 13 }

Not requestable. Administrative bulk changes to a character’s spells do not push updates — if you have reason to think that happened, re-request char.spells.

4.6 Runes

runes.all — static reference

The full rune table, as RUNES FULL would show a master runecaster:

{ "runes": [
    { "id": 0, "name": "fehu", "aett": "Freyr", "cost": 12,
      "costMerkstave": 12, "merkstave": true,
      "description": "Restores movement over time. Merkstave: ..." },
    { "id": 7, "name": "wunjo", "aett": "Freyr", "cost": 24,
      "costMerkstave": 0, "merkstave": false,
      "description": "Fast mana regeneration." }
] }

• id is fully durable (it never changes, even across reboots).
• aett is Freyr, Heimdall, or Tyr — 8 runes each, in id order.
• Costs are base values; if the caster has aett focus, the effective cost is one third — apply that client-side if you display costs.
• merkstave = the rune can be cast reversed; costMerkstave is 0 when it can’t.

char.runes — your learned runes

{ "runes": [0, 2, 5, 11] }

Just the learned ids, in order. Non-runecasters get { "runes": [] }.

4.7 Era abilities

abilities.all — static reference

{ "abilities": [
    { "id": 0, "key": "ClearCasting", "name": "Clear Casting",
      "era": "ancient", "maxLevel": 3, "pk": false },
    { "id": 8, "key": "DeathtrapAvoidance", "name": "Deathtrap Avoidance",
      "era": "industrial", "maxLevel": 5, "pk": false }
] }

• id is stable for your session; key is the durable identifier across reboots. Fetch abilities.all once per login and join char.abilities on id.
• era is ancient, medieval, or industrial.
• maxLevel is the training cap for that ability.
• pk: true marks abilities that stop working while you carry pk damage (they still appear in char.abilities — it’s a use-time gate, not a listing gate).

char.abilities — your earned abilities

{ "abilities": [ { "id": 0, "level": 2 }, { "id": 7, "level": 3 } ] }

level runs 1..maxLevel. Characters who haven’t earned any era abilities get { "abilities": [] }.

4.8 Tradeskills

tradeskills.all — static reference

{ "tradeskills": [
    { "id": 0, "name": "smithing", "limited": true },
    { "id": 7, "name": "farming",  "limited": false }
] }

• id is stable for your session; name is the durable identifier.
• limited: true marks the tradeskills that share the capped skill pool; unlimited ones can all be raised freely.
• Recipes are intentionally not available over GMCP.

char.tradeskills — your levels

{ "tradeskills": [
    { "id": 0,  "level": 42, "title": "hobbyist" },
    { "id": 11, "level": 1,  "title": "beginner" }
] }

Every tradeskill you can use, including level-0 rows — the same list the TRADESKILLS command prints. (Mortals don’t see enchanting unless they currently have access to it.) title is the proficiency bracket: beginner, dabbler, hobbyist, apprentice, journeyman, master, grand master.

4.9 Factions

char.factions — your standings

{ "factions": [
    { "vnum": 13306, "name": "Yama Temple", "value": 1000,
      "min": 0, "max": 2000, "status": "Indifferent" },
    { "vnum": 33500, "name": "Iceland Explorers", "value": 0,
      "min": 0, "max": 2999, "status": "Unknown" }
] }

• One entry per faction you have a standing with (hidden factions are never sent). vnum is fully durable.
• value is your current standing; min/max are that faction’s bounds — enough to draw a meter.
• status is the faction’s own label for your current standing; "Unknown" when your value falls outside its labeled ranges (the FACTIONS command shows the same).
• There is no factions.all; each entry already carries the static fields a client needs.

4.10 Moods

moods.all — static reference

{ "moods": [
    { "id": 0,  "name": "normal" },
    { "id": 27, "name": "cheerful" }
] }

Every mood, in id order — the same list the MOODS command prints. All moods are available to all players. id is stable for your session; name is the durable identifier.

char.moods — your mood settings

{ "combat": 27, "talk": 0, "walk": 0, "social": 0, "temporary": null }

The mood id set in each of the four categories; 0 is normal, the default. temporary is the one-shot mood override that the next mood-bearing action consumes — null when none is pending, which is nearly always. Join the ids against moods.all for names.

4.11 Groups

group.info — request-only

{ "groups": [
    { "name": "Merlin", "longName": "Merlin the Great", "level": 25,
      "position": "Standing", "rank": "L",
      "hp": 180, "maxHp": 250, "mana": 400, "maxMana": 500,
      "move": 120, "maxMove": 150, "agg": 0, "sameRoom": true }, …
] }

rank is a single character: L = leader, f = the character you follow, 2 = next-in-line leader, space = ordinary member. sameRoom is true when that member is in the same room as you — useful for graying out members you can’t currently assist.

4.12 Help

help.topic — request with {"keywords": "..."}

Fetches a helpfile — the same content the HELP command prints, without the banner.

help.topic {"keywords": "pk"}

{ "keywords": "pk", "found": true,
  "title": "PK PKILL PLAYERKILLING",
  "text": "Pkill, also known as Playerkilling, …" }

• Keywords resolve exactly like HELP: case-insensitive, and aliases work (pk finds the pkill file). Omit keywords (or send {}) and you get the same summary a bare HELP shows, with "keywords": "summary" echoed back.
• title is the topic’s keyword line, uppercased — use it as the window header. text is the raw helpfile body (plain text with newlines).
• found: false (with empty title/text) means no helpfile you can read matches — nonexistent and restricted topics are indistinguishable by design.
• The reply always has these four fields, so you can parse it with a fixed shape.

4.13 Journal

char.journal — request, also pushed

Your full quest journal — every entry you currently hold, complete and incomplete alike:

{ "entries": [
    { "vnum": 4108, "name": "The Lost Heirloom", "area": "midgaard",
      "complete": false, "stagesDone": 1, "stagesTotal": 3,
      "lastUpdated": 1752438000 },
    { "vnum": 4200, "name": "Trial by Fire", "area": "asgard",
      "complete": true, "stagesDone": 2, "stagesTotal": 2,
      "lastUpdated": 0 }
] }

• One row per entry you hold, in catalog order. stagesDone equals stagesTotal once complete is true; otherwise it’s how many stages you’ve finished so far.
• lastUpdated is a raw epoch-seconds timestamp — format it client-side. It can be 0 on an entry you haven’t touched this session: the timestamp isn’t saved to your player file, so it only starts counting once something about that entry changes while you’re online (added, a stage completes, it completes, or it’s removed).
• An empty journal replies { "entries": [] }, same as any other per-character list package.
• Pushed: the server re-sends this same full snapshot — not a delta — every time a journal entry is added, a stage completes, an entry completes, or an entry is removed. Treat every char.journal message (requested or pushed) as a full replace of your local list.

char.journal.entry — request with {"vnum": N}

Detail for one journal entry:

char.journal.entry {"vnum": 4108}

{ "vnum": 4108, "found": true, "name": "The Lost Heirloom",
  "area": "midgaard",
  "description": "An old family amulet has gone missing from the manor.",
  "complete": false,
  "stages": [
    { "id": 1, "text": "Find the amulet.", "done": true },
    { "id": 2, "text": "Return it to Lady Anne.", "done": false },
    { "id": 3, "text": "Report back to the mayor.", "done": false }
  ] }

• stages always lists every stage’s text, whether done or not — a complete entry reports every stage done: true.
• Never pushed — if you keep a detail pane open for an entry, re-fetch it after the next char.journal push.
• Unknown, unheld, and malformed requests all get the same reply: { "vnum": N, "found": false } — nothing else. That covers a vnum that doesn’t exist, a real quest vnum you don’t currently hold, and a request with a missing or non-numeric vnum (which echoes back as 0). This is deliberate: the reply gives you no way to tell “no such quest” from “not your quest,” so char.journal.entry can’t be used to fish for quests in the game you haven’t found yet.
• There’s no journals.all — LegendMUD doesn’t ship a static catalog of every quest in the game the way it does for skills or spells, since that would spoil quests you haven’t discovered. Fetch char.journal for what you hold, and char.journal.entry per vnum for detail; don’t wait for a bulk catalog package that isn’t coming.

5. What the server pushes

Everything else is request-only. These arrive on their own:

Package	When
char.prompt	every prompt — your main live-vitals feed
char.prompt.delta	opt-in: changed prompt keys only on output-triggered renders
room.info	every room change and LOOK
char.items.update	any object-state change on your person (get, drop, wear, remove, container moves); at most one coalesced frame per game moment
char.spell.update	a spell’s level changes through play
char.journal (full snapshot)	a journal entry is added, a stage completes, an entry completes, or an entry is removed
char.colors (full snapshot)	once at login/reconnect, then whenever the player’s color config changes
logging.error	your request couldn’t be handled

char.equipment no longer pushes — it’s request/reply only now (§4.3). Use char.items.update to keep your equipment and inventory current.

A practical session bootstrap:

1. Negotiate GMCP (§1).
2. Request the static tables you care about: skills.all, spells.all, words.all, runes.all, abilities.all, tradeskills.all, moods.all.
3. Request your character’s state: char.score, char.status, char.skills, char.spells, char.words, char.runes, char.abilities, char.tradeskills, char.factions, char.moods, char.inventory, char.equipment, group.info, char.journal.
4. Let the pushes keep prompt, room, inventory/equipment (via char.items.update), journal, and colors current (char.colors arrives on its own at login); re-request anything else when you want it fresh (e.g. group.info on a timer, char.factions after questing).
5. Fetch helpfiles on demand with help.topic — no need to prefetch; entries resolve in one round trip. Fetch journal-entry detail on demand with char.journal.entry, per vnum, when a quest pane opens.

6. Accepted no-ops

core.hello, core.supports.set / .add / .remove, core.keepalive, core.ping, and external.discord.hello are accepted without error but currently do nothing. You may send them (many client GMCP stacks do automatically); today they don’t change what the server broadcasts. A future subscription model may start honoring core.supports.*.

7. Errors

Any malformed request, unknown package, or invalid JSON payload gets:

logging.error { "error": …, "package": "...", "message": "..." }

Common causes: a package name without a dot, a request body that isn’t valid JSON, oversized requests (§2), or a package name typo.