Reviewed October 6, 2026. This page covers the root, registered subcommands and documented internal actions.
Registration permissions
| Registration | Handler | Required status (local DB, Oct 6) | Implementation |
|---|---|---|---|
/q_accept_pending_quest |
76 | 0 | Implemented |
Accept a pending quest offer.
Implementation: Implemented.
Syntax
/q_accept_pending_quest <quest_id>
Arguments
Position is zero-based in sep, after a registered database subcommand has been removed. Internal action tokens remain at position 0. Angle brackets are required; square brackets are optional. Alternative forms may change field meanings.
| Position | Argument | Accepted value / type | Meaning |
|---|---|---|---|
| 0 | quest_id |
integer | Pending quest identifier. |
Behavior and restrictions
The active handler performs the operation described above after the registration permission check.
Current argument/client/target checks (exact source excerpts; branch-dependent):
if(sep && sep->arg[0] && sep->IsNumber(0))
Permissions
Local database snapshot, October 6, 2026: /q_accept_pending_quest requires status 0 (handler 76). Other worlds may configure different values.
The dispatcher checks the resolved registration status before invoking the handler. In-handler guild, group, ownership, client-version and target checks still apply.
Examples
The syntax forms above are the source-based invocation examples. Replace identifiers with values valid for your world; client callback fields are supplied by the game client.
Source evidence
Dispatch: COMMAND_ACCEPT_QUEST (handler 76).
WorldServer/Commands/Commands.cpp:3652—COMMAND_ACCEPT_QUEST.
Reviewed local revision: 9efddf962ffee075d0db2059d3914c36b0acbdf3; working-tree file checksums identify the exact reviewed bytes. Reviewed dispatch/helper evidence · Reconciliation report.
No upstream Markdown file exists for this registration in the retrieved revision.