Open axvemi opened 1 year ago
Related:
You can use a console add-on in your project such as https://github.com/quentincaffeino/godot-console, then define your own commands and variables. This has some upsides compared to an editor-only implementation:
I've been thinking whether it would be a good idea to create a built-in console similar to the above add-on, but I'm divided about it. On one hand, I know that consoles are very handy during prototyping and even as a player (I play a lot of id Tech/Source-based games). All iterations of Unreal Engine also ship with a built-in console, which you can choose to expose to players in the exported project as well.
On the other hand, the console code would be dead weight on platforms where you usually don't have keyboard input available, such as mobile platforms and consoles (no pun intended). This could be a module you can disable at build-time if you wish to reduce binary size, but maybe it should be disabled by default in the mobile export templates.
A difference with that one would also be able to run methods on the editor. It may be useful if you have one that setups something in your scene or something, but yeah the main idea is a console that runs commands in play mode.
Also an annotation would probably be more intuitive for the user that using that way to add the commands, but maybe that could be something that can be changed on the asset.
And yeah, it could be useful to be able to export the console to the built game, in case you want to test it outside the engine. About the keyboard, mobile should be able to write, and console I don't know wether you are able to use it's keyboard.
(Btw, I don't know if that repo is updated, the last release is from 2022-11)
About the keyboard, mobile should be able to write, and console I don't know wether you are able to use it's keyboard.
Virtual keyboard makes it possible to use a console on mobile[^1], and console games can be programmed to have native support for hardware keyboards and mice (this can also be done on mobile). The thing is, it's not exactly the most convenient interface to interact with as most developers may not have a hardware keyboard connected to their mobile device or console.
We should evaluate either way whether implementing a built-in console has a big impact on binary size. It may only be a few KB if we keep the feature set small and avoid including new icons.
[^1]: Been there, done that :stuck_out_tongue: – it's not very convenient to do on a phone, but it is technically possible indeed.
I've started working on a console add-on in GDScript: https://github.com/Calinou/godot-console-prototype
https://github.com/godotengine/godot-proposals/assets/180032/b5079d3b-40d1-44b3-900a-027c4fd1ffe4
It's fully functional; you can add your own commands/variables from any script with the help of Callable. Variables are stored to user://variables.ini
and loaded using the ConfigFile class. This means you can use the Console autoload to store configuration options that can be adjusted via the console. (This kind of duplicates functionality available in ProjectSettings, but ProjectSettings doesn't make it possible to save only a subset of its options to a file, so I can't use it here.)
Some UX refinements still need to be added (such as tab completion). More built-in commands and variables could also be provided.
Like the debug menu, I intend to port it to C++ if there's enough interest in having this as a built-in feature.
Shameless plug here, I've been contributing to this console plugin: jitspoe/godot-console
Its pretty competent and a all in one file, I took some inspiration from your console prototype
Describe the project you are working on
Non relevant. Could apply to all kind of projects.
Describe the problem or limitation you are having in your project
The absence of a console command functionality makes it harder and slower to debug and tests some functionalities.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Have an annotation that marks a method as a command, and, in the editor, an area that allows to run them.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
You would mark the method that you want as a command with the an annotation. IE: @command in GDScript or [Command] in C#. It could also have a parameter for the name of the command, but by default it could be the method's name.
You would also have a new tab at the bottom, where you already have
It could be called console, or commands, or something like that.
It would have a text input field. Writing there the command's name would run it on the editor, if it's an editor script, or ingame if you are in play mode. (It can throw an error or something if you are not in play mode). It could also autocomplete the commands name or show a list of every command.
If it's a method with parameters. IE:
You could call it like this:
potato 3
Doing so, would just run it if it's an editor script, and, if it's ingame could either run it on every instance of that script in the scene, or just in one of them.
If this enhancement will not be used often, can it be worked around with a few lines of script?
You can create your own ingame console, but I don't know if you could replicate the editor commands part.
Is there a reason why this should be core and not an add-on in the asset library?
I don't know if it can be an add-on or asset.