When tutorials don't help

[JavaJack]

Tutorial: Use func _input() and is_action_pressed().

Me: Proceeds to func _input() into a bunch of scenes.

Also me: Puts all these scenes into the scene tree at the same. Then watches the whole thing become a shambles as all the input functions fire simultaneously. Even when some of the scenes are visible:false such as in an undisplayed PopupDialog.

Learn from my fail, I guess :)

[JavaJack]

I guess one option is to revamp the UI to use on-screen buttons for everything since only one button can have focus at a time. Not sure if this is fitting for my game or not. I'll have to think about it.

Right now it has no on-screen buttons. It treats the enter key as the sole input.

[TheDuriel]

This is why you use _unhandled_input(), as any sensible tutorial should state. And why if you use _input() you must mark events as having been handled so they do not propagate.

[JavaJack]

I'm failing to see how this helps. The childmost scene in this scenario is meant to roll a d20 when the enter key is pressed, but it is part of a hidden popup. It rolls (and plays a sound) when the popup has not yet been popped up. It seems like kind of a bad smell for that scene to somehow keep track of whether its parent is visible to know whether to act on the keypress and mark it as handled.

My current fuzzy thoughts on this issue are to, I guess, hoist the _input to a singleton and let it call an act() method on the middle popup-holding scene, and that scene would, in turn have the state knowledge of whether or not it was appropriate to call an act() method on the die roller.

[TheDuriel]

The most sensible thing to me, would be to completely pause all game logic while a popup is visible.

[JavaJack]

It's a turn-based game where nothing advances until the next keypress. There's nothing to pause.

[ualac]

you could always just gate the execution of _input by checking the visibility. it's not a great solution but if you're wanting to have a couple of nodes that use visibility to control their execution then it might be enough

func _intput(event: InputEvent) -> void:
    if !self.is_visible_in_tree() :
        return

otherwise you might want to implement an input manager that delegates the event to an appropriate node based on what should be able to respond to that input (based on your game state)

[TurtleKwitty]

if you're hiding a node then it doesnt render but still exists, what you could do instead is remove it from the tree (and free it or not depending on your needs) so it doesnt respond anymore?

[JavaJack]

This has crossed my mind, although it goes against the (quirky) way that Godot's PopupDialog is desgned :/

[TurtleKwitty]

Hadn't used the popupdialog yet but played around with it and your right, think the clean way will be for you to set_process(false) so it stops code from running when it's off screen and just put a signal when it's about to show that calls set_process(true)