Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the notion of interlocutor to Blabber #7

Merged
merged 13 commits into from
Oct 31, 2023
Merged

Add the notion of interlocutor to Blabber #7

merged 13 commits into from
Oct 31, 2023

Conversation

Pyrofab
Copy link
Member

@Pyrofab Pyrofab commented Oct 30, 2023

Realized quite a few use cases for dialogues involved someone to talk to, so here goes.

At first the feature scope was :

  • dialogues get started with an optional interlocutor entity
    • the interlocutor is available both serverside and clientside through the screen handler
    • it is also available in commands through a new @interlocutor entity selector (only applicable to players)
    • it is also available in predicates through a new blabber:interlocutor_properties loot condition
  • texts in dialogues support serverside parsing operations, required for scoreboard and selector components

The latter change however means the dialogues have to be parsed and sent whenever a player starts one. Therefore, the registry's contents would only be used clientside to provide the suggestions in commands. It seemed to me that this may be somewhat overkill, so I killed the synced registry part, and synced just the identifiers using the new configuration phase.

Having removed one reason to use Minecraft's dynamic registries, I started looking at the other ones :

  • they store our entries (duh)
  • they load said entries automatically
  • they integrate well with existing APIs (notably registry events)
  • they offer natural client/server separation

However, they present some rather large downsides :

  • they are not reloadable
  • they give terrible error messages (codec issue)
  • they have a stupid quirk that prevents using records for the entries

Considering the cost of an in-house data loader is rather minimal, I figured this way may be best. The lack of registry events may be an issue for future add-on development, but I figured we could add our own callbacks when the need arises.

Future considerations :

  • the screen handler could be made officially part of the API
  • the interlocutor could be added as a parameter to DialogueAction (possible breaking change, though it could go to a separate interface)
  • the texts could be refreshed periodically while a dialogue is opened

@Pyrofab Pyrofab merged commit 1456f87 into main Oct 31, 2023
4 checks passed
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.

None yet

1 participant