Resource for defining bbcode tags that activate only one time- when their position in RichTextLabel is made visible

[Bropocalypse]

The overall goal of this proposal is to add functionality that will make the creation of character dialog content easier in text-heavy games such as RPGs and visual novels.

In many story-rich games, dialog is often blitted out one character at a time. This is functionality Godot's RichTextLabel provides beautifully. However, such games often have events surrounding dialog besides this. Specifically, events that occur only one time rather than repeatedly in association with the rendering of text. These events, which may even occur mid-sentence, may include changing the rate at which dialog is revealed, starting or ending various animations, affecting items in the player's inventory, unlocking achievements- virtually any kind of game functionality may be evoked.

Godot currently lacks functionality for designers to evoke such events in the same way that they may write dialog.
RichTextEffect is almost a solution to this, however it has no functionality for only activating when first revealed in a RichTextLabel. Rather, once revealed they will fire repeatedly, many times per frame. There is seemingly no good way to bend this behavior towards a one-off function. Writing in a boolean check to prevent repeated calls to _process_custom_fx() will prevent enclosed code from working more than once... ever. Because RichTextEffects are a resource, this means it can only occur once, since the resource's data will be persistent even if a new tag calls it again. Hypothetically, this means that every time a new string is inserted into RichTextLabel, these 'already been used' type booleans need to be reset. At best this means that RichTextEffects hacked this way can only be used once per string.
The dialog plugins I've seen that make use of RichTextLabel often implement a one-off bbcode tag for ease of dialog construction, but they need to write custom parsers specifically for this purpose. Parsers that by necessity must operate in this way:

1. Find sections of text enclosed by []...
2. Disregard such sections already implemented by normal BBCode and also by custom text effects...
3. Interpret their string contents into function calls somehow and remove them from text if they're valid, and if they aren't...
4. Decide whether or not to remove custom tags that don't have valid content.
   And when all that's done, they're still left with the problem of how to preview rich text in the editor that contains custom tags.

And while this is a solution, a much more elegant one that would be easier for users to implement lies just out of arm's reach:
If RichTextEffect had a E.G. _on_visible() callback.
The ideal solution to these problems would be if RichTextEffect had a callback that was activated one time, perhaps when the character immediately proceeding it is revealed via RichTextLabel's visible_ratio, visible_characters, or immediately if the text is loaded in while those values are set such that it would be visible anyway(E.G, visible_ratio 1.0). This would allow for a very convenient way to introduce cutscene functions such as animations and sound, and modification of other game flags, through the same tools used to write dialog.
The only issue would be that RichTextEffect makes repeated _process_custom_fx calls, which would probably be undesirable if RTE is used in this way. So, it would be wise to have a means to prevent it from firing, if not move this one-off functionality to a new type of resource entirely.

[dalexeev]

You can use invisible characters to do things the moment they "appear".

[Eoin-ONeill-Yokai]

I agree with this idea -- It might be nice to add a signal to the RichTextLabel that emits a string when a certain bbcode is encountered so you can do something like...

This is a good [b]clue[notify="ding"][/b] that gets us just a bit closer to knowing the whole truth! 

This could effectively work a lot like the above suggestion, but would do so without having to resort to special characters. Of course, you could also supply no string which would result in an empty string being passed into the notification.

Some points of consideration...

• When do these signals emit? Should they emit the minute they're present in the text? Or only when "visible character" lands on the special entry?
• If visible characters is at a value of -1, do we consider all notifications present immediately on text change or do we need to have the visible characters value set to a non-zero value to consider notifications at all?
• Should notifications be batched in the case that multiple notifications become "visible" all at once?

I think that building it out via a signal would make it speak in a gdscript friendly way to other nodes or elements and it would be relatively simple to add.