This introduces a new type of dialog called Interparsable. Interparsable is a type of dialog that allows embedded code tags or snippets in dialog boxes. These can then be interpreted by the dialog box at update time.
The feature is not entirely complete via this PR, but should be easily expandable from here, and this PR already has minimal functionality to provide practical benefit in existing games.
A next step would be to allow code tags that alter the appearance of the dialog text, such as color formatting. Right now, the DialogBoxRenderers/InterparsableRenderer will simply render the printable characters, with the tags removed. (see more under Features to Implement).
Types of tags
Currently, any text in a dialog text page that is surrounded by ( parens ) is considered an "operational" chunk. When an operational chunk is encountered during dialog update() (dialogs are updated to reveal one-character-at-a-time), then that chunk is passed along to a user-provided callback function. It's then up to the user to interpret the text within the parens and implement subsequent behavior.
As-is, this "operational" chunking is hard-coded to ( parens ) as delimiters, but there's no reason a user-provided chunking algorithm could be included at some point as well. For now, the parens are considered "default" behavior, and this default behavior is currently hard-coded in.
Edge case behavior
Because this introduces operational text, some interesting edge cases come into play. Here's the ones that have been identified, and how they are handled:
With multiple pages
Any page that contains only one or many operational chunks (and no printable text), it will perform the operational chunk(s) and automatically advance to the next page.
If the last page contains only operational text, the dialog box will automatically be marked as finished after processing the operational chunks.
If the first page is an operational chunk, the page will automatically advance on first update
If the dialog box contains one or more pages that are all operational text, the dialog box should not be spawned at all, but each operational chunk should be processed, and the resulting callbacks should be fired off. ⚠️ This requirement has not been implemented.
Features to implement
Interparsable dialog node class has members for options (user-selectable list of choices after the dialog box has completed all pages), but it's not supported anywhere else. You would look into MultipageWithOptions dialog, node, and its integration into the system for how the options system works. In theory it should be a direct copy.
There's a partial implementation of text style formatting in InterparsableRenderer that is disabled, in the render function. It needs to parse line breaks to be ready enough for use.
Interparsable Dialog
This introduces a new type of dialog called
Interparsable
.Interparsable
is a type of dialog that allows embedded code tags or snippets in dialog boxes. These can then be interpreted by the dialog box atupdate
time.The feature is not entirely complete via this PR, but should be easily expandable from here, and this PR already has minimal functionality to provide practical benefit in existing games.
A next step would be to allow code tags that alter the appearance of the dialog text, such as color formatting. Right now, the
DialogBoxRenderers/InterparsableRenderer
will simply render the printable characters, with the tags removed. (see more under Features to Implement).Types of tags
Currently, any text in a dialog text page that is surrounded by
(
parens)
is considered an "operational" chunk. When an operational chunk is encountered during dialogupdate()
(dialogs are updated to reveal one-character-at-a-time), then that chunk is passed along to a user-provided callback function. It's then up to the user to interpret the text within the parens and implement subsequent behavior.As-is, this "operational" chunking is hard-coded to
(
parens)
as delimiters, but there's no reason a user-provided chunking algorithm could be included at some point as well. For now, the parens are considered "default" behavior, and this default behavior is currently hard-coded in.Edge case behavior
Because this introduces operational text, some interesting edge cases come into play. Here's the ones that have been identified, and how they are handled:
With multiple pages
Features to implement
Interparsable
dialog node class has members for options (user-selectable list of choices after the dialog box has completed all pages), but it's not supported anywhere else. You would look intoMultipageWithOptions
dialog, node, and its integration into the system for how the options system works. In theory it should be a direct copy.InterparsableRenderer
that is disabled, in therender
function. It needs to parse line breaks to be ready enough for use.