Allow event extensions to define a condition with an operator based on an expression.

[D8H]

Based over:

• https://github.com/4ian/GDevelop/pull/3968

I added a test to check that expression and condition of an ExpressionAndCondition function are renamed. I tried to add a test where an expression is inside its own condition, but this can't be done with the current suite because it seems that the event function metadata are not initialized by the test.

Example

I manually tested some rename cases:

• https://www.dropbox.com/s/rs5aa0w5d4ts4s2/ExpressionAndConditionTest.zip?dl=1

[4ian]

Nice! This is corresponding to this card: https://trello.com/c/zwo0T1E7/479-add-in-events-function-a-condition-expression-type-that-would-allow-to-generate-both-an-expression-and-a-condition-to-check-it

there is probably some work to do an event refactorers.

I guess this would work by launching the expression refactorer first, then the condition?

[D8H]

I only covered the feature for the function renamer. Do you think other refactors could be important to cover too?

[4ian]

Nice thanks for the other tests :) Are we now covering:

• Extension renaming
• Function renaming
• Parameter move

for the new ExpressionAndCondition ? Maybe we should have this both for an extension and for a behavior? Not sure about this but because we have a "The order is important" and we don't really know why, tests might save us of a future regression here :)

[D8H]

It seems that moving parameters on expressions never worked because the scene or object and behavior parameters were not taking int account. Should I extract the fix in another PR?

[D8H]

The ExpressionAndCondition now has the same cover as Expression and Condition.

Free function

• Extension renaming
• Function renaming
• Parameter move

Behavior function

• Extension renaming
• Function renaming
• Parameter move
• Behavior renaming

I also updated the project example to check it manually.

[D8H]

There is still one issue that remains: adding new parameters make the operator and operand parameters to shift as they are at the end. We could do a refactorer for this.

But, adding new parameters to an ExpressionAndCondition will still break extensions compatibility when they are updated in the repository. We could try to add the 2 parameters at the beginning, but it seems hard to do. The parameter indexes of phase would have to be shifted.

I'm a bit torn between the 2 solutions. Compatibility is important, but having the parameters that represents the context before the 2 parameters for the condition feel more intuitive to me. It's not always the consistent across conditions though. For instance, the timer condition put the identifier first but the camera condition put the layer after which is not horrible either.

What is your view on this?

[4ian]

I'm not sure but intuitively it would be better to have these operator and operands parameter at a fixed place, at the beginning just after the "context" parameters, to avoid them being moved (so that you can add a new parameter, and the extension will continue to work when upgraded as long as you handle this parameter as being "optional"). Otherwise, it will be a pain (and even if we write a refactorer, it's... not a great design if we had the operator/operand at the end?).

I.e:

• First: Current Scene OR Object, then Behavior
• Then: Operator
• Then: Operand
• Then: the rest (because we can't know which of these parameters are an "identifier" and which are just additional parameters
• Then: the automatically insert eventsFunctionContext

At least that's what I would say intuitively?

For instance, the timer condition put the identifier first but the camera condition put the layer after which is not horrible either.

Can you give the examples you're mentioning?

[D8H]

I have to check that it works correctly with Choices, Color or other types.

[D8H]

This is how the function properties look for an expression. It's not ideal but it's not worst than having the expression type buried in the the function type where users are ask about it at the creation and could suppose there is no more choices.

I don't want to spend time to find a better design when it will be redesigned from scratch soon. This reuse what already exists and is still an improvement.

The related action parameters:

[4ian]

This will be huge for extension creators