Editor Fields and Advanced Expression Evaluation

[WolfWare-Dev]

Who Am I:

I am a recent Unity to Godot convert and have been using Godot steadily more and more over the last weeks.
I've used Unity for a handful of years now, and have discovered numerous helpful quirks and features of the editor along the way that truly are a time saver in many scenarios.

What I'm Requesting:

One of the first things I noticed I miss sorely in Godot vs Unity is advanced Expression evaluation in the editor for properties of Nodes(GameObjects).

For direct reference to this feature within Unity, refer to: Unity Docs - Editing Value Properties under the header Numeric field expressions

In this example image from the page above, a user is in the process of inputting a Sin/Cos function into the Transform property of a selection of objects. After exiting the field with tab/enter, the editor then evaluates the user's expression and maps the selected objects accordingly.

Within Godot, similar eval functionality exists but it appears to be limited to only the very basic operators and parentheses support.

My proposal is for Godot to implement advanced expression evaluation for Editor fields to allow Godot users, advanced and beginner alike, more options and power for accurately manipulating node properties. This could go beyond simple transform/rotations, perhaps one could even spread Animation keyframes with similar behavior..

Why it's useful to everyone

I fully believe everyone could benefit from this feature, despite how small and 'hidden' it could be after implementation. Many Unity users don't even know this feature exists, and it may be the same for Godot - however, it is indeed a very powerful tool for those who are aware of its potential (IE, editor expression evaluation functionality beyond simple 5*5), and I believe it should be praised more for its utility than it currently is in the Unity Documentation.

This functionality streamlines - by a vast degree - the task of creating precise arrangements of nodes in-editor, in a mathematically sound and precise manner. Circles, ovals, and random or linear arrangements are all instantly within reach without needing to manually move each node or manage it with code.

Some examples:

• Quickly arrange Control Nodes onscreen in a circle for UI designs, or linearly without needing a container first
• An less-code inclined artist can randomly scatter trees or rocks
• Create a Line of ducks!
• Speed up tedious work in a time-restricted Game Jam!

Primarily, this improvement would assist in enhancing developer creativity by alleviating frustrations one may encounter while designing levels and other tools without needing to write 'one use' code or mess with external plugins and tools that are slow or unreliable, or worse, their ability for inclusion is dependent on project restrictions such as target platform.

There are no doubt many packages currently available that offer similar scattering functionality, but still these are external packages that are dependent on Godot Engine version and external maintenance.

This is my first time doing this - If this is poor form or I have left out crucial info, I apologize!

[theraot]

At least the first thing missing is a reference to the object, without it the expression cannot use the object properties. It is worth, the way this is done, giving it a reference will also allow calling methods on it (with the caveat of tool scripts). The other part of this is that evaluation needs to happen per object, so it can have a different result for each of the selected objects. I do not know how much trouble that could be, but it seems worth looking into.

For the controls case in particular, you are probably going to want a container for those controls to handle resizes, or you also have to tweak anchors and margins, which gives me another idea: what about a container that takes an expression and uses it to organize its children? Edit: I should point out I'm just throwing the idea out there.

[Calinou]

The Expression class can be given a context, so it shouldn't be too difficult to give it the currently edited node as a context. This would allow you to refer to its properties using the same syntax you'd use to access properties from a script.

That said, with multiple node editing, this would be much more involved as you'd also need to feed the context an index variable (so you can "line up" multiple selected nodes), etc.

[theraot]

@Calinou Yes, I'm aware Expression can do that.

Still, I haven't looked at that part of the inspector, I do not know how much is done already, or what other things are patched there. For example I read something about supporting both . and , as decimal separator.

In fact, when writing my recent pull request for dropping property access, there are things that I do not dare to change because I do not know what might break, yet I'm convinced a better design is possible.

[strutcode]

Based on a conversation around this particular proposal I've explored this as an editor addon to some degree as a proof of concept with some success.

For this test I arbitrarily chose a few rules and passed them to the Expression as parameters: _ references the index of the current item. _c for count provides the number of selected items and _p for progress provides a 0..1 range over items. This allows a few interesting expressions already:

My overall finding so far though is that this would probably work best as a dedicated parser more similar to Unity's version rather than a GDScript expression evaluation. My reasoning being:

• Expression doesn't respond well to Callables, which makes providing utility shortcuts like the L in the example difficult if not impossible
• Since this runs in the editor, there should be reasonable limits on what the parser can do. If you accidentally paste some code from your clipboard that iterates project files and deletes them it should error with no effect
• Personally motivated and slightly off topic, but it would be a great opportunity to fix the frustrating handling of numeric types such as 1 / 4 = 0

[theraot]

Ok, doing this with Expression would imply some kind of proxy object, which exposes all the properties (probably not the methods) of the selected object, but augments it with other things such as its index, and also any utility methods.

I do not think there is interest in supporting yet another parser... But yes, it would solve other gripes.

[Calinou]

• Personally motivated and slightly off topic, but it would be a great opportunity to fix the frustrating handling of numeric types such as 1 / 4 = 0

See #5344.

[miv391]

Expression doesn't respond well to Callables, which makes providing utility shortcuts like the L in the example difficult if not impossible

How important are the utility shortcuts like L? (Unity seems to have only two shortcuts, L and R) You used lerp in your addon and in my opinion it is even better than L because it's the exactly same lerp function you'll use in your actual code too. No need to learn specific property expression syntax.