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

0 favourites
From the Asset Store
Create your game with this complete pack of images and animations!
  • 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.

  • I agree calling function by a string name is very useful. A common use case I run into is buttons. Each button object normally has a string variable to designate a callback function when the object is clicked. This is not possible with the new system.

    Would it be possible to call parameter less functions by name?

  • 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?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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.

  • 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...

    Probably it wasn't a good example calling it only at the Start of Layout but Here is a better example to help illustrate what I was referring to, not sure if is the best example but I think you can get an idea, I tried to make it simple so it doesn't get messy with to much code, I just put a random example. so basically is just to illustrate that we call the Functions targetting directly the Enemy Type without checking every time "Elses" I hope it makes sense. but this is just one of many useful things that you can do by calling Functions by String.

    https://www.dropbox.com/s/ndkhuay0rgdsi79/New%20Functions.capx?dl=0

    ==================================================

    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>

    That sounds like an awesome Idea looks like is exactly what we need

    Thank you for looking into it

  • 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?

  • what would be the benefit of having it be it's own block? i think it will just be for better visual, since its integrated into the new function system, alot of the optimization that were done for that would probably apply to this mapping as well?

    also you might want to associate mapping functions with a condition that is triggered?

  • what would be the benefit of having it be it's own block?

    I don´t see why such a map would need to be created during runtime with individual actions, rather than just beeing there.

    i think it will just be for better visual, since its integrated into the new function system

    But it isn´t really, if you have to create it in an "on start of layout" event with individual actions.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)