Stasis Cube v2.2

[MyPad]

This is a new version of Stasis Cube, right? In your previous thread (if it would be open by then), you can click the Edit option on the bottom left of your resource, before any posts/messages.

Back to the post, I could see this being an example of when the (possibly) new native in the PTR, BlzPauseUnitEx can be used.

Edit:

Sorry about my previous suggestion (I forgot that thread was deleted). Next time, if you wish to update any resource in the future, do what is suggested above.

 

[Phantawalker]

This is a new version of Stasis Cube, right? In your previous thread (if it would be open by then), you can click the Edit option on the bottom left of your resource, before any posts/messages.

Back to the post, I could see this being an example of when the (possibly) new native in the PTR, BlzPauseUnitEx can be used.

I deleted the previos one because it wasnt good at all. I guess I will edit this one.
BlzPauseUnitEx - is this new one? What does it do?

 

[MyPad]

BlzPauseUnitEx - is this new one? What does it do?

Yes, but it's still on the PTR. It does the same thing as PauseUnit, but at least keeps the command card. It does not update IsUnitPaused though.

 

[Phantawalker]

Yes, but it's still on the PTR. It does the same thing as PauseUnit, but at least keeps the command card. It does not update IsUnitPaused though.

So its almost stun effect (without attached special visual effect overhead). I guess its good command to use it here (and no need to create dummies), but as I understand it would appear in next patch? I will reworked my spell as soon as it will be avaliable)

BTW, in blizzard.j I found that PlayerRegisterUnitEvent use integer 16 (as number of players). But in last patches all 24 players are avaliable (I cant see blizzard.j in last patch, because there no MPQ archives in my directory, only data files). In new version should I use 24 instead of 16 in the loop?

 

[Rigborn]

So its almost stun effect (without attached special visual effect overhead). I guess its good command to use it here (and no need to create dummies), but as I understand it would appear in next patch? I will reworked my spell as soon as it will be avaliable)

BTW, in blizzard.j I found that PlayerRegisterUnitEvent use integer 16 (as number of players). But in last patches all 24 players are avaliable (I cant see blizzard.j in last patch, because there no MPQ archives in my directory, only data files). In new version should I use 24 instead of 16 in the loop?

Use bj_MAX_PLAYERS it will return the max players allowed as an integer

 

[MyPad]

In new version should I use 24 instead of 16 in the loop?

Try 28 instead. Ensure that it is castable by every player.

 

[Phantawalker]

Try 28 instead. Ensure that it is castable by every player.

I have tried BlzPauseUnitEx, but its not working yet. Will be waitnig for next patch. I have fixed number of playes) Also I wanted to ask, is there any program for detecting BJ functions? (Here in hive you have amazing feature to preview triggers and see orange text).

 

[MyPad]

Well, as far as I know, no.

 

[Phantawalker]

Well, as far as I know, no.

I have found!) JASS SHOP PRO shows BJ's with other color!)

 

[nhocklanhox6]

Love the lightning

 

[MyPad]

Review:

The spell mechanics behind this are quite simple, yet they deliver in appearance and eye-candy. Lofty as the wind, dazzling as lightning, perfect as a cube, such a strange spell catches enemies in awe. Their minds too foolish to understand, they are slowly brought up into the sky, with the fury of the elements tearing the very tethers of their bodies apart.

Code:

Optimization:

Try to avoid Filter functions and For Group callback actions whenever possible. There are a lot of For Group callbacks in the spell. For the callback function EndCube, you can use a FirstOfGroup loop instead.

Avoid destroying boolexprs if they are only generated once, like this boolexpr:
Condition(function GroupCon)

Use one global dummy unit instead of creating a new dummy unit per target.

If multi-leveled, you can make these variables into arrays: (Add a prefix so that these variables can be easily identified, their names are too generic right now).

• Set Damage = 350.00
• Set Radius = 300.00
• Set Duration = 4
• Set LType = Chain Lightning - Primary

Try to replace GetUnitState with GetWidgetLife

The filter function GroupCon can be made into a customizable function like this:

//---Conditions for units when we add them to cube (unit must be alive, not building, not in other cube and an enemy of caster)---
function GroupCon takes unit u returns boolean
    return            (GetWidgetLife(u) >= 0.405) /*
               */ and (not IsUnitType(u, UNIT_TYPE_STRUCTURE)) /*
               */ and (not IsUnitInGroup(u, udg_StunGroup)) /*
               */ and (IsUnitEnemy(u, GetOwningPlayer(udg_Caster[udg_N])))
endfunction

Add more customizable fields, such as the model art of the stun, and model art of the lightning ball.
​

I can see a lot of room for improvement of the spell, such as added customizability, and optimizable functions.

For now, this shall be Awaiting Update

 

[Phantawalker]

Review:

The spell mechanics behind this are quite simple, yet they deliver in appearance and eye-candy. Lofty as the wind, dazzling as lightning, perfect as a cube, such a strange spell catches enemies in awe. Their minds too foolish to understand, they are slowly brought up into the sky, with the fury of the elements tearing the very tethers of their bodies apart.

Code:

Optimization:

Try to avoid Filter functions and For Group callback actions whenever possible. There are a lot of For Group callbacks in the spell. For the callback function EndCube, you can use a FirstOfGroup loop instead.

Avoid destroying boolexprs if they are only generated once, like this boolexpr:
Condition(function GroupCon)

Use one global dummy unit instead of creating a new dummy unit per target.

If multi-leveled, you can make these variables into arrays: (Add a prefix so that these variables can be easily identified, their names are too generic right now).

• Set Damage = 350.00
• Set Radius = 300.00
• Set Duration = 4
• Set LType = Chain Lightning - Primary

Try to replace GetUnitState with GetWidgetLife

The filter function GroupCon can be made into a customizable function like this:

//---Conditions for units when we add them to cube (unit must be alive, not building, not in other cube and an enemy of caster)---
function GroupCon takes unit u returns boolean
    return            (GetWidgetLife(u) >= 0.405) /*
               */ and (not IsUnitType(u, UNIT_TYPE_STRUCTURE)) /*
               */ and (not IsUnitInGroup(u, udg_StunGroup)) /*
               */ and (IsUnitEnemy(u, GetOwningPlayer(udg_Caster[udg_N])))
endfunction

Add more customizable fields, such as the model art of the stun, and model art of the lightning ball.
​

I can see a lot of room for improvement of the spell, such as added customizability, and optimizable functions.

For now, this shall be Awaiting Update

Thank You for the review, I will try to fix all those things)

 

[Phantawalker]

Review:

The spell mechanics behind this are quite simple, yet they deliver in appearance and eye-candy. Lofty as the wind, dazzling as lightning, perfect as a cube, such a strange spell catches enemies in awe. Their minds too foolish to understand, they are slowly brought up into the sky, with the fury of the elements tearing the very tethers of their bodies apart.

Code:

Optimization:

Try to avoid Filter functions and For Group callback actions whenever possible. There are a lot of For Group callbacks in the spell. For the callback function EndCube, you can use a FirstOfGroup loop instead.

Avoid destroying boolexprs if they are only generated once, like this boolexpr:
Condition(function GroupCon)

Use one global dummy unit instead of creating a new dummy unit per target.

If multi-leveled, you can make these variables into arrays: (Add a prefix so that these variables can be easily identified, their names are too generic right now).

• Set Damage = 350.00
• Set Radius = 300.00
• Set Duration = 4
• Set LType = Chain Lightning - Primary

Try to replace GetUnitState with GetWidgetLife

The filter function GroupCon can be made into a customizable function like this:

//---Conditions for units when we add them to cube (unit must be alive, not building, not in other cube and an enemy of caster)---
function GroupCon takes unit u returns boolean
    return            (GetWidgetLife(u) >= 0.405) /*
               */ and (not IsUnitType(u, UNIT_TYPE_STRUCTURE)) /*
               */ and (not IsUnitInGroup(u, udg_StunGroup)) /*
               */ and (IsUnitEnemy(u, GetOwningPlayer(udg_Caster[udg_N])))
endfunction

Add more customizable fields, such as the model art of the stun, and model art of the lightning ball.
​

I can see a lot of room for improvement of the spell, such as added customizability, and optimizable functions.

For now, this shall be Awaiting Update

I have reworked all those things)

 

[Phantawalker]

Updated with:

BlzPauseUnitEx

No more dummies and stun abilities needed.

 

[MyPad]

Imprisoning your enemies in a cage not good enough for you? Then do it with style.. lightning style
Guaranteed to halt your enemies in fear and awe, the lightning rods' connection release such energy that they uplift your enemies from the ground. For some reason, it doesn't do the same to your allies
but what the heck?

Notes:

• Variable names are too generic. I suggest adding a prefix to them (like "StasisCube_") so as to prevent variable name collisions.
  
  
• To reduce overhead, pass null as a filterfunc to the GroupEnumUnitsInRangeOfLoc parameter. Then, apply the filter function GroupCon within callback function StunTarget instead (from ForGroup call).
  
• Modifying the Learn Ability Hotkey to Q would be welcome here, since attempting to learn the skill in-game via hotkey might take some time (trial and error).

Suggestions:

• I still find the allocation scheme quite perplexing (going on a cyclic queue scheme), though I find the maximum index of 100 quite restrictive. I suggest setting the maximum index to be JASS_MAX_ARRAY_SIZE - 1 just for convention.

• Why not map out the (timer) trigger handle udg_T to the specific index used to contain it? Using a hashtable at least for mapping the (timer) trigger handle will make search time in function CubeCast O(1) as opposed to O(n) in the current scheme of things. Moreover, making it a timer handle instead will reduce handle count, since there would be no need of an additional trigger, save for callback upon timer expiration.
  
  
• Adding some eye candy on those who are currently affected by the Stasis Cube would be welcome.

The points made in the Notes portion of the review are to be resolved in order to be approved. For now, this shall be set to Awaiting Update