Something does not work: find the failing boundary

It does not compile#

• dotnet is not recognized: install a Windows .NET SDK and open a new terminal. A runtime-only installation does not include the compiler.
• Reference assemblies for .NETFramework,Version=v4.8 were not found: DPB1 needs the 4.8 Developer Pack / targeting pack.
• Client reference not found: verify DpbDirectory and the product. DPB1 references its managed .exe; DPB2 references DreamPoeBot.dll, not the launcher .exe.
• A namespace or type is missing: keep Directory.Build.props beside the project folders and use the complete matching client installation. Do not mix DPB1 and DPB2 dependencies.
• An API member is missing: confirm the product and client version, then open that API's product-specific reference. Do not guess a replacement from another library with a similar name.
• A DLL cannot be overwritten: close the test DPB instance before replacing its loaded extension. Keep source/build output separate from the running installation.

It builds but does not appear in DPB#

1. Check the final client path, not just artifacts in your source folder: Plugins/AcademyObserver/AcademyObserver.dll.
2. Ensure there is exactly one expected folder level and that the entry DLL matches its folder name.
3. Use a public, non-abstract entry class implementing the correct interface, with a parameterless construction path. Do not perform game reads in its constructor.
4. Restart the client after replacement. Do not assume hot reload.
5. Inspect DPB's loader log for missing dependencies, wrong framework or duplicate types. Do not solve a host dependency mismatch by copying random DLLs from another product.

It appears, but nothing runs#

• A plugin is installed but not enabled. Enable is a separate step from discovery.
• A bot is selected but not started, or the normal client connection prerequisites are not satisfied.
• The selected bot does not tick your plugin. For the first lesson use AcademyBot and the original Academy names.
• Your plugin implements IPlugin but not ITickEvents. A method named Tick without the expected interface does not establish that contract.
• The timer is not due, the player is not loaded, there is no target, or the area identity has not changed. These are valid idle paths.
• The selected routine expects a Logic ID that the bot never sends. Tick is not an automatic combat request.

The method returns, but nothing happens in game#

• Separate the boundaries: caller ran → eligibility passed → request accepted → state changed → goal completed. Log which boundary actually succeeded.
• A found path is not movement. A successful MoveTowards result in the sample means request accepted, not arrival.
• A skill result of None is not a hit or kill confirmation. Check the chosen slot, current target, range, resources, cooldown and applicable UI state.
• The action workshop needs explicit permission, a new button request, valid selected Academy components and its own available input session.
• No displacement after the bounded observation window means no observed progress, not permission to loop forever. Stop and inspect the actual state.
• An object found before a wait can become stale. Recheck game state and reacquire the object after loading or transitions.

It freezes, spams logs or repeats old work#

• Search your loop for Thread.Sleep, .Wait(), .Result, an unbounded while or Task.Run game reads. Use the bot coroutine and cooperative waits.
• Store timers once rather than constructing them each tick. Check the timer before expensive queries.
• With UntilHandled, a task that always returns true can starve every lower-priority task.
• If logs duplicate after re-enable, check that the same event handler is unsubscribed and that repeated Enable is guarded.
• If a button action replays after restart, clear pending intent on Stop and Start.
• If state is accessed after Stop, identify the background task, event subscription or coroutine that outlived its owner.

Optional: debug your own DLL with matching symbols#

Start with the log checkpoints above. If your DPB build supports managed debugging, Visual Studio can inspect your extension while it runs in its host. This is an optional workflow, not a prerequisite for the Academy.

Build Debug and keep your DLL, PDB and source from the same build. Install your DLL and PDB together with the test client closed. In Visual Studio, use Debug → Attach to Process and identify your own DPB host process, not the game process. Choose the managed code type matching the product.

Place a breakpoint in your own Tick method before the readiness guards, enable the plugin and start its teaching bot. A hollow breakpoint usually calls for checking the loaded DLL and matching symbols before changing the code.

Where this goes: Extracted kit root. Keep the resulting AcademyObserver.dll and AcademyObserver.pdb from this same build.

.\Build.ps1 -DpbDirectory 'C:\DPB' -Project AcademyObserver -Configuration Debug

Make a report another developer can reproduce#

1. State DPB1 or DPB2, the client version and the kit/project being used.
2. State the exact build command or the manual steps before the failure.
3. Include the first error and a short relevant log window. Do not send an entire private configuration folder.
4. Say what you expected and what you actually observed, including whether any input was sent.
5. Remove account names, character names, license values, tokens, personal paths and third-party private code.
6. If the problem follows a client update, rebuild against that installation and record which API boundary changed.