Functions Feature Needed

Functions needs to actually store and "know" the current list of function.

A current workaround is to create an object that stores function names in text instance variables. When you want to call a function you enter that object.shortcut name for function. I was thinking, why not allow the function to store and know the names of its own functions.

This would be my all time favorite update so far. I love using functions...hate keeping track of them all.

I requisted Functions to be a primitive similar to variabls. That way they apear int he auto filler.

So instead of

Function.Call( object.functionName, a, b, c)

you would get

functionName( a, b ,c )

just like a real function

Yes please!!! i get lost on all my functions... and needing to remeber the name when calling one...

Yes please!!! i get lost on all my functions... and needing to remeber the name when calling one...

You will always have to remember your function names to call them, no matter what But I know what you mean.

Until there's a better solution, I do:

Global constant text FN_SOME_FUNC = "SomeFunc"

Global constant text FN_ANOTHER_FUNC = "AnotherFunc"

---------------------------

Function: Call FN_SOME_FUNC( x, y, z)

Function: Call FN_ANOTHER_FUNC( "Hello")

---------------------------

And never have to remember another function's spelling, and they appear together in the drop-down.

codah that's a neat idea, actually, I think I might adopt that practice.

I'm all in favour of requests that improve workflow, so I'll definitely throw in my +1 for this suggestion (and jayderyu 's, while we're at it). Functions should always be ready to go, anyway - having to create a "function object" has always seemed a little odd to me.

I'd go as far as to say that functions should have their own window, like bookmarks, for easy access and reference. I've suggested the same thing with global variables in the past, as I really do think these windows are a great way to keep track of important info.

+1 a good suggestion!

This is a good idea. Namable parameters as well please. I know theres a third party plugin that does this but i think it should be standard feature.

Great idea ^_^

It would be very useful and time saving.

I requisted Functions to be a primitive similar to variabls. That way they apear int he auto filler.

So instead of

Function.Call( object.functionName, a, b, c)

you would get

functionName( a, b ,c )

just like a real function

If you think about it that doesn't really fit into the current way of doing things. I'm thinking you'd need to do something like

System: Call Function functionName(a, b, c)

and 'functionName' would have to be a Function 'type', and they would appear in the drop down list much like Object types in the System:Create Object dialog.

+1

I will +1 for the ability to have the function name remembered.

I will however -1 for the ability to have functions as a primitive, it adds nothing more than what we have and would need adjustements to not break things, and also this would be a breaking change unless the function object is still here, but then we would have both solutions for the same result.

Also having a basic template with all type of inputs, function object, and dictionnary and array would be nice to have, but not mandatory.

sorry. I should have been clear codah.

From an Event Action line yo are right.

System.Call(system.function, a, b, c )

Similar to variables listed in the system listbox if you do a lot of object clicking style programming. This style is already kinda supported by the current design, but puts the root C2 rather than use of a plugin.

Sprite.setX : functionName(a, b, c)

What I was thinking was for expression line where you embed function calls usually for the immidate return type in an expression. ie Sprite.AnimtionFrame = Function(blah). In this case the function being primititive and similar to vars.

I tend to use Functions a lot with expressions.

+1, I've been using the constant variable workaround but it's still a pain. I'll try OPs method.

TwinTails - My method is pretty much the same as using global constants - I just put them in an object because I NEVER use global variables; mostly because you can't sub group globals while you can use objects to sub group variable names... without subgrouping variables I can end up with hundreds of globals... and their names have to be stupid long to keep them organized (i.e... Character_FinalBoss_AtackStrength_01) this in turn makes some of the events harder to read...

In the end I create an object PlayerFunctions or BossFunctions... I then tend to name all variables according to certain conventions that allow me to keep them organized yet still easily accessible in that huge drop down list* ... and since I can sub group objects, finding what I want quickly becomes easier.

player_fm.caculateAtackVector (m = shortcut for math, f shortcut for function)

then that variable would be set to something like: "Player_Functions_Math_CalculateAtackVector" ... A real pain to spell out every time you want to call it... The beauty of it is that you never even need initialize any of these data storage objects as you normally just need their variables as constants.

While I am thinking about that dropdown list.... I think it is stupid*. It works when you have like 4 variables but not when you have dozens, if not hundreds... You can't even type in the name of the variable... you have to select from the list... but in other cases you can actually type it in. For example:

If I set a variable to some value, I have to select the variable from a giant drop down list. Only the first keystroke works to find it, but as I use v_before most variables this does me no good.

The reason I use v_before most variables is because If I do the following:

Player.physics.velocityX = V_somevariable .... and I haven't organized my variables its hard to find the variable in a list of all the sprites expressions and so on... Again, the default conventions are nice, but not in large projects. The bigger the project the more tedious some things become.

I would love a data object that simply stores variables, instead of having to use a sprite...