[Suggestion] Make the console a node

[GuillaumeCailhe]

Right now, the console is automatically autoloaded and works in every scenes of the project. What if I don't want this behavior ? I might want to use the console only in certain scenes : for example, I might want it in the actual game for quick debugging, but not in the actual menu.

I suggest the console should be working only when you instanciate it in a scene. I know "toggle" can be called to avoid that but I feel this would make more sense in terms of Godot's design principles and would respect separation of concerns. Having a UI Node seems more fitting because you wouldn't have to edit directly the plugin to make changes.

I know that this is possible in Godot : https://docs.godotengine.org/en/stable/tutorials/plugins/editor/making_plugins.html#a-custom-node

Of course, the new control node would need to be easily modified with an exposed interface : exported variables, functions, signals, etc... Ideally, users shouldn't have to look at the code of the plugin if they don't need to. I think this would fit pretty well with #24

[quentincaffeino]

I like the idea of creating custom node and I might look into that later.

Currently you can disable console autoloading in the project settings and then load Console.tscn whenever you want. It adds itself on install phase. So you don't have to worry about it reappearing there later.

[GuillaumeCailhe]

That's good to know, thanks.

While I'm at it, it would be great if the Console node used signals to notify its state. For example, a signal could be emitted when the console is shown. This would be more elegant to use than polling for is_console_shown.

[quentincaffeino]

Sure, I think signals could be implemented right now, even without custom node, isn't it? Since there is a .tscn file...

UPD: It could be taken even further with signals for all console actions, middlewares/transformers. But last couldn't be done with bindings, but since console has very powerful callback system it could be done through those. Or mix it, simple stuff with signals, more complex with event listeners.

[GuillaumeCailhe]

Yes, I think so. Usage would be just : Console.connect("signal", self, "_signal")

As you say, it could be done with a lot of these actions. I think it should stay fairly simple and have signals only for basic stuff. For more complex stuff, maybe the user should have the responsability to use a wrapper function that emit the signal. Let me illustrate with 2 examples.

Example 1 : Toggling the console It's hard to track when the console is getting toggled or not as it can be toggled by the function toggle() or with player input. Having a signal in this situation might help.

Example 2 : Adding commands

Commands are not going to be created by the console itself (except in the beginning). They are created when the player wants a new command. So the player could just create a wrapper that does something like :

add_command():
	Console.add_command()
	emit_signal("command_created")

(this might not be the best example as it's a pretty complicated chain of commands and writing the wrapper might complicate the usage a bit much)

So maybe, make signals only for very common use cases ? I'm not sure what would be the Godot way of doing it.

[quentincaffeino]

@all-contributors please add GuillaumeCailhe for ideas

[allcontributors[bot]]

@quentincaffeino

I've put up a pull request to add @GuillaumeCailhe! :tada:

[quentincaffeino]

Oops, accidentally closed it.

Hey, @GuillaumeCailhe, check out this pr #38, @joshdegraw implemented signals. It will be merged soon.

Edit: Merged, will release new version on asset store after I update the docs.

[quentincaffeino]

Closing as for me it seems as it was fixed. If you have other thoughts, please open another issue.

Best