Hi 
Ashley and the rest in the Construct Team.
I would like to talk about the Functions built-in. There seems to be 2 issues I've found. I understand how much thought you've might given the new Functions, but I think you might have missed a few important points.
- Redundancy
- Limitation
I've made a few events to showcase the issues I've encountered. There are lots more actually but I think this is enough to give a point and to show the solution's effectiveness.
Redundancy
Mapping
The current state of the Functions built-in has a few unnecessary parts, specifically the Map Function to string.
By design, a Construct 3 function is already a string, for simplicity sake, can we instead of Map function to string to use the function name instead as a string reference.
It doesn't feel like it's worth all the trouble. Considering less events are better in both performance and readability.
If you really think mapping features are necessary, then I think this should be left as optional, like a tag action.
Redundancies are something we can still endure though but I think it can be on its best when remaining simple but effective.
Limitations
Unlike redundancies, limitations are the project stopper on the user end. They make it nearly impossible or at least hard to manage development. I'll show a quick show why,
Parameters & Expression Function Call
Parameters ::
It's of an upmost importance to be able to control the parameters, for example making a dynamic function inside a current function where the input parameters of the current function determines which function will run and what parameters are passed.
Just like the screenshot above, the ConversionMode controls the function to be called for and what parameters are passed, dependent on the process output data.
It might come of question:
Why not make direct call function and make the comparison on a base event?
It's because of its inefficiency in readability, organization and event count-performance. For example, I've done a function of a Character Creation Class, which has its own sub-class functions (Not in the same event). Calling those sub-class functions on the parent event instead can lead to very confusing events, almost impossible to call organized.
It can be said similar to developing a regular app using JS without passing dynamic arguments or functions having the same parameters when passed.
We are already limited to Global Functions, I feel like we don't want to add any more limitations like this.
Parameter Count & Param(i) ::
I have to give it to the Construct Team. The default function is a great feature. A fallback for a function is very handy, and it also gives an opportunity to showcase a limitation.
We know the it basically passes all the parameters of a misfired function to the default function.
Although, the passed parameters are lost.
The problem here is that, similar to the regular built-in function, we can't manage the parameters, like get its Count and Param(i), where it's crucial for this to work.
JavaScript has this feature, Construct 2 also has this feature. I believe it's really crucial to get these features back.
Other info
I understand the amount of thought and work you guys have made, it might work in the theory planning, but I can assure that it's really hard to do in real development.
I asked other regular users of Construct 3 on how they managed to get around these limitations. Interestingly, I got these answers:
- They use scripting. And they even suggested me to do that.
- They use the old Construct 3 Function by importing a Construct 2 .capx with a Function plugin.
The first idea makes sense, but with my workflow, I only want to use scripting when it can't be done with Construct 3's core plugin. And that makes sense, cause Construct 3 promotes being mainly visual-editor based.
The 2nd one, I've done that for my projects. But, after the variadic-parameters issue, it broke lots of projects, including mine. If a time comes where the old Construct 3 Function becomes depreciated, it would be another rewrite and heavier this time. Which I'm not planning to go with again.
As much as possible, I'd like it resolved now, while it's early.
Solution
Redundancies
The redundancy issue compromises a bit of organization of events and increases event count, but nothing that isn't manageable. But it can become better.
I have a suggestive solution,
Instead of having the Call mapped function, how about just making it into a Call action. Instead of having the Map default function, how about making it Set default function. With this, we don't need to Map function to string since a function is already a referenced by a constant string. Especially, we wouldn't need maps at all.
The function name is already a great candidate for a function reference string. But if you really need to, a Tag function to string action can also be an option.
Limitations
Parameters ::
I'm not sure why the Functions (built-in) had an ACE change, but I'm guessing it has something to do with Variadic Parameters. But if that's the case, an easy solution is add new actions to the actions list, that would be the following:
A parameter stack, would be a great replacement. I've tried it and it's an easier replacement to use.
Parameter Count & Param(i) also Compare ::
Having the expressions ParamCount & Param(i) and the condition Compare Parameter as an additional feature would really be useful on dynamic cases.
Basically, at this point, I'm asking for integration of the old Function to the new built-in Functions.
Hoping for your kind consideration.
Thank you for your time.