Skip to content

Add Darkrime Delves dungeon bot - #63

Open
Wellwisher533 wants to merge 1 commit into
apoguita:mainfrom
Wellwisher533:codex/add-darkrime-delves
Open

Wellwisher533 wants to merge 1 commit into
apoguita:mainfrom
Wellwisher533:codex/add-darkrime-delves

Conversation

@Wellwisher533

Copy link
Copy Markdown
Contributor

Summary

  • add the complete Darkrime Delves route from Longeye's Ledge through all three dungeon levels
  • add restartable named phases, alternate bridge routing, snowball/trap safety, hero flagging, key handling, lock passage verification, blessings, quest acceptance, and final chest handling
  • add an opt-in reliable interaction controller used by the dungeon's NPC, Beacon, lever, lock, keg, and chest interactions
  • include normalized route data and capture metadata

Validation

  • repeatedly live-tested end to end in Guild Wars while refining route and interaction recovery
  • Python syntax compilation passed for the widget, route data module, and reliable interaction controller
  • JSON metadata validation passed
  • reliable interaction dataclass/import smoke check passed
  • git diff whitespace check passed

@apoguita

apoguita commented Aug 9, 2026

Copy link
Copy Markdown
Owner

Verdict for the original request: request changes — Darkrime Delves is a coherent dungeon-bot feature, but this PR does not fix the existing interaction path. It adds a second interaction system and makes Darkrime use that instead.

[BLOCKER] Py4GWCoreLib/routines_src/reliable_interaction.py is a replacement interaction system beside the existing one.

Its header explicitly says existing interaction wrappers do not import or call it. It then implements its own target search, movement, interaction, dialog handling, retries, post-interaction checks, and action-queue control.

Py4GWCoreLib/routines_src/behaviourtrees_src/botting_interaction.py already owns reusable bot interaction states: moving to NPCs and gadgets, interacting, and sending dialogs through the Botting APIs.

Darkrime Delves.py reloads reliable_interaction.py and uses its private controller instead of extending the existing interaction owner.

As a result, the original interaction path remains unchanged. Darkrime receives a separate version of interaction behavior, and later bots can use either path and behave differently.

[BLOCKER] Widgets/Data/dungeons/darkrime_delves.json is a second representation of Darkrime data.

Darkrime Delves.py imports Widgets.Data.dungeons.darkrime_delves_data.py. It does not load darkrime_delves.json.

The JSON contains route metadata, interaction policies, markers, and capture references that belong to the same Darkrime feature data already represented in Python.

As a result, the PR adds two sources for Darkrime data: the Python catalog the bot uses and a JSON file the bot does not use. They will drift.

Required direction:

  1. Remove Py4GWCoreLib/routines_src/reliable_interaction.py and remove its reload/import/controller wiring from Darkrime Delves.py.
    Why: this is a second interaction implementation that deliberately bypasses the existing shared interaction path.

  2. Add the required reliable-interaction behavior to Py4GWCoreLib/routines_src/behaviourtrees_src/botting_interaction.py and its existing Botting helpers.
    Why: target validation, approach handling, dialog handling, retries, and post-interaction confirmation must improve the shared owner so every bot gets the same corrected behavior.

  3. Change Darkrime Delves to use those corrected shared interaction helpers directly.
    Why: Darkrime must consume the supported interaction path, not maintain a private controller and runtime adapter.

  4. Remove Widgets/Data/dungeons/darkrime_delves.json. Put the required route metadata, interaction policies, markers, and capture references into typed dictionaries or catalogs in Widgets/Data/dungeons/darkrime_delves_data.py.
    Why: Darkrime already consumes Python data from that module. A parallel JSON file is an unused second representation of the same feature data.

  5. Provide focused Pyright and injected-client evidence for the corrected shared interaction path: target selection, approach, interaction, dialog choice, retry, post-interaction confirmation, and Darkrime’s resulting dungeon progression.
    Why: static code cannot prove that the original interaction failure is fixed in the running client.

The current implementation is a private interaction rewrite and duplicate Darkrime data, not a fix to the existing shared interaction path.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants