Hey, wouldn’t it be better to use _unhandled_input instead of _input in Dialogue.gd, so events like clicking on a popup (if mapped to ‘continue_dialogue’ action) do not also continue dialogue at the same time?

For information, I put my use case below, but it’s a bit shady as _unhandled_input may not solve the issue at 100%. However I still think it’s a good idea to use, so I still post it as a general suggestion.

In my case, I had more an issue related with input event handling order: Dialogue always handled SPACE first to ‘continue_dialogue’, which ended the last dialogue bubble. Then my character would be free to talk to an NPC again, and my own _unhandled_input method would detect my ‘interact’ action (also mapped to SPACE) and restart the dialogue, so I was stuck in an infinite loop. Using _unhandled_input instead of _input in Dialogue.gd made it handle the event after mine in a given frame, forcing ‘interact’ action to be checked again next frame, where SPACE was already consumed, so I had to press SPACE again to restart the dialogue as expected.

However there is no guarantee of order between different _unhandled_input methods, so I shouldn’t rely on that. But at least, if a developer has an actual _input to implement he’d be able to process that before Dialogue.gd.

In the end I was afraid the input handling order would not be guaranteed in release build, so I just delayed allowing the character to interact with a NPC at the end of a dialogue by 1 frame, just enough not to process SPACE to start the dialogue again.

I guess, otherwise, that the best solution is to take full control of inputs, by not mapping anything to ‘continue_dialogue’, and instead make your own action, process inputs based on context and priority order, and then if we should continue dialogue, call next() manually on the Dialogue instance.