Nested expressions

Hey everyone. I'm wondering if it is possible to hierarchically nest expressions for a plugin. For instance, say I'm writing a plugin where I want my plugin to have the following expressions:

XPosition

YPosition

XVelocity

YVelocity

XAcceleration

YAcceleration

In order to make everything more compact and easier to use in the C2 interface, I want to be able to have my plugin only have 3 expressions, Position, Velocity, and Acceleration, and then have each of those had an X and a Y expression.

While it doesn't matter if this were the case (having 6 expressions isn't that bad), I'm actually working on something where I have 20 things as part of my plugin, all of which have an X, Y, and a Z. I'd really like to avoid defining 60 expressions, because that would really get to cluttered for me and the person using my plugin.

Ultimately, I'd like it such that if the user is in the expressions panel and double clicks on my plugin name, they're shown the 20 things. They can then double click on that and be shown X, Y, and Z.

The limit is, the expression only can return number or string currently, so it's hard to chain the expressions.

Yea, I guess that does make this pretty impossible. Is that something that C2 devs have in mind to change sometime? Or are we stuck with that functionality until the end of time?

Actually, I don't feel like much would need to be changed to get this working. The current limit is that expressions can't return expressions. So let the parent objects be something other than expressions. When the engine is looking for expressions, it usually thinks "everything in the exps object must be an expression function". It could be changed to think "every FUNCTION in the exps object is an expression. every ARRAY in the exps object is a parent thing, so look for functions inside that array!"

Of course this might just be pointless thinking aloud. I'm relatively new here, so I don't know how much the developers pay attention to feature requests in the forums.

They do pay attention to it, pretty closely.

Nevertheless Scirra is a two-men team with a lot of work on their hands.

Also changes in the IDE needs to be passed to the exporter (C2's architecture).

Sometime what appears as "simple" to the user runs through complex tunnels behind the curtain.

This is unlikely to be ever changed, Construct 2 is just not architected to allow expressions to work like that. You will have a lot of expressions, but you can use the expression categories to group them in the UI and make them more manageable.

What you really want I guess is a proper vector type in expressions, but that would require a significant overhaul of the expression system right now so it's definitely off the cards for the time being.

Repsajo

I think there's at least one simple solution

just give it an extra parameter that contains an extra string parameter, to be set to "x" "y" or "z"    position("z")

also, I haven't made a plugin yet with c2, but if it has all the options construct classic does you should be able to create undefined expressions that don't require the name be explicitly specified in the code, allowing the ide to accept anything as an expression name. This way positiony or positionz can be handled through there by analyzing the name manually,

in construct classic sdk it'd be something like

long ExtObject::ReturnUndefinedExpression(CString& expName, LPVAL theParams, ExpReturn& ret)

{

switch(ExpName)

{

case "positiony"

   return ret=MyYPositionVariable;

case "positionz"

   return ret=MYZPositionVariable;

}

return ret = 0;

}

but handle positionx the normal way, then name the category something like "MyExpressions - also works with Y and Z".

this way right there in the category they see that there are alternate version of the expressions, but they still have the full list of the x versions, so they know what their choices are

The first way is probably less trouble (with the strings : position("x")) to implement,

and though the second method(undefined expression) is more natural in that you can just type PositionY like a normal expression, it would have the disadvantage that it would allow things like PosixionnY, which could make it difficult for a user to track down if a typo got through.

also, I haven't made a plugin yet with c2, but if it has all the options construct classic does you should be able to create undefined expressions that don't require the name be explicitly specified in the code, allowing the ide to accept anything as an expression name.

That's not in C2 yet.