Skip to main content
Two plugins coordinate whole accounts: moving wealth between clients and completing Tutorial Island.

​
Mule Orchestrator

MulePlugin orchestrates forward muling between a Master and one or more Slave clients. All nodes use outbound RuneLite Party connections, and every mule message uses a versioned envelope with master-only RSA signatures, a distinct HMAC key for slave-origin status, relay-member targeting, payload bounds, and bounded replay protection. The plugin pins the configured master’s member ID only after RSA verification, caches slave identity before departing members leave the party, and moves Party callbacks onto the client thread before touching workflow or game state. The transport reuses an already-joined matching party, refuses to replace an unrelated current party, and leaves on shutdown only when Mule joined the party itself.

​
Security keys

Use three distinct cluster values:
  1. A RuneLite Party passphrase shared by all clients.
  2. A message authentication key (16+ characters) shared by master and slaves for slave-origin status.
  3. An RSA key pair used only for master-origin commands. Configure the PKCS#8 private key on the Master only, and the matching X.509 public key on every Slave (Base64 DER or PEM both work).
Never distribute the master private key to slave hosts.

​
How a run works

The Master coordinates trades through its queue and state machines. Slaves walk to the configured meeting point, hop worlds as needed, prepare inventory at a supported bank (BankAccess.openNearest(): a usable scene bank first, then the lowest-cost route-feasible known bank), and trade with the master. Slaves enter the ready queue only after a command-correlated party join, so the 45-second active-trade timeout starts after arrival rather than while a slave is still banking or walking.

​
Tutorial Island

TutorialIslandPlugin (n3tutorialisland, disabled by default) completes Tutorial Island end to end. The controller routes from the tutorial varplayer (281) through immutable transition descriptors and reconstructs partial progress from live state on restart.

​
How it operates

Each tick preserves one meaningful action in a fixed priority: validate login, initialize the per-account seed/profile, read varp 281 (resetting stage-local state on change), observe an existing pending action before any new interaction, apply manual-step gates, drain continue and option dialogues, apply the idle gate to transition stages, and dispatch the current stage. Automatic pacing uses a per-account 0-2 tick action gap on top of the shared pacer.
  • Transitions are explicit descriptors: semantic name, object ID and action, expected tile, approach and destination areas, and valid varp range. Selection prefers the expected ID at the expected tile, then the nearest approach-area match, then a documented alternate or morph; it never falls back to an arbitrary nearby object.
  • Postconditions before progress: an accepted action creates a bounded pending observation, and obstacle success reconstructs from live state (varp leaving the descriptor range, destination reached, object disappeared, expected widget or NPC appearing), never from an optimistic boolean.
  • Setup screens recover: name entry, appearance, and familiarity screens route through their functional children, with name lookup wait and rejection handling.
  • Client setup at varp 7: an optional pipeline hides roofs and enables shift-drop through the settings search flow.
  • Bank and poll modals: semantic matching of the bank-space offer modal precedes exact bank-booth and poll-booth interactions.
  • Gather stages respect seeded over-collection targets (chopMultiple/fishMultiple/mineMultiple with inclusive bounds).
  • COMPLETE maps to varp 1000+; an unknown varp halts only after 60 unchanged ticks.

​
Configuration highlights

The plugin checks the break handler in automatic mode and releases automation ownership when complete, halted, manually paused, logged out, or on a planned or active break.