jacopofar / blocking-dialog-box Goto Github PK

Once the quality is decent enough, it's useful to release the plugin for the Godot AssetLib and inform on social media about the release

The demo is nice and all, but for an initial evaluation of the plugin is better to provide an animated GIF or a video showing what it does in a more immediate way.

The component should by default use a font with supports for a wide amount of scripts, and ship with it.
In an ideal scenario, RTL scripts and emojis are supported as well, but for RTL scripts there are issues on the engine, and it seems emojis require a font file too big to justify its incorporation, so providing support outside these issues is probably enough for now.

I'd really like to be able to (optionally) provide a TextureRect with the face of who is talking.

It'd be extra good if I could provide any arbitrary Control object to be displayed, that way if I wanted to do something fancy like use a ViewPort to show a real-time view of the character, I could also do that.

Just like BlockingDialogBox shows a dialogue with pure text output, a corresponding component should allow arbitrary text input from the player, and emit a signal when said text is inserted.

Hopefully, the behavior of this component should be similar, in the sense that the input for the game is blocked until the dialog is closed, and the node manages its own positioning and visibility

In my use case I need the index, not the text of the choice. That information is readily available at the time the signal is fired, so it'll save users time if that is needed and it is just included along with the text as a second argument in the signal.

For impatient people :P

Clicking right on him doesn't work, but slightly up and left does work? Some times?

I looked into it a little and don't see anything obviously wrong, so not sure whats going on.

Just as BlockingDialogBox manages the text output, there should be another component to manage a player choice between a given list of elements. This element, like the existing one, should manage itself regarding screen positioning, hiding/showing the HUD elements and blocking the input.

Once all of the breaks are processed, I would expect the next click to dismiss it, but the next click apparently does nothing, then a second click will finally dismiss it.

Is this intended behavior? If so It'd be nice if it was configurable.

Once there are two or more node types, for example because #2 is done, there should be a single wrapper to instantiate and use all the types of nodes with a single interface, to make the usage easier.

Maybe I'm missing the intended way for this to work, but I need a signal to know when the user has dismissed the dialog box so I can do whatever the next thing is.

Is there some way this is intended to work? I just added a dialogue closed signal that is fired when hide is called which seems to work well.