Turn output tab into an interactive console

[passivestar]

I've been trying to find the easiest way to make editor tools without UI, and while it's convenient to make Command Palette commands, a big drawback of them is that you can't pass any arguments to them. So if a command needs to prompt for some text, I'd have to create a popup dialogue for that

GDScript expressions caught my attention. From what I understand they can do a lot of different things, in particular call methods, and they should be enough for a simple interactive REPL console

Not only a console like that would allow you to quickly explore the API by poking at things via expressions, it would also solve my problem of having to make GUIs for tools, because I'll be able to just call methods on my utility scripts instead

A console like that can be an addon, but I was wondering what you guys think if this console was just in engine combined with the Output tab? Here's a sketch that I made:

It could expose some convenience variables, for example EditorInterface.get_edited_scene_root().find_node() could be aliased to just find_node() with simple text substitution, etc

What do you think?

[lentsius-bark]

I would very much enjoy having this in the engine, to be able to run commands quickly without having to wrap things in editor tool scripts that only do something simple and end up being buttons (being a fair amount of boilerplate for just a button).

[AThousandShips]

See also:

• Add an expression evaluator (REPL support with inspector sequent results) #4473

[Calinou]

And also #7091 🙂

I think this embedded console in the Output panel is a good idea, but it requires alt-tabbing to the editor if the project is running. This means it would probably be most relevant for editor usage, e.g. when working on editor plugins.

[passivestar]

True. Perhaps godot could inject a console on ~ into development builds, and then 2 consoles would share the same code (autocomplete logic, history, convenience shortcuts, both using Expressions) so that you could have the same experience in editor and in game?

[passivestar]

also if Juan's proposal on embedding the game view into the editor gets implemented then you won't need to alt tab
#7213

[API-Beast]

I like this because embedding it into the Output panel is a good design.

[passivestar]

Perhaps this console could evaluate expressions in-game when the game is running, and in-editor when it's not. Single UI for both

[AThousandShips]

I'd argue that while some of the expression calling methods would be useful in-game the interface would be too limited to be useful for games in general and you'd be better off using any of those plugins which can be more dynamic design wise, the engine one should be as specific and simple as possible while doing what it needs to do

[passivestar]

limited in what way?

[AThousandShips]

A very specific visual feel, limited ability to adapt it to any style in a game, because there's little reason or need to make a feature in the editor so widely customizable, it would add a lot of overhead for using it outside of its normal purpose

Making anything general purpose is expensive and increases points of failure

[passivestar]

oh, you're thinking about a console that you'd ship with a game. I'm thinking of a console for development only. Just so that you don't need to alt tab

[AThousandShips]

Ah that makes sense, "in-game" to me would mean in a deployed project and not for development 🙂

[passivestar]

To iterate a little on the idea of using GDScript expressions instead of a custom parser for the console:

I deal with scripting languages a lot, and I think a big advantage that they offer is how easy they make it to explore APIs and quickly try things out by giving you a way to evaluate lines of code

When I make blender addons I use the python console a lot

It works nice in combination with API docs, because you don't have to imagine what a property or method would do, you can immediately try it out yourself and see the real output without any boilerplate files

And of course in browsers it's incredibly convenient to open the console and just start playing with javascript:

I think being able to execute expressions in Godot in a similar fashion will make it more convenient to learn the engine and make tools for it. And I think it's convenient to have that in-game too (for dev builds) to quickly try things out that you didn't think of explicitly defining commands for beforehand

The added syntactic complexity of expressions over a more simple classic console syntax found in id / valve games or unreal engine can be dealt with by introducing some basic syntactic sugar. For example a command starting with >:

> MyNode my_method "arg1" 10

could be automatically substituted for something like

get_tree().root.find_child("MyNode").my_method("arg1", 10)

This way:

• You're not giving up the flexibility of expressions
• You're not making yourself explicitly define commands for everything you want to test
• You still have short syntax for easy access to your methods

[AThousandShips]

Using just expressions would be highly limiting and wouldn't allow most functionality like accessing nodes or the tree, so you'd still need to have custom parsing to do what your example says

[passivestar]

That's unfortunate, I didn't know find_child() won't work in an expression

I guess the important part is to reduce friction in calling methods and poking at properties by allowing users to do that without boilerplate code. Maybe a custom parser will even simplify some things, like autocomplete, if all the parser is going to do is basic path resolution like NodePath.method_name arg1 arg2 🤔

[Calinou]

It's possible to procedurally create a GDScript resource, fill its source code with _ready()/_init() functions and run it. See https://github.com/gdscript-online/gdscript-online.github.io for a project that does exactly that.

[passivestar]

I was wrong actually, I just tried using find_child() in an expression and it works:

func run(plugin : EditorPlugin):
	var expression = Expression.new()
	expression.parse("interface.get_edited_scene_root().find_child(\"PlayerController\")", ["interface"])
	var result = expression.execute([EditorInterface])
	print(result)

Also tried @Calinou's solution, worked in editor as well:

func run(plugin : EditorPlugin):
	var code="EditorInterface.get_edited_scene_root().find_child(\"PlayerController\")"
	var script := GDScript.new()

	var template = """
@tool
extends EditorPlugin

func _enter_tree():
	print(_CODE_)
"""

	script.source_code = template.replace("_CODE_", code)
	var error := script.reload()

	if error != OK:
		print("Error parsing script.")
		return
	else:
		var run_context: Object = script.new()
		EditorInterface.get_edited_scene_root().add_child(run_context)
		run_context.queue_free()

With an expression you just need to pass all of the globals that you need as input variables

Not sure which approach is better, maybe there are some limitations in expressions that could be problematic in a console, but both approaches work in this simple test

[azur-wolf]

just only add that both having a console that runs stuff in the editor to try fast things, plus have the option to export such console functionality with exported projects would be great

[AThousandShips]

See above on the export part, this thread

[passivestar]

yeah you probably don't want to ship a game with a console that lets you execute any code with access to the OS, it can do a lot of damage. in a shipped game you want a simple version that can only call pre-defined commands

[sancho2]

Visual Basic, from many years ago, had this and it was fantastic.
Set a break point and live test commands against your code.
Great idea.