@HellGateSc2: Go
It's not possible because reverse compilation is an almost impossible problem, Blizzard being lazy or not.
GUI triggers are compiled to Galaxy. Decompiling the Galaxy source to triggers (essentially another programming language) is extremely hard and would be too naive if implemented.
It is.
There's a series of functions called TriggerAddEvent*, that add events to triggers. Depending on the event you want to add, you use a different TriggerAddEvent function. Check out the natives.galaxy file.
@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.
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.
@s3rius: Go
If that is so, then the memory limit is in fact just a program stack-size limit... Which makes things far easier than I expected. I'll try to get a confirmation on that from MindWorx and I'll run some tests when I get the time. Should have started a Galaxy code generator aeons ago anyways...
I'm interested in testing the memory space limit in SC2.
Does anyone have a clear idea on what is the current memory space size limit and what counts as "in memory"? Last time I checked, certain stuff didn't count... I think it was stuff stored inside the Data Table, though I'm not sure.
@Rushhour: Go
I'm very interested in it.
It might push more people to write Galaxy code directly rather than just triggers, if only to put more code into their maps more easily.
0
@HellGateSc2: Go It's not possible because reverse compilation is an almost impossible problem, Blizzard being lazy or not. GUI triggers are compiled to Galaxy. Decompiling the Galaxy source to triggers (essentially another programming language) is extremely hard and would be too naive if implemented.
0
@s3rius: Go One can always use a precompiler to... oh wait -_-
A X-to-Galaxy compiler will write that if-then-else block for you. If one existed (other than Andromeda, which I have ideological differences with).
0
@s3rius: Go Sheesh, the unclarity a simple compiler would solve... -_-
0
Sometimes you might want to check a condition without performing the actions. Hard to use in GUI, stupid to use when scripting directly in Galaxy.
0
It is. There's a series of functions called TriggerAddEvent*, that add events to triggers. Depending on the event you want to add, you use a different TriggerAddEvent function. Check out the natives.galaxy file.
0
@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.
0
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...
0
@Talon0815: Go
Brilliant post! Very useful for those who want to write Galaxy only, without dealing with the GE proper.
0
Thanks Maxi! Will sure be useful in the future.
Somebody with permission add this to the wiki!
0
Cool graphics!
0
They might as well have split the trigger into a "launcher" trigger and a "logic" trigger. This is just bad code.
0
@s3rius: Go If that is so, then the memory limit is in fact just a program stack-size limit... Which makes things far easier than I expected. I'll try to get a confirmation on that from MindWorx and I'll run some tests when I get the time. Should have started a Galaxy code generator aeons ago anyways...
0
Hi!
I'm interested in testing the memory space limit in SC2. Does anyone have a clear idea on what is the current memory space size limit and what counts as "in memory"? Last time I checked, certain stuff didn't count... I think it was stuff stored inside the Data Table, though I'm not sure.
0
@Rushhour: Go I'm very interested in it. It might push more people to write Galaxy code directly rather than just triggers, if only to put more code into their maps more easily.
0
Can we upload the natives some place where it will remain easily accessible for all? Not just a pastebin?