Add support for additional variable types when using "For each child variable (of a structure)"

[tristanbob]

Description

The new "For each child variable (of a structure)" function works only when using scene structure variable.

This function does not seem to use other types of variables, including:

• Object variables
• Multi-level variables (grandparent.parent.child)
• Global variables

This request is to add support for these types of structure variables.

To Reproduce

Steps to reproduce the behavior:

1. Create a structure variable from the list above
2. Create a "For each child variable (of a structure)" event
3. Create a sub-event that changes the background color (this simply confirms that the ForEach() loop was entered)
4. Preview the game and see if the background changes

Other details

• Tested on GDevelop beta 105

Example game

ShadowClone8.zip

Screenshot

[4ian]

That's indeed an unfortunate limitation. Duplicating the event for each variable kind if unfortunately not a viable option (nor a good user experience anyway!).

Instead, I think this is part of a larger refactoring/reworking of how variables work to introduce a new variable parameter type, that would allow any variable to be entered using an expression: an object variable, a scene variable, or a global variable. Or later an extension variable, or a local temporary variable.

With this support for "expressions" that return variables, we would easily be able to use any kind of variables with the for each event, and also the action/condition that use variables, like the ones to transform a variable from/to JSON. See this card that I made on the roadmap: https://trello.com/c/FwShg063/487-add-support-for-a-generic-variable-parameter-that-would-allow-to-choose-any-variable-object-variable-scene-global-extension-vari

cc @Bouh, @arthuro555 so that you know about the plans of this in the long term.

[arthuro555]

I think I would like to look into adding this generic variable field, and have began looking into it. Where do you think the "extra information" (if it is a global variable, scene variable, etc...)? I was thinking of adding a std::vector<gd::String> inside gd::Expression for that, but maybe you have a better idea? I would like to be sure before I do too much work in case it is a bad idea.

[arthuro555]

Actually, now that I think about it, I was going to go with the last suggestion on trello of keeping selection of the variable type "hidden" from the user, but how would we make it work in expressions? Expressions are not necessarily built with the expressions builder, hence the autocomplete, and all that is stored is the expression text, so we cannot make this invisible to the user. I think we need a syntactic way of describing a variable.

[arthuro555]

Another solution would be a more "breaking change" would be to make variables more "clever". This idea would be the following: expressions can return variable and we do not use expressions to get variable values. For example, the Variable(variableName) expression would no longer return a number but a reference to the scene variable (and VariableString would be removed).

Then, we can either (1) infer from the type of field the variable reference is used in to know what to call on it or (2) allow to use it like an object to explicitly say to get it under a special type.

For 1, it would look like this:
In a field that accepts a text:
Before: VariableString(myVar) After: Variable(myVar) Exported code: gdjs.evtTools.variable.getSceneVariable(runtimeScene, "myVar").getAsString()
In a field that accepts a number:
Before: GlobalVariable(myVar) After: GlobalVariable(myVar) Exported code: gdjs.evtTools.variable.getGlobalVariable(runtimeScene, "myVar").getAsNumber()

With 2 it would look like this:

In a filed that accepts a text:
Before: Object.VariableString(myVar[0]) After: Object.Variable(myVar)[0].String() Exported code: gdjs.evtTools.object.getObjectVariable(objectsList[0], "myVar").getChild(0).getAsString()

In a field that accepts a variable regardless of 1 or 2:
Before (in a scene variable field): NameOfTheVariable.hello After (in a generic variable field): Variable(NameOfTheVariable).hello Generated code: gdjs.evtTools.variable.getSceneVariable(runtimeScene, "NameOfTheVariable").getChild("hello")

I would prefer the first option but

This would solve the problem because we can just use the adequate expression to select the variable scope (like we do currently in expressions) and would allow to have powerful new expressions (FromJSON("{\"hello\": 6}").hello, P2P::LastEventVariable().playerX...).

The disadvantage of course is that this is a huge breaking change and may be unfamiliar/unintuitive to current users.

[Silver-Streak]

I'm going through some of the older discussions and saw this.

@arthuro555 What about an extra set of expressions that accept any variable type, rather than replacing? This leaves the specific-typed variables for users that want it (and avoids being a breaking change), but then you could add something like Object.VariableAnyType() (Or AnyVariableType, or something less specifically named, like VariableGSO (Global/Scene/Object)).

[arthuro555]

I believe generally that variable expressions are the future, but I see how it would be a huge breaking change and thereby problematic. I've rewritten my proposal on the forum a few days ago but without the automatic type inferring of variables, just the variable expression thing. I've removed that other part to not make it too "complex" by being foreign to current users.

https://forum.gdevelop-app.com/t/reworking-variables-to-be-returnable-by-expressions/34593?u=arthuro555

[arthuro555]

Yes, this was mentioned multiple times and is in my opinion really needed. It will also help with avoiding mistakes as currently we have to declare one instruction for each variable type 😬
Would this be a good GSoC project idea? Maybe it is a bit too big?

[tristanbob]

I am updating my original post because I discovered that you CAN use multi-level scene variables:

[4ian]

Yep this was a nice addition from @arthuro555 :)