is it possible to call a function from a variable? all functions take the same parameters
i saw something like #PARAM(var) but i don't know how to use it for my problem :/
in wc3 there was a variable type called code that works like this
local code func = function BlaBla
and i also don't want to make 1 function and 10 if's
1) You can store triggers in the data table - store the needed trigger there and get+execute it by string id.
2) You can create triggers on the fly from functions via CreateTrigger, see exact syntax in wiki. Create a trigger from the function and then run it.
What he means I think is if you can create functions that return values.
Trigger Test
Events
Event Unit Attacks
Variables
UnitName (type: string)
Conditions
Actions
Set UnitName = Getunit_Name(triggering Unit)
Text Message (convert string to text(UnitName)
Or you can skip the temp variable and do
Trigger Test
Events
Event Unit Attacks
Variables
Conditions
Actions
Text Message (convert string to text(Getunit_Name(triggering Unit))
Getunit_Name (Return as string)
Parameters
TempUnit(type: unit)
Actions
Getunit_Name = convert Unit Type of (TempUnit) to string
This is a sample of passing a parameter and then returning the string value of type of unit. This isnt very productive but it gets the value passing theory across I hope.
Switch statements do wonders for limiting the giant If then statements. Though they do not offer any better proformance. They just are a hell of a lot easier to read IMHO.
No a variable can only contain 1 type of data. Trying to add a function as a variable value pretty much breaks this whole concept as a function contains alot more then a single type value.
What you can do but also has some limitations is not using a function or action but using a trigger. You can save a trigger into the Data Table with the naming you want.
the naming is a simple string value so you can then load up the string values into an array and call on the data table entries to run the trigger of choise.
The only draw back you have with this method is you loose the ability to pass on parameters and have no return value. Your contruction will need an overhaul but can be achieved with this method
No what hes asking is he has like say 10 functions.
then wants to add those functions to a variable array and then run the fucntions out of a loop based on the array index.
What hes refering to in WC3 is actually now alot more complex and is infact the "Run Trigger" action we now have.
Just need to bend our minds alittle to deal with it compared to the old version.
Having a trigger as container instead of a function does allow alot more breathing room when coding as you can always still use global variables to pass on and return values from the trigger. It just doesnt work the way you would want by using a function directly
Can only be done using Custom Script, and even then it might not be exactly what you would like to have.
In custom script you can transform a string into a trigger, which can be run. You cannot run it as a function though, which means it cannot return any value and it can only take parameters as global variables.
If that's enough for you and if you're fine with using custom script I can write you a guide for it.
Umm .... One fucntion with 10 ifs .... doesnt really make much sense to me.... I dont think hes really sure what he wanted to be honest. Depends if he wants the ifs for calling the function or in the functions...
generally if he wants different code run inside the function itself i would pass a parameter to the function so it behaves differently when its ran.
Thats the logical way to do something like that anyways. Me thinks author of thread needs to clarify what hes looking for.
Rollback Post to RevisionRollBack
Skype
KageNinpo = SN
My Libraries
DialogLeaderboard & TeamSort
My Projects
SPACEWAR Tribute
Infinite TD
No need for custom script as we can use the datatable for the trigger string identification, but maybe that a custom script could be abit more efficent then doing it with normal ingame code.
I just like to use a datatable when possible due to its memory perks in the map.
No need for custom script as we can use the datatable for the trigger string identification, but maybe that a custom script could be abit more efficent then doing it with normal ingame code.
I just like to use a datatable when possible due to its memory perks in the map.
True, datatables work too :o
Well, the custom-script way has the advantage of actually requiring less memory because there's no need to create the triggers beforehand. They need only be created when used.
@s3rius: Go
The custom-script way requires more running time - parsing the string and interpreting it (if not even compile it, blizz really suck at writing script language [WOW Lua being an exception]). While most modern processors probably won't have problems with it, on a trigger-intensive map this might become cumbersome.
@s3rius: Go The custom-script way requires more running time - parsing
the string and interpreting it (if not even compile it, blizz really
suck at writing script language [WOW Lua being an exception]). While
most modern processors probably won't have problems with it, on a
trigger-intensive map this might become cumbersome.
It's a tradeoff one must consider.
kinda dbout this... considering... it does the same thing when it runs gui code....
Dynamically creating the trigger everytime it's used really needs more processing time, so for a function which runs very very often it's useful to make it a global trigger (basically turn it into what GUI calls a new-threaded action definition or so).
I'm using it for normal-sized functions that run maybe a couple of times per minute and I hardly have to care about the performance loss then :)
It doesn't do exactly the same. GUI creates the trigger when the function is called for the first time and then never destroys it. Instead it keeps it and re-runs it when it's used again.
That way is faster, but you don't get the memory for variables and triggers back.
The dynamic way re-creates the trigger anew everytime it runs, but destroys it immediately after.
@s3rius: Go The custom-script way requires more running time - parsing the string and interpreting it (if not even compile it, blizz really suck at writing script language [WOW Lua being an exception]). While most modern processors probably won't have problems with it, on a trigger-intensive map this might become cumbersome.
It's a tradeoff one must consider.
Uh, lol.
You know that the trigger editor works by outputting Galaxy script, right?
Oh you silly people and your wonderful theories.
To the OP - functions aren't first class variables in Galaxy, but triggers are, which allows you to store a trigger in a variable and then run it. But you lose the benefits of functions, namely parameters and return values. You can workaround by using global variables, however this will not be threadsafe so you must be careful for any race conditions that could potentially arise.
I think we need a whole new section on the site that breaks down what the game engine does with script / gui functions.
As riley stated the game intreprets GUI code the same as script because... GUI is script... with a gui interface.
I have looked through the script that my GUI code generates and I dont really see a reason for writing anything in code.
S3rius you say scripted function run differently but why would they? They are the same as GUI implement scripting.
It would be nice to put together an indepth section where we can read the nitty gritty detail and differencies. But I would also like to see some sources as to where people are getting this information from. I have yet to see one concrete reason to do anything with script. Other then what a few people say the benefits from using script are. Since technically GUI is script.
For example S3rius when you say that scripted function are released from memory. I think your talking about creating a function at run time.... which I really dont believe to be possible. Hell I cant even do that in Visual Basic, java, java script. Generally you need that stuff declared prior to run time. Which at that point it does consume memory.
But you said it goes a step furthere where my GUI triggers that have alot of variables used in them. You say these variables never release the memory they use. I find that hard to believe, and would really like to know where your getting your information from. Or how you determined this.
Rollback Post to RevisionRollBack
Skype
KageNinpo = SN
My Libraries
DialogLeaderboard & TeamSort
My Projects
SPACEWAR Tribute
Infinite TD
I have looked through the script that my GUI code generates and I dont really see a reason for writing anything in code.
[...]
It would be nice to put together an indepth section where we can read the nitty gritty detail and differencies. But I would also like to see some sources as to where people are getting this information from. I have yet to see one concrete reason to do anything with script. Other then what a few people say the benefits from using script are. Since technically GUI is script.
You are right, unlike the wc3 interpreter, the sc2 gui is converted into galaxy script quite nicely (with a few exceptions like the for each integer loop thing). Everything you do in a trigger is handled in one function, almost zero dumb wrapper functions like the bjs in wc3. Performance-wise it seems not to be bad to use the Gui.
I still use galaxy script for everything, though, because the Gui annoys the hell out of me. I'd rather type out calculations than having to look them up in a function list and click each parameter or something. Its just so much faster and easier to modify as soon as you know the basic function calls (and use a decend text editor with syntax highlighting and autocompletion)
S3rius you say scripted function run differently but why would they? They are the same as GUI implement scripting.
For example S3rius when you say that scripted function are released from memory. I think your talking about creating a function at run time.... which I really dont believe to be possible. Hell I cant even do that in Visual Basic, java, java script. Generally you need that stuff declared prior to run time. Which at that point it does consume memory.
He talks about trigger objects, not about actual functions, and his statement was correct. In Gui, there is no possibility to create a trigger at runtime; in galaxy script there is.
But you said it goes a step furthere where my GUI triggers that have alot of variables used in them. You say these variables never release the memory they use. I find that hard to believe, and would really like to know where your getting your information from. Or how you determined this.
Still, thats specifically for the trigger example: Creating a new trigger everytime you want to run a specific function and destroying it after it finished should save a tiny bit of memory, because the trigger is not there if the function is not running. In Gui, every trigger is always present, consuming some memory. If it is already present, access time is faster, because you do not have to create a new trigger.
is it possible to call a function from a variable? all functions take the same parameters
i saw something like #PARAM(var) but i don't know how to use it for my problem :/
in wc3 there was a variable type called code that works like this
local code func = function BlaBla
and i also don't want to make 1 function and 10 if's
some kind of interface
Im not quite sure what you mean...but functions are designed to return value to variables...
Like
set VariableReal = FunctionX
and in function X you can do some stuff and return a value to the variable that called the function
yea i know
but i want to call a function stored in a variable like
call VaraiableFunc[i](i,"idk",unit)
1) You can store triggers in the data table - store the needed trigger there and get+execute it by string id. 2) You can create triggers on the fly from functions via CreateTrigger, see exact syntax in wiki. Create a trigger from the function and then run it.
You can't run functions per se AFAIK...
What he means I think is if you can create functions that return values.
Or you can skip the temp variable and do
This is a sample of passing a parameter and then returning the string value of type of unit. This isnt very productive but it gets the value passing theory across I hope.
Switch statements do wonders for limiting the giant If then statements. Though they do not offer any better proformance. They just are a hell of a lot easier to read IMHO.
No a variable can only contain 1 type of data. Trying to add a function as a variable value pretty much breaks this whole concept as a function contains alot more then a single type value.
What you can do but also has some limitations is not using a function or action but using a trigger. You can save a trigger into the Data Table with the naming you want.
the naming is a simple string value so you can then load up the string values into an array and call on the data table entries to run the trigger of choise.
The only draw back you have with this method is you loose the ability to pass on parameters and have no return value. Your contruction will need an overhaul but can be achieved with this method
@Bezerker18: Go
I think hes asking if you can create a function you can call as if it were a variable. Thats what I make from his question, hence my example.
No what hes asking is he has like say 10 functions.
then wants to add those functions to a variable array and then run the fucntions out of a loop based on the array index.
What hes refering to in WC3 is actually now alot more complex and is infact the "Run Trigger" action we now have.
Just need to bend our minds alittle to deal with it compared to the old version.
Having a trigger as container instead of a function does allow alot more breathing room when coding as you can always still use global variables to pass on and return values from the trigger. It just doesnt work the way you would want by using a function directly
Why not just use a value say .....
Func_Index (type: integer) .... I generally use strings for this type of stuff so i have more flexability
and a switch
Not too complicated. But you need to set the "Func_Index" accordingly so you can control which chunk of code would be run.
Ya though of that first but then he also said
"and i also don't want to make 1 function and 10 if's"
Pretty much makes that code idea obsolete
Can only be done using Custom Script, and even then it might not be exactly what you would like to have.
In custom script you can transform a string into a trigger, which can be run. You cannot run it as a function though, which means it cannot return any value and it can only take parameters as global variables.
If that's enough for you and if you're fine with using custom script I can write you a guide for it.
Umm .... One fucntion with 10 ifs .... doesnt really make much sense to me.... I dont think hes really sure what he wanted to be honest. Depends if he wants the ifs for calling the function or in the functions...
generally if he wants different code run inside the function itself i would pass a parameter to the function so it behaves differently when its ran.
Thats the logical way to do something like that anyways. Me thinks author of thread needs to clarify what hes looking for.
No need for custom script as we can use the datatable for the trigger string identification, but maybe that a custom script could be abit more efficent then doing it with normal ingame code.
I just like to use a datatable when possible due to its memory perks in the map.
True, datatables work too :o
Well, the custom-script way has the advantage of actually requiring less memory because there's no need to create the triggers beforehand. They need only be created when used.
@s3rius: Go The custom-script way requires more running time - parsing the string and interpreting it (if not even compile it, blizz really suck at writing script language [WOW Lua being an exception]). While most modern processors probably won't have problems with it, on a trigger-intensive map this might become cumbersome.
It's a tradeoff one must consider.
kinda dbout this... considering... it does the same thing when it runs gui code....
@moshewe: Go
Dynamically creating the trigger everytime it's used really needs more processing time, so for a function which runs very very often it's useful to make it a global trigger (basically turn it into what GUI calls a new-threaded action definition or so).
I'm using it for normal-sized functions that run maybe a couple of times per minute and I hardly have to care about the performance loss then :)
@SouLCarveRR: Go
It doesn't do exactly the same. GUI creates the trigger when the function is called for the first time and then never destroys it. Instead it keeps it and re-runs it when it's used again.
That way is faster, but you don't get the memory for variables and triggers back.
The dynamic way re-creates the trigger anew everytime it runs, but destroys it immediately after.
Uh, lol.
You know that the trigger editor works by outputting Galaxy script, right?
Oh you silly people and your wonderful theories.
To the OP - functions aren't first class variables in Galaxy, but triggers are, which allows you to store a trigger in a variable and then run it. But you lose the benefits of functions, namely parameters and return values. You can workaround by using global variables, however this will not be threadsafe so you must be careful for any race conditions that could potentially arise.
Alot of this all sounds like theory craft to me.
I think we need a whole new section on the site that breaks down what the game engine does with script / gui functions.
As riley stated the game intreprets GUI code the same as script because... GUI is script... with a gui interface.
I have looked through the script that my GUI code generates and I dont really see a reason for writing anything in code.
S3rius you say scripted function run differently but why would they? They are the same as GUI implement scripting.
It would be nice to put together an indepth section where we can read the nitty gritty detail and differencies. But I would also like to see some sources as to where people are getting this information from. I have yet to see one concrete reason to do anything with script. Other then what a few people say the benefits from using script are. Since technically GUI is script.
For example S3rius when you say that scripted function are released from memory. I think your talking about creating a function at run time.... which I really dont believe to be possible. Hell I cant even do that in Visual Basic, java, java script. Generally you need that stuff declared prior to run time. Which at that point it does consume memory.
But you said it goes a step furthere where my GUI triggers that have alot of variables used in them. You say these variables never release the memory they use. I find that hard to believe, and would really like to know where your getting your information from. Or how you determined this.
You are right, unlike the wc3 interpreter, the sc2 gui is converted into galaxy script quite nicely (with a few exceptions like the for each integer loop thing). Everything you do in a trigger is handled in one function, almost zero dumb wrapper functions like the bjs in wc3. Performance-wise it seems not to be bad to use the Gui.
I still use galaxy script for everything, though, because the Gui annoys the hell out of me. I'd rather type out calculations than having to look them up in a function list and click each parameter or something. Its just so much faster and easier to modify as soon as you know the basic function calls (and use a decend text editor with syntax highlighting and autocompletion)
He talks about trigger objects, not about actual functions, and his statement was correct. In Gui, there is no possibility to create a trigger at runtime; in galaxy script there is.
Still, thats specifically for the trigger example: Creating a new trigger everytime you want to run a specific function and destroying it after it finished should save a tiny bit of memory, because the trigger is not there if the function is not running. In Gui, every trigger is always present, consuming some memory. If it is already present, access time is faster, because you do not have to create a new trigger.