squattingmonk / sm-dialogs Goto Github PK

The standard tokens (e.g., <sir/madam>, <Day/Night>, or <StartCheck>[Persuade]</Start>) could be interpreted before the dialog text is displayed. The token should be added as normal rather than using token functions as in ZZ-Dialog, because:

• it makes it less likely the builder will need to use callbacks to set correct node text
• if we end up making alternate scripts that use NWNX to set dialog text, the game can manage token interpretation and save on this step

The example dialog references a number of action and condition library scripts that do not yet exist. The idea is that the system will come with many common action and condition scripts already in library form and that the builder will not have to make his own.

I have implemented DLG_CONDITION_PC_HAS_GP, but many more need to be added.

We need to add automated Next, Previous, and Back (and possibly Refresh) nodes that appear when the list of possible responses is larger than the number that can be shown. They should have configurable labels.

Currently, the system is set up so that all the information about the dialog is cached at initialization. After this, other scripts are only run if there are conditions or actions on the nodes or pages. I can envision instances where this could be too constricting, especially if you want to add or delete node lists on the fly.

A callback to the dialog script could be sent for several events:

• dialog init
• page init
• node condition
• node action
• end
• abort

Users should have the option of not using this and just using the cached data to run the dialog.

Currently, the cache is deleted and recreated every time the conversation is begun. While this helps with cleanup, conversations that do not have state-specific variables being set on previous runs don't benefit in any way from this. Making it so the cache can persist after the first run can reduce the work that needs to be done on subsequent runs.

I think we can avoid data duplication by not sending the dialog init callback (#1) when the cache is found and avoid cleanup issues by having the user remove state-specific variables with an end or abort callback.

Currently, the End and Abort events simply delete the dialog cache. I want to allow the user to specify actions that happen on these events. This should be able to happen in two ways:

1. By specifying at initialization the actions to perform which,
   a. should be easily settable for the dialog as a whole, and
   b. easily overridden on a per-page basis
2. Through a callback to the dialog script

Are you planning to integrate this system with nwnx_dialog at all?

We should be able to swap NPC speakers. This should be able to be specified on a per-page basis at init and during a callback (#1).

ZZ-Dialog does this by creating a ghost object placeable that changes name and portrait to match the different speakers, but this is ugly and has several downsides. Instead, we can simply restart the conversation with the next NPC and use the dialog's state to pick up where we left off. This may require #5 to work.

This comes with potential issues of its own, though. For example, what if the NPC we want to switch to is not available for conversation (e.g., another PC is talking to them, they're in battle, etc.)?