Ground Charge v1.00

[Moderator]

13:34, 27th Aug 2015
IcemanBo: Posts in thread.

 

[Flux]

Changelog:

v1.00 [15 August 2015]
- Initial Release

 

[IcemanBo]

• (X of Ch_TempLoc2) Greater than or equal to (Max X of (Playable map area))
  • (X of Ch_TempLoc2) Less than or equal to (Min X of (Playable map area))
  • (Y of Ch_TempLoc2) Greater than or equal to (Max Y of (Playable map area))
  • (Y of Ch_TempLoc2) Less than or equal to (Min Y of (Playable map area))

I believe there is a gui condition that checks if your point is in playable map area, so you don't need to check for cooditnates by yourself.

You don't check for trees, but kill all destructables. So also bridges, gates and others will be killed, too.

Manipulating custom value of units is not allowed. It's reserved for unit indexers only. (at least here in public resources)

• Custom script: set udg_Ch_AffectedUnits[udg_Ch_MaxIndex] = CreateGroup()

^You do this without any check. But group [0] and [1] already are initialiszed so it will leak.
You can simple avoid the leak by destroying them onInit, then no check is needed, or check if group equals null before you create a group.

Honestly I think your check for x/y onCast if they equal with caster's position is not needed. It will be like never the case that they are exactly the same.

 

[Flux]

• (X of Ch_TempLoc2) Greater than or equal to (Max X of (Playable map area))
  • (X of Ch_TempLoc2) Less than or equal to (Min X of (Playable map area))
  • (Y of Ch_TempLoc2) Greater than or equal to (Max Y of (Playable map area))
  • (Y of Ch_TempLoc2) Less than or equal to (Min Y of (Playable map area))

I believe there is a gui condition that checks if your point is in playable map area, so you don't need to check for cooditnates by yourself.

I see, I will use the GUI equivalent then

You don't check for trees, but kill all destructables. So also bridges, gates and others will be killed, too.

Noted.

Manipulating custom value of units is not allowed. It's reserved for unit indexers only. (at least here in public resources)

I manipulated the shadow trail's custom value not the actual caster so I don't see how that will affect anything

• Custom script: set udg_Ch_AffectedUnits[udg_Ch_MaxIndex] = CreateGroup()

^You do this without any check. But group [0] and [1] already are initialiszed so it will leak.
You can simple avoid the leak by destroying them onInit, then no check is needed, or check if group equals null before you create a group.

The destroying at Init part is better so I will do that.

Honestly I think your check for x/y onCast if they equal with caster's position is not needed. It will be like never the case that they are exactly the same.

It happens when you clicked on the Hero's Portrait when the Hero is not moving.

 

[KILLCIDE]

So many triggers ;_; nonetheless, works well for me! If I may ask, is it always better to set Picked Unit to a variable?

 

[Flux]

So many triggers ;_; nonetheless, works well for me! If I may ask, is it always better to set Picked Unit to a variable?

Yes, if you are gonna used it more than once because (Picked Unit) is a function call and variable lookup is faster than a function call.

 

[IcemanBo]

...

• I don't know if I very like the animation index system. Use UnitType over Unit as parameter, as a unit can exist or not, a unit type always does. (you need preplaced units)
  I'm not very sure now, but if you use channel I think there is a possiblity to loop a certain animation while casting. If so, it would drop the whole animation system.
  If someone knows what I mean he is welcome to post here, but I also need to test it myself again I think.
• You know JASS, so you could actually create one static rect for tree destruction, which is never destroyed.
• I repeat, don't manipulate custom values. You never know how systems work.
• Index owner of caster.
• It's more readably if you filter units via conditions inside your ITE statement then using "MatchingUnit".
• Damage- Attack type should be configurable.
• You can think of using system for knocking units and tree destruction.

The transparency feature looks cool. Also think of the points in the other post.

 

[Flux]

...

• I don't know if I very like the animation index system. Use UnitType over Unit as parameter, as a unit can exist or not, a unit type always does. (you need preplaced units)
  I'm not very sure now, but if you use channel I think there is a possiblity to loop a certain animation while casting. If so, it would drop the whole animation system.
  If someone knows what I mean he is welcome to post here, but I also need to test it myself again I think.
• You know JASS, so you could actually create one static rect for tree destruction, which is never destroyed.
• I repeat, don't manipulate custom values. You never know how systems work.
• Index owner of caster.
• It's more readably if you filter units via conditions inside your ITE statement then using "MatchingUnit".
• Damage- Attack type should be configurable.
• You can think of using system for knocking units and tree destruction.

The transparency feature looks cool. Also think of the points in the other post.

• Yeah, using unit-type is better. I tried placing "walk" in the Animation Names but it does not work.
• Ok, so I will use MoveRect?
• I know it is in the Rules but I don't see how manipulating the custom value of the Shadow Units (not the caster) will affect anything. Will it not work if this is imported to a map with Unit Indexer? I just used it as a way to de-index easier (unit group acting as a linked list)
• Ok
• But the tendency is that unit-group will initially have a lot of units. To be honest, I don't know which is better in terms of performance. (That's why I asked)
• Will do
• That depends

Yeah I still keep in mind those other things you pointed in your first post.

 

[IcemanBo]

Yeah, using unit-type is better. I tried placing "walk" in the Animation Names but it does not work.

Hm, sad if it won't work. :/

Ok, so I will use MoveRect?

Yes. I would not say it's required for GUI, but it's good habit to do so. And I think you are on that level! ^^

manipulating the custom value of the Shadow Units

It's not good if there exist more than one unit with same custom value.
A unit can't be identified anymore uniquely through custom value in what ever code.

But the tendency is that unit-group will initially have a lot of units.

True. It will be bigger, I'm not sure of performance differences, but it's much more readable, especially in GUI I think.