Will a future C3 build convert old functions to the new system?

The same API (c3_callFunction()) also calls built-in functions.

One of the Most Powerful things that I liked about the Old Functions is that when you have to check a Condition that has many "Else" I could just then replace it by calling directly the Function to avoid many Else checks unnecessary especially when it has to check it very often, I tried to do the same with the New Functions but I couldn't, is this feature removed? will it be in the future? as it's very useful

Thanks

Here is what I mean:

On here I have to check which type of Enemy is and depends on which enemy is he has to do different things, I haven't done any actions but you can get the idea

When the Else becomes to many like on this Picture

I just Replace it by this

It's impossible to get all the benefits of functions if you can call them by name, since it can't display the correct parameters and validate them. Instead you can pass the dynamic part of the function name as a parameter instead.

The same API (c3_callFunction()) also calls built-in functions.

Thanks, that's great.

It's impossible to get all the benefits of functions if you can call them by name, since it can't display the correct parameters and validate them. Instead, you can pass the dynamic part of the function name as a parameter instead.

Thanks, I see what you mean

I tried the way you advised but I still get the same Results I have to through all the "Else" Checking which is that what I'm trying to avoid when using Functions,

Example:

I tried By Passing the UID through a Parameter and then Pick the Object and check the Variable "Enemy_Type" directly from the Object

Or by Passing the "Enemy_Type" Variable as a Parameter and check the results inside the Functions the same as the First Method.

But Both are exactly the same thing they have to go through the process of all the "Else" checking which can be really Performance Impact when you have many Enemies and many Different Variables to check very often, ending up with long lists of "elses" is there any way to avoid this like we could do with the old Functions? or is any Plans to add it on the Future? as this feature is really important

Thanks for your Time

What are you doing in those events? Sometimes you can eliminate the redundancy by using what you're passing as Enemy_type in an expression. For example you could look up a dictionary key, create an object by name, etc...

I'd rather not add this feature if at all possible, since it negates literally all the benefits of the new functions feature.

Doing anything by a string of the function name fundamentally removes the ability for Construct to do things like update all references to the function when you rename it, or show accurate results for "Find all references", etc. It would force you to go back to having to review the project when you make certain changes, which is slow, error-prone and laborious, and exactly what the new functions feature is designed to avoid.

I think it should be possible to support this without using expressions for function names, though. The equivalent in a programming language would be a map or a switch-case of a string to a function call. Construct doesn't yet have any equivalent, but we could add one. It could work something like this. Suppose you have "Call function <string>" which can call one of "Red", "Green" or "Blue". That could be replicated with a "function map" feature along the lines of this:

+ On start of layout

-> Create function map "color"

-> Map "color" string "Red" to RedFunction

-> Map "color" string "Green" to GreenFunction

-> Map "color" string "Blue" to BlueFunction

Note that RedFunction, GreenFunction and BlueFunction refer to built-in functions, and aren't strings (this would be some kind of new function-picker parameter). Then instead of "Call function <string>", you could use:

-> Call function from "color" map with <string>

This would then look up the string in the color map and call the corresponding function. E.g. call fucntion from "color" map with "Red" will call RedFunction. This should be the best of both worlds: you can dispatch function calls by a string, and it separates the concept of the string lookup from the function name. So if you rename one of the built-in functions all the references update and nothing is broken, and "Find all references" can still give you exact results.

This doesn't cover passing parameters though. One way of solving that would be to forward the parameters of another function call. So you could add a function like:

* On function ColorCall

* Parameter colorType

* Parameter someNumber

-> Call function from "color" map with string colorType and forward parameters from index 1

This would skip the first parameter (colorType) and just forward someNumber. So RedFunction, BlueFunction and GreenFunction all get called with one parameter (someNumber). Then in your events you can do:

-> Call function ColorCall (colorType: <string>, someNumber: <number>)

This then calls RedFunction(someNumber), GreenFunction(someNumber) or BlueFunction(someNumber) depending on the string 'colorType'. So you essentially get the same thing as calling a function by an expression, but you never used an expression for a function name.

Does that sound like it would cover this case?

yeah something like that sounds great, it seems like it would cover all the cases. like a switch statement though, would it have a default case? just in case for whatever reason the string is not mapped, or in that case would it just not call the function, and we get a warning in console?

That sounds good to me.

like a switch statement though, would it have a default case? just in case for whatever reason the string is not mapped, or in that case would it just not call the function, and we get a warning in console?

That's a good question actually. I think it would be useful to have a default-case function call in case nothing else matches, e.g.:

+ On start of layout

-> Create function map "color"

-> Map "color" string "Red" to RedFunction

-> Map "color" string "Green" to GreenFunction

-> Map "color" string "Blue" to BlueFunction

-> Map "color" default to OtherColorFunction

Then if you call a function by the string "Yellow", which isn't otherwise in the map, it would call OtherColorFunction. In this case it makes sense to pass all the parameters to OtherColorFunction since you'd probably want to look at the colorType string and do something different depending on that. So I guess if the default case is used, it should forward all parameters, ignoring any index provided.

That sounds like it would cover everything - and actually be quite a flexible and handy feature, especially since this way the default-case handling is more elegant than calling functions by a string (which would just do nothing if the function name doesn't exist).

Just to clarify something

+ On start of layout -> Create function map "color" -> Map "color" string "Red" to RedFunction

Wouldn´t it make more sense (and be more neat) to have that feature similar to the new function feature. Like a block that you add where you can define this rather than having to be created and populated in an event?