Why not just aggregate the amount you heal in some variable and deal with it later?
The direct spell is easy to do - just add the amount healed to the variable.
The aura is more complicated, albeit doable - do you have access to the aura details? Can you plant some code in what happens to units in the aura? If so, it's just a matter of planting the same code you have in a direct spell in there. Concerning lag and aura-updating: you can set the update to happen not every time but every few times the units gets healed by the aura. That way the local aggregator for the aura would be updated without causing any kind of net traffic (unless I have the running model wrong) and only when you update the "global" aggregator will anything be transferred to other players. I know it won't be EXACTLY what you're looking for, but it's a reasonable compromise that will give you the approximate same behaviour.
Well FuzzYD - you can view yourself as a trailblazer. Like with any other programming language, we have raw Galaxy and there are those who will implement all the shorthands and compact calls that make it useable. You're one of them :)
One-shots are perfectly fine, no performance falls.
The only way for you to declare the variables in any sequence would be to parse a declaration in your format, decide what's what, and then reorder it in order to print it to a .galaxy file.
All in all, too much work just for that feature. Maybe you can plug this feature in into some bigger framework.
1. XML syntax is horrible. Why do people still insist on using it?
2. Why not just write function wrappers - that is, functions with less parameters that simply put default values in the parameters not given of the full method?
For example, the function foo(a1, a2, a3, a4) can be wrapped by foowrapper(a1,a3) that contains the following code:
foowrapper(a1, DEFAULTA2VAL, a3 DEFAULTA4VAL).
3. Can you write a function that returns the dynamic dialog? If it's rare enough, just generate it anew every time.
How does this affect TriggerExecute commands?
Is the trigger I've just executed put in the back of the line, or is it actually run right now as intended?
The apply-after-buff problem you've described above can be solved by registering the post-buff on a post-buff callback, if one exists. I see no reason to write the whole code in a single function.
What do you mean by registered?
Lets say I've registered a trigger T on a Roach being hit. Lets say I have two roaches, R1 and R2.
Assuming R1 was hit before R2 (or any linearization), will Galaxy process T(R1) first and T(R2) afterwards, or will it process them in parallel (thus assuming no shared state)?
Do triggers get executed in Galaxy sequentially in order of their events' arrival, or are they performed in parallel?
As much as I'd like them to run sequentially (and it is logical for an event based system that keeps track of state), in light of more recent discoveries and experiences with Galaxy I'm afraid the answer isn't obvious.
@grim001: Go
This is very interesting.
I'm working on generating Galaxy code from a certain theoretic model, but I'm doing my work in prolog. I generally tried to avoid any text-manipulating languages, like Perl, because if I want to do smart analysis (whether on the model, or plain Galaxy) those languages are very poor "hosts".
I would sure like to borrow your techniques, if you don't mind, when the time comes.
Can you further elaborate on "Specific error reporting"? Did you write an exception mechanism?
Galaxy is not C/Cpp.
I fail to see a reason for the "invisible i" that is taken from the TOS AS A VALUE to be evaluated to the current TOS position. Did any of you actually verify this by trying to fill up the file with crap till it exploded and checking that return value every time?
Recursion: I REALLY hope they implemented tail-call optimizations...
0
I have one file including another. When I want to access a global defined in the other file, I get a syntax error. What's the correct syntax for this?
variable = X? OtherFile.variable = X?
0
How about sharing, then?
0
Why not just aggregate the amount you heal in some variable and deal with it later? The direct spell is easy to do - just add the amount healed to the variable. The aura is more complicated, albeit doable - do you have access to the aura details? Can you plant some code in what happens to units in the aura? If so, it's just a matter of planting the same code you have in a direct spell in there. Concerning lag and aura-updating: you can set the update to happen not every time but every few times the units gets healed by the aura. That way the local aggregator for the aura would be updated without causing any kind of net traffic (unless I have the running model wrong) and only when you update the "global" aggregator will anything be transferred to other players. I know it won't be EXACTLY what you're looking for, but it's a reasonable compromise that will give you the approximate same behaviour.
0
@FuzzYD: Go
Well FuzzYD - you can view yourself as a trailblazer. Like with any other programming language, we have raw Galaxy and there are those who will implement all the shorthands and compact calls that make it useable. You're one of them :)
0
One-shots are perfectly fine, no performance falls.
The only way for you to declare the variables in any sequence would be to parse a declaration in your format, decide what's what, and then reorder it in order to print it to a .galaxy file. All in all, too much work just for that feature. Maybe you can plug this feature in into some bigger framework.
0
In an event-heavy map, the performance penalty might matter - imagine a DOTA where you had X times the computation when updating scores.
I think this pretty much sums up to a wrapper library, maybe a small preprocessor to allow easier declaration of variables. Please don't use XML.
0
1. XML syntax is horrible. Why do people still insist on using it?
2. Why not just write function wrappers - that is, functions with less parameters that simply put default values in the parameters not given of the full method? For example, the function foo(a1, a2, a3, a4) can be wrapped by foowrapper(a1,a3) that contains the following code: foowrapper(a1, DEFAULTA2VAL, a3 DEFAULTA4VAL).
3. Can you write a function that returns the dynamic dialog? If it's rare enough, just generate it anew every time.
0
How does this affect TriggerExecute commands? Is the trigger I've just executed put in the back of the line, or is it actually run right now as intended?
The apply-after-buff problem you've described above can be solved by registering the post-buff on a post-buff callback, if one exists. I see no reason to write the whole code in a single function.
0
Thanks guys! Really makes my work much easier. At least Blizz got this one right, and saved us the trouble of writing an event linearizer.
0
What do you mean by registered? Lets say I've registered a trigger T on a Roach being hit. Lets say I have two roaches, R1 and R2. Assuming R1 was hit before R2 (or any linearization), will Galaxy process T(R1) first and T(R2) afterwards, or will it process them in parallel (thus assuming no shared state)?
0
Do triggers get executed in Galaxy sequentially in order of their events' arrival, or are they performed in parallel? As much as I'd like them to run sequentially (and it is logical for an event based system that keeps track of state), in light of more recent discoveries and experiences with Galaxy I'm afraid the answer isn't obvious.
0
I gave up on parsing galaxy aeons ago, precisely because of stuff like that - and because I don't want to write yet anther C parser.
0
@grim001: Go This is very interesting. I'm working on generating Galaxy code from a certain theoretic model, but I'm doing my work in prolog. I generally tried to avoid any text-manipulating languages, like Perl, because if I want to do smart analysis (whether on the model, or plain Galaxy) those languages are very poor "hosts". I would sure like to borrow your techniques, if you don't mind, when the time comes.
Can you further elaborate on "Specific error reporting"? Did you write an exception mechanism?
0
@s3rius: Go
Sad indeed. It's something I expect first-year undergrads to be capable of. Truly, blizz, you disappoint me.
0
Galaxy is not C/Cpp. I fail to see a reason for the "invisible i" that is taken from the TOS AS A VALUE to be evaluated to the current TOS position. Did any of you actually verify this by trying to fill up the file with crap till it exploded and checking that return value every time?
Recursion: I REALLY hope they implemented tail-call optimizations...