Who calls what? The DPB execution model

The selected bot owns the execution loop#

DPB drives the selected bot. The bot decides whether to call plugin, routine and mover managers, or selected components directly. A plugin is not guaranteed periodic work merely because it is enabled.

AcademyBot deliberately drives only the named Academy components. This avoids activating unrelated installed extensions during the exercise. A name check is a teaching boundary, not a security boundary.

A general-purpose bot can call PluginManager.Start/Tick/Stop, RoutineManager.Start/Tick/Stop and PlayerMoverManager.Start/Tick/Stop. That also means taking responsibility for the enabled or selected components it drives.

DPB
└─ selected IBot.Start / Tick / Stop
   ├─ plugins the bot chooses to drive
   ├─ selected routine and mover, if the bot calls them
   └─ bot coroutine
      ├─ task priorities
      ├─ explicit Logic requests
      └─ yield back to DPB

The callbacks have different jobs#

• Initialize / Deinitialize: prepare and release extension-level resources. Do not assume a character or area exists here.
• Enable / Disable: an IPlugin becomes available or unavailable. Register and unregister plugin subscriptions here.
• Start / Stop: the running bot session begins or ends. Reset per-run state; dispose your coroutine and pending work on Stop.
• Tick: short, repeatable work. Check readiness, update a small amount of state and return quickly.
• Logic: a caller asks for a particular behavior by ID and awaits its result. Selecting a routine does not automatically call its combat logic.
• Message: synchronous communication by ID. It is not the right place for a long asynchronous game action.

Return values are part of the contract#

• MessageResult.Unprocessed: this component did not recognize or handle the message.
• LogicResult.Unprovided: this component did not provide the requested behavior. Do not return Provided for unknown IDs.
• ITask.Run() == true: this task handled the current iteration. With UntilHandled, later tasks wait until another iteration.
• IPlayerMover.MoveTowards() == true in the Academy example: the movement request was accepted. It does not mean arrival.
• LokiPoe.InGameState.UseResult.None: no reported error submitting that skill request. It is not a damage, hit or kill event.

A coroutine cooperates with DPB#

An async method returns a Task. A DPB Coroutine is the host that resumes that work from bot ticks. The examples create one on Start, resume it from Tick and dispose it on Stop.

Yield returns control to DPB; Sleep waits cooperatively for a bounded duration. Neither means a new thread is reading game objects. After an await, check current state again.

Do not use Thread.Sleep, a busy while loop, .Wait(), .Result or async void in the bot loop. Do not move game reads into Task.Run to make them seem asynchronous. That loses the normal execution context and can leave work running after Stop.

No player is a normal state#

Character selection, loading, disconnection and death are normal transitions. Before reading player state, check IsInGame and Me. Before actions also check that the player is alive, that the relevant UI/data is ready and that the caller owns an input session.

Game objects are views of changing state. Keep simple values such as a destination or an identifier when useful, then reacquire current objects after a wait. Do not keep a Monster or Item wrapper forever and assume it still represents the same live object.