uo-death-recovery

name	uo-death-recovery
description	What to do when the headless UO character dies — detecting ghost state, getting resurrected via a healer, and checking equipment afterward. Use whenever the user asks about death, being a ghost, resurrection, or the character shows HP:0.

Handling character death and resurrection

Requires a logged-in character with the map loaded (see the uo-login skill).

1. Detect death

echo "status" >> /tmp/cuocmd
sleep 1
tail -3 /tmp/cuolog

HP:0/max means the character is a ghost. The log also passively announces it the moment it happens:

[WARN ] [DEATH] You have died!

2. Resurrection is fully automatic — don't send a "confirm" command

There's no manual accept/decline step. The client reacts directly to the resurrection gump packet the instant it arrives (in Handle_GenericGump / Handle_CompressedGump, headless/Packets/IncomingPackets.cs) — it isn't watching its own log output, and there's nothing for you to click. As soon as the real confirm dialog shows up, the client sends button 1 (OKAY) itself:

[INFO ] [GUMP] Resurrection confirm — accepting (button 1 = OKAY)
[INFO ] [GUMP] Sending response: serial=... gumpId=B04C9A31 button=1
[INFO ] [ALIVE] You have been resurrected!

Your only job is getting the ghost adjacent to an actual healer NPC — the gump fires from a tight proximity check, not from any command you send.

Don't be fooled by similarly-shaped gump IDs

Two other gumps show up around the same time and are red herrings if you're trying to identify "the resurrection gump" by eye:

Gump ID	What it actually is	Handling
0xB04C9A31	Real resurrection confirm	Auto-accepted (button 1)
0x11775C2E	"Client is out of date" notice	Auto-dismissed
0xCECA8EAD	Server news / MOTD popup	Auto-dismissed

If the client's reported version doesn't match UO_VERSION in .env correctly, the server sends the out-of-date notice, which can visually look like it's blocking resurrection — it isn't; it's just a decoy dialog getting auto-dismissed.

3. Walk to the area, then hunt down the healer specifically

A fixed coordinate is only a starting area, not a guaranteed resurrection spot — the healer is a wandering NPC, not a static object, so "arrive at (x,y)" is not the same as "be next to the healer." The known-good starting area for this character is (3626, 2616), just outside the healer building near the door at (3627,2615)/(3628,2615), unless the user gives different coordinates:

echo "goto 3626 2616" >> /tmp/cuocmd
sleep 10
tail -20 /tmp/cuolog

GoTo already knows about ghosts:

• It pauses automatically for ~5s if a resurrection gump appears mid-walk (ResurrectionOffered event), giving the auto-accept time to land before continuing.
• It pauses ~3s if the server "freezes" ghost movement (an anti-spam throttle UO applies to ghosts) — this shows as GoTo: frozen, waiting 3s... in the log and is expected, not a bug.

A ghost can walk through doors. Unlike a living character (see uo-navigation's door-hunting steps), a ghost isn't blocked by closed doors — don't bother with opendoor or entrance-hunting here. If goto still reports no path for a ghost, treat it as a genuine unreachable/off-map tile, not a door problem.

Find the healer by name, not by guessing a spot

mobiles doesn't show NPC job titles — a healer shows up as a generic Human (Male)/Human (Female), indistinguishable from any other townsperson at a glance:

echo "mobiles 15" >> /tmp/cuocmd
sleep 1
tail -15 /tmp/cuolog

Identify which one is actually the healer:

• Ambient name-barks are the easy signal. Nearby NPCs periodically say their own name/title unprompted in the log, e.g. Gerda: Gerda the healer. Watch a few seconds of log output for a line containing "healer" — that gives you the name to match.
• Once you have a name, correlate it to a serial with click <serial> on the candidate Human NPCs from the mobiles list — the response echoes the full name (Paperdoll opened for [...]: 'Gerda the healer' if you use use <serial> instead, which also works for identification).

Don't rely on the built-in findhealer/fh command — it walks a fixed, hardcoded sequence of far-off waypoints that can be entirely unrelated to (and unreachable from) your current location. In practice it can fail every single waypoint with no path ... 0 extra blocked and conclude Pattern complete — no healer found even while a real healer is wandering a few tiles from you. Treat it as unreliable and use the mobiles + name-bark approach instead.

Chase the healer down — she keeps moving

Once you have her serial, don't just goto her last-seen position once — she wanders continuously, including while you're walking toward her, so a single goto will often "arrive" at a spot she's already left:

echo "mobiles 15" >> /tmp/cuocmd    # get her current (hx, hy)
sleep 1
echo "goto <hx> <hy>" >> /tmp/cuocmd
sleep 3
echo "mobiles 15" >> /tmp/cuocmd    # she's moved — get the updated (hx, hy)
sleep 1
echo "goto <hx> <hy>" >> /tmp/cuocmd   # repeat
sleep 3

Repeat this re-check/re-goto cycle until you're adjacent to her exact current tile — get as close as possible, don't settle for "same room" or "within mobiles range." The resurrection proximity check is tight; arriving at a tile she already vacated does nothing even if you're only a few tiles off by then.

If the gump doesn't fire once adjacent

Sometimes walking straight into range doesn't trigger the confirm dialog immediately. If status still shows HP:0 a couple of seconds after you're adjacent, walk away a tile and back in — re-entering range re-triggers the check:

echo "walk n" >> /tmp/cuocmd; sleep 1
echo "walk s" >> /tmp/cuocmd; sleep 1
echo "status" >> /tmp/cuocmd; sleep 1
tail -5 /tmp/cuolog

4. After resurrection, check equipment

Resurrection doesn't restore lost gear — confirm what the character is actually wearing before assuming anything (including whether a "death robe" survived). See the uo-equip-items skill for the correct layer table (notably: layer 0x0B is Hair, not a robe — don't mistake it for stuck equipment when investigating what's on the character).

echo "status" >> /tmp/cuocmd; sleep 1   # confirm HP is no longer 0
echo "inv" >> /tmp/cuocmd; sleep 1
tail -15 /tmp/cuolog

Don't conclude gear was lost just because the backpack shows empty. inv's backpack listing only reflects what the server has actually sent, which is nothing until the backpack itself has been double-clicked open at least once this session — see the uo-equip-items skill's step 1. If anything looks missing, open it before reporting a loss:

echo "use <backpack_serial>" >> /tmp/cuocmd; sleep 2   # serial from the inv equipped list, layer 15
echo "inv" >> /tmp/cuocmd; sleep 1