New parameter for instructions: "predicate"

[arthuro555]

In javascript, it is common to pass a function to another function for flexibility. This allows for nice methods like array.map, array.sort, array.find, array.filter... Those are impossible in GDevelop as of now, but a partial solution would be a "predicate" codeonly parameter. What it would do:

• Make the instruction CanHaveSubInstructions that are conditions
• Compile the subinstructions into a function
• Pass that function as parameter to the function of the instruction

This is only a partial solution as it would only support conditions, but I think it would be pretty clean compared to other solutions for creating "lambda functions" in events and help in a lot of cases already.

[arthuro555]

An alternative would be creating something like the promise event as described here but the "sub events" would be passed as a callback instead of using promises (as they are not necessary, if asynchronous programming is added it would use async/await syntax) and that callback could then be used as predicate, as callback to a recurring event like the Firebase onAuthStateChange event or anything you would use a lambda function for.

[4ian]

There is surely something to explore here, but I would rather achieve asynchronous actions (and conditions) first, as they are an "obvious" missing feature (the biggest one being a "Wait X seconds" action, and actions making requests).

I say obvious in the sense that this concept of asynchronous is something that any user will quickly search for, because it's already part of our natural language: "If object is there, then do something, wait for a few seconds, and do something else" (i.e: you find the idea of the condition, the action, the wait, another action).

The "natural language" is an important point, because most concepts from the events in GDevelop are coming from this (you can almost read events, and you can at least understand them intuitively without a background in coding).
So I would wait to see after the support for "promise" if we actually need this badly (are there a lot of uses cases for this?), if we can simplify (even the word predicate is either an obscure grammar stuff, or a first-order logic concept from mathematics) or if we can do this otherwise.
The less concepts we have to learn as a user, the better it is.

[arthuro555]

but I would rather achieve asynchronous actions (and conditions) first, as they are an "obvious" missing feature

Yes, I was mentioning that feature because I think some of the propositions I have made here could be reused for that feature, but I am not claiming this feature is more important or better than async.

if we actually need this badly (are there a lot of uses cases for this?)

Well, filtering, mapping and sorting of arrays is imo important and wouldn't really be possible (or be severely limited) without this. If taken over to the next level it could allow to make for example very flexible custom behaviors, for example one could make a state machine behavior that accepts some "lambdas" to define what actions do to each frame for each possible state (though this example is kind of useless and we are far from there at the moment).

even the word predicate is either an obscure grammar stuff, or a first-order logic concept from mathematics [...] The less concepts we have to learn as a user, the better it is.

That's the thing, the main proposition I am making here is not about users, I am talking about a code only parameter that allows one making a JsExtension to use sub-instructions without writing a custom code generator by passing a function executing those sub-instructions to the implementation instead. To users, it's invisible, intuitive, and just like the or and and conditions.