Some player-to-player actions begin with a consent offer. The recipient accepts or declines the displayed prompt, but acceptance proves only that the recipient agreed to let the owning system attempt the action. Always wait for that system’s final success result before treating money, items, or access as changed.

Review an offer before answering

When a prompt appears:

  1. Read who sent it and what action is proposed.
  2. Check that it matches the in-character agreement.
  3. Accept or decline using the keys shown by the prompt, or with the accept and decline commands if you prefer typing.
  4. After accepting, wait for the owning system’s final result.

A recipient can hold only one pending offer at a time. Unanswered offers expire, and either participant disconnecting cancels the temporary prompt. An expired or disconnected offer cannot be resumed.

The game can recheck distance, identity, custody, funds, authority, and other current conditions after acceptance. Moving away or changing relevant state can therefore prevent the final transaction even though consent was recorded.

Distinguish acceptance from completion

Use the feature-specific result:

  • a cash payment completes only when both sides receive the final paid and received result and their balances reflect it;
  • an item handover completes only when custody changes and both inventories reflect the result;
  • shared key access completes only when both players receive the final grant result and the recipient sees the access entry.

Never hand over a second part of a trade merely because the first offer says it was accepted. Confirm each money, item, or access change separately.

Property purchase and sale use their own ownership workflow rather than an ordinary player-to-player offer. Buying has no separate confirmation prompt; selling uses its own self-confirmation. Follow the final property result and door state described in Properties, ownership, and renting.

Recover from expiry or refusal

An offer declined or expired before acceptance does not invoke the proposed action. A disconnect that cancels a still-pending prompt, or an explicit pre-transaction validation refusal, likewise attempts no mutation.

After one of those clear no-mutation results, restore the required proximity and state, then create a fresh offer only if both players still want the action. Do not use an old prompt or remembered list reference. If the recipient already has another pending offer, let them resolve it first.

Recover from an unclear outcome

If lag, a missing result, or disconnect makes completion unclear:

  1. Do not send the same offer again immediately.
  2. For money, both participants should compare /balance; it shows each character’s current server balance after the result is resolved.
  3. For items or keys, both players can inspect their current inventory or access view, but absence there cannot safely prove that an ambiguous save did not commit.
  4. Retry only after an explicit pre-transaction refusal or another clear result showing that no mutation was attempted.
  5. If an item or key result is ambiguous, do not retry. Preserve the action, participants, item or entity, location, approximate time, and exact visible result for support.

Keep combined trades separated into clear steps. A payment and an item transfer are different transactions; one succeeding does not prove the other did.

See Money, banking, and paying players, Inventory, giving, dropping, and picking up items, and Keys and shared access for each system’s documented visible checks and recovery path. The generated command panels own current syntax.