Moderator
M
Moderator
23.03.2016; BPower:
Update when you're new code is written.
If you still struggle with the double free issue ( comment make a post in
trigger&scripts or upload it directly here. I'll check it for you.
I like the system.
13th Mar 2015
BPower:You could null the timer t and the unit u onDestroy for best cleanup results.
In general you want to avoid using onDestroy, instead declare your own destroy method.
^A bit sloppy that you missed that one.
The demo map does not match with the code posted on the first page.
I think the wander events are an overkill.
Can you name a practical utility for each event you are providing?
You should check if a unit is already wandering to prevent a
multiple instance allocation case for the same unit handle.
Simple question. Can a unit order attack without having the ability to attack units?
I don't know the answer, but you should test it out.
Most times you want to neutral units to wander around the map.
You could try this one
I had to rethink from vJass to Zinc is not C, because of the syntax and slightly different
encapsulation rules. Correct me if I make a mistake.
By default a library / struct is completly private.
By declaring the struct as public struct everything inside is public, hence can be accessed by struct(this).var
Therefore you should privatize timer t, boolean onCooldown, unit u and real x, y, finalCooldown.
Furthermore privatize static method Update, better static method update to keep consistency of your function naming.
I feel that you could build in a getter by unit handle.
Either O(n) by looping over the entire stack of allocated instances
or more performant O(1) via unit handle id / unit user data.
Wander.getByUnit(myUnit) -> thistype or static method operator [] unit u -> thistype
I deliberately used the struct name Wander instead of WandererStruct,
because I think a name analogous to the default ability name is well-fitting.
Update when you're new code is written.
If you still struggle with the double free issue ( comment make a post in
trigger&scripts or upload it directly here. I'll check it for you.
I like the system.
13th Mar 2015
BPower:You could null the timer t and the unit u onDestroy for best cleanup results.
In general you want to avoid using onDestroy, instead declare your own destroy method.
(this.onCooldown == true)
--> this.onCooldown
^A bit sloppy that you missed that one.
The demo map does not match with the code posted on the first page.
I think the wander events are an overkill.
Can you name a practical utility for each event you are providing?
You should check if a unit is already wandering to prevent a
multiple instance allocation case for the same unit handle.
Simple question. Can a unit order attack without having the ability to attack units?
I don't know the answer, but you should test it out.
Most times you want to neutral units to wander around the map.
You could try this one
JASS:
if not IssuePointOrder(u, "attack", dx, dy)
IssuePointOrder(u, "move", dx, dy)
}
encapsulation rules. Correct me if I make a mistake.
By default a library / struct is completly private.
By declaring the struct as public struct everything inside is public, hence can be accessed by struct(this).var
Therefore you should privatize timer t, boolean onCooldown, unit u and real x, y, finalCooldown.
Furthermore privatize static method Update, better static method update to keep consistency of your function naming.
I feel that you could build in a getter by unit handle.
Either O(n) by looping over the entire stack of allocated instances
or more performant O(1) via unit handle id / unit user data.
Wander.getByUnit(myUnit) -> thistype or static method operator [] unit u -> thistype
I deliberately used the struct name Wander instead of WandererStruct,
because I think a name analogous to the default ability name is well-fitting.