Icesus Mudlet GMCP: Vitals, Rooms, Party, Casting, and Momentums

GMCP is the cleanest way to build an Icesus Mudlet UI. Instead of scraping prompt text for HP, exits, party members, casting progress, cooldowns, or momentums, Mudlet can listen to structured events from the game. The Icesus browser client is the reference experience here: it already uses GMCP heavily for vitals, room exits, party grids, screen reader behavior, hotkeys, basic triggers, and manual momentum buttons.

Verify in your own profile: GMCP is a live protocol. Use Mudlet's Debug window, Statistics view, or lua display(gmcp) after connecting. Build from the fields your client actually receives.

What GMCP Gives You

GMCP, the Generic Mud Communication Protocol, sends JSON-like data outside the normal text stream. That matters because text changes. Prompts can wrap, colors can change, and room descriptions can contain words that look like status messages. GMCP is state: current HP, room exits, party member flags, active casting, cooldown timers, and so on.

Use GMCP for state and text triggers for prose. For example, use Room.Info for room name and exits, but keep text triggers for an NPC saying something suspicious.

Known Icesus GMCP Surface

The current browser client advertises support for Char, Char.Vitals, Char.Maxstats, Char.Base, Char.Status, Char.Casting, Room, Room.Info, Party, Party.Info, Client, Client.Hotkeys, and Client.Triggers. Its GMCP handler also handles additional events such as experience gain, cooldowns, screen reader mode, world time, and server status. Mudlet profiles should still verify what they receive, because client support lists and server behavior can evolve.

GMCP package Observed Icesus use
Char.VitalsCurrent HP, SP, EP, and PSP. In payloads used by the web client, SP appears as mana and EP as moves.
Char.MaxstatsMaximum HP/SP/EP/PSP values such as maxhp, maxmana, maxmoves, and maxpsp.
Char.BaseCharacter identity and title data, used after login.
Char.StatusLevel, position, state, food/water/drunk status, money, bank, divine favor, carry weight/volume, effects, enemies, EXP, busy state, activity, PSP visibility, momentum, and special momentum.
Char.CastingActive casting state, spell name, progress percentage, and casting speed.
Char.ExpGainExperience gain or loss event amount.
Char.CooldownsCooldown list with names and remaining time.
Room.InfoRoom name, area, safe/inn flags, and exits. This is the clean source for exit buttons and mapper experiments.
Party.InfoParty name and members, including grid position, role, flags, HP/SP/EP percentages, location presence, self, and leader state.
World.TimeGame time, season, phase, month/day, and hour name.
Server.StatusServer status such as players online and uptime.
Client.ScreenreaderWhether Icesus screen reader mode is active for the client.
Client.Hotkeys, Client.TriggersBrowser-client hotkey and basic trigger data. Mudlet users normally build their own UI instead of relying on these.

Enable and Inspect GMCP in Mudlet

  1. Open the Icesus profile in Mudlet.
  2. Check that GMCP is enabled in profile preferences.
  3. Connect to icesus.org on port 4000, or TLS port 4443 if configured.
  4. Open Mudlet's Debug window and watch for gmcp. events after login, movement, combat, casting, or party changes.
  5. Run lua display(gmcp) after a few events to inspect the current table.

If a package is missing, do not assume Icesus is broken. Some data appears only after login, movement, combat, party formation, casting, or status change. Some modules may require client support negotiation. Compare with the browser client if you need a sanity check.

Basic Event Handler Pattern

In Mudlet, create a script namespace and register event handlers for the GMCP events you care about. Keep each handler small.

icesus = icesus or {}

function icesus.onVitals()
  local char = gmcp.Char or {}
  local v = char.Vitals or {}
  local m = char.Maxstats or {}

  local hp = v.hp or 0
  local maxhp = m.maxhp or v.maxhp or 1
  local sp = v.mana or 0
  local maxsp = m.maxmana or v.maxmana or 1
  local ep = v.moves or 0
  local maxep = m.maxmoves or v.maxmoves or 1

  cecho(string.format(
    "\n<grey>Vitals: <red>%s/%s HP <cyan>%s/%s SP <green>%s/%s EP<reset>",
    hp, maxhp, sp, maxsp, ep, maxep
  ))
end

if icesus.vitalsHandler then killAnonymousEventHandler(icesus.vitalsHandler) end
icesus.vitalsHandler = registerAnonymousEventHandler("gmcp.Char.Vitals", icesus.onVitals)

This example prints a line so you can see the data. A real profile would update labels, gauges, or mini-windows instead of echoing every tick into the main output.

Vitals and Status

For Icesus, Char.Vitals and Char.Maxstats are the base of a clean HUD. Note the field names: the browser client reads HP as hp, SP as mana, EP as moves, and PSP as psp. Max values use maxhp, maxmana, maxmoves, and maxpsp.

Char.Status is where the richer state lives: level, position, food, water, drunk state, effects, carry weight, carry volume, money, bank, divine favor, EXP, state, busy/activity text, enemies, and momentums. For accessibility and reliability, prefer visible labels over color-only indicators.

Rooms, Exits, and Mapping

Room.Info gives a better foundation than parsing room text. The browser client uses it for room name, area, safe/inn indicators, exit buttons, special exits, and mobile direction controls. In Mudlet, use it for a room header, exit list, and cautious mapper experiments.

Do not overtrust a map. Icesus has special exits, dangerous areas, and rooms where reading the description matters. Use GMCP to reduce parsing mistakes, not to turn exploration into blind speedwalking.

Party Info

Party.Info is one of the most useful Icesus GMCP packages. The browser client renders a 3-by-3 party grid from member column and row values, then shows HP/SP/EP percentages and role flags. Observed roles and flags include leader/follower style roles, LD for linkdead, Rip for dead, and flags such as stunned, sleeping, meditating, and wounded.

A good Mudlet party panel helps players notice problems faster. It should not auto-heal, auto-rescue, or react to another player's speech by sending commands. Use party GMCP to show status, not to replace the player.

Casting and Cooldowns

Char.Casting can drive a casting bar: active/inactive state, spell name, progress, and casting speed. Char.Cooldowns can drive cooldown badges with remaining seconds. This is exactly the kind of state GMCP is good at: structured, compact, and less brittle than trigger text.

Class-specific Mudlet setups should keep caster, healer, melee, and crafting UI separated. A priest may care most about party HP and casting progress; a melee character may care more about HP, enemies, effects, and momentums.

Momentums

Icesus momentums are short-lived combat opportunities. The web client reads momentum and special_momentum from Char.Status and displays manual buttons such as "Use strike" when available. That is the model to copy: show the opportunity, require a deliberate player action.

Do not auto-use momentums. Icesus help triggers explicitly says using triggers to reuse combat momentums is strictly forbidden. A Mudlet GMCP handler may display a momentum. It should not send use <momentum> automatically.
function icesus.onStatus()
  local s = gmcp.Char and gmcp.Char.Status or {}
  if s.momentum and s.momentum ~= "" then
    cecho("\n<yellow>Momentum available: " .. s.momentum .. " (type it yourself)<reset>")
  end
  if s.special_momentum and s.special_momentum ~= "" then
    cecho("\n<orange>Special momentum: " .. s.special_momentum .. " (manual use only)<reset>")
  end
end

if icesus.statusHandler then killAnonymousEventHandler(icesus.statusHandler) end
icesus.statusHandler = registerAnonymousEventHandler("gmcp.Char.Status", icesus.onStatus)

Screen Reader State

Icesus has in-game screen reader mode, enabled with screenreader on. The browser client receives Client.Screenreader and adapts ARIA output and UI visibility. Mudlet screen reader behavior depends on platform and screen reader, but the principle is the same: never make color or sound the only signal, and do not gag the only useful text version of an event. See Icesus accessibility for the broader setup.

Client.Hotkeys and Client.Triggers

The web client supports hotkeys and basic triggers through client GMCP. Its trigger editor uses pattern => command lines, simple substring matching, rate limits, and a 25-trigger cap. Mudlet users usually do not need to send Client.Triggers or Client.Hotkeys; Mudlet has richer local systems. Treat these modules as browser-client support unless you intentionally build compatibility with them.

GMCP vs Text Triggers

Use GMCP for Use text triggers for
Vitals, max stats, EXP deltas, money, divine favor, carry weight, carry volume.NPC speech, room prose, quest clues, unusual item text.
Room name, area, safe/inn state, exits, special exits.Hidden hints and descriptive lines that are not state.
Party grid, HP/SP/EP percentages, flags, leader/self/here status.Human party chat and social coordination.
Casting progress, cooldowns, busy state, effects, combat state, momentums.Combat flavor, critical-hit prose, and spell success wording not exposed as data.

Development Habits

Suggested Build Order

  1. Display raw gmcp data and confirm the packages you receive.
  2. Create a small vitals panel from Char.Vitals and Char.Maxstats.
  3. Add room name and exits from Room.Info.
  4. Add casting and busy indicators.
  5. Add party display if you party regularly.
  6. Add momentum display as manual-only information.
  7. Only then consider mapper integration or reusable Mudlet packages.

Keep the Player in Control

GMCP makes better clients possible, but it does not loosen Icesus automation rules. Vitals, room state, party state, and momentums are there to inform the player. Use them for display, warnings, logs, accessibility, and manual controls. Do not turn them into unattended combat, hunting, fishing, healing, movement, looting, or momentum scripts.

Related Guides

Want to see Icesus GMCP already wired into a client?

Open the browser client