Command Parry

[Spacebuns]

Up until very recently I had no idea how a hashtable worked. But then I read a tutorial about hashtables and learned how they could store very large numbers, including the unique IDs given to handles that distinguish them from each other internally. So I decided to give it a try and came up with this spell because I've always wanted to make a parry that doesn't require a DDS. It has the honor of being my first creation with a hashtable

 

[Kakerate]

Novel idea (for WC3 maps atleast), good work!

 

[DarkePacific]

Very cool spell, tho in terms of game play id prefer if they didn't swap positions, but I'm sure that's an easy fix.

 

[MyPad]

I'd say that for your first time using a wc3 hashtable, it is actually quite a decent attempt. The config trigger is nicely documented, local handle variables are nullified properly, dynamic entries are handled appropriately, etc. That said, there are some logical statements that can be simplified:

Spoiler: Code Review

• Logical Comparison
  

  • function ParryAnimTimerEnd takes nothing returns nothing
        // (...)
        if time > time_max or time_max-time<0.01 then
        // (...)
    endfunction

    
    With a bit of arithmetic manipulation, the equivalent of the statement above becomes:
    if (time_max - time < 0.0) or (time_max - time < 0.01)
    
    Depending on which expression you choose, you can break it down into a single boolean expression, since these expressions are virtually the same.
    
• Storing Ability Handle
  

  • call BlzSetAbilityRealLevelField( BlzGetUnitAbility(u, 'AHtb'), ConvertAbilityRealLevelField('Htb1'), 0, dmg )
    call BlzSetAbilityRealLevelField( BlzGetUnitAbility(u, 'AHtb'), ConvertAbilityRealLevelField('ahdu'), 0, stunDur )
    call BlzSetAbilityRealLevelField( BlzGetUnitAbility(u, 'AHtb'), ConvertAbilityRealLevelField('adur'), 0, stunDur )

    
    You can store the result from BlzGetUnitAbility into an ability variable, so that you don't have to call the function thrice to get the same value.
    

I would also like to point out that the generation of dynamic timer handles for the purpose of running a set of specific callbacks would normally be pointed out as well as the above. However, given that these timer handles do not exist for long anyway, this could be something worth optionally fixing.

I'll test this further for any bugs or potential memory leaks that can be cleaned up (aside from units).

 

[Spacebuns]

Thanks for the feedback! I've uploaded a version which incorporates the suggestions you made.
In it I've also made sure that only one dynamic timer handle will exist for an event at any time, cleaning up the current timer if the event is triggered while it is still running. But even without this cleanup, in standard situations (not making parry timer cooldown lower than parry valid duration, not spamming stop during attack animation), a unit should have only one timer running for each timer type at a time.

 

[MyPad]

After a more careful review on the trigger actions, here are some more things to address:

• The trigger Parry init vars appears to be a config trigger. That said, attempting to modify values within this trigger will not work, since they are overridden by the succeeding triggers.
  • The trigger Parry cast event overrides the following variables:
    • Parry__Range
    • Parry__EffectDamage
    • Parry__EffectStun
    • Parry__EffectName
    • Parry__EnableFaceback
    • Parry__CastLength
    • Parry__EnableAnim
    • Parry__AnimLength
    • Parry__AnimInterval
    • Parry__AnimName
      
  • The trigger Parry attacker event overrides the following variables:
    • Parry__AttackLength
    • Parry__LoopInterval
      
  • Since the values are going to be assigned upon map initialization, it would be best to remove the lines which override the above variables within their respective triggers.
    
• The trigger Parry cast event can work just as well with (A unit starts the effect of an ability).
  
  
• You might want to caution users regarding the usage of the following variables within the trigger Parry user defined effect:
  • Parry__AttackPoint -> Attacker's location
  • Parry__CastPoint -> Caster's location
    
    Both of these variables can be read, but not modified nor cleaned up within the trigger's actions, since the script already deals with them.
    
• Just to be safe (if abilities do leak), it would be preferable to null the local ability handles at the end of the function ParryEffectAction.
  
  
• Since the coordinates of the source and the target are already accessible, there's no need to use SetUnitPosition to reposition both the source and the target, unless order interruption is desired for both units. You can use SetUnitX and SetUnitY instead.
  • SetUnitPosition usage found in the function ParryEffectAction.

 

[Spacebuns]

After a more careful review on the trigger actions, here are some more things to address:

• The trigger Parry init vars appears to be a config trigger. That said, attempting to modify values within this trigger will not work, since they are overridden by the succeeding triggers.
  • The trigger Parry cast eventoverrides the following variables:
    • Parry__Range
    • Parry__EffectDamage
    • Parry__EffectStun
    • Parry__EffectName
    • Parry__EnableFaceback
    • Parry__CastLength
    • Parry__EnableAnim
    • Parry__AnimLength
    • Parry__AnimInterval
    • Parry__AnimName
  • The trigger Parry attacker eventoverrides the following variables:
    • Parry__AttackLength
    • Parry__LoopInterval
  • Since the values are going to be assigned upon map initialization, it would be best to remove the lines which override the above variables within their respective triggers.
• The trigger Parry cast event can work just as well with (A unit starts the effect of an ability).
  
  
• You might want to caution users regarding the usage of the following variables within the trigger Parry user defined effect:
  • Parry__AttackPoint -> Attacker's location
  • Parry__CastPoint -> Caster's location
    
    Both of these variables can be read, but not modified nor cleaned up within the trigger's actions, since the script already deals with them.
• Just to be safe (if abilities do leak), it would be preferable to null the local ability handles at the end of the function ParryEffectAction.
  
  
• Since the coordinates of the source and the target are already accessible, there's no need to use SetUnitPosition to reposition both the source and the target, unless order interruption is desired for both units. You can use SetUnitX and SetUnitY instead.
  • SetUnitPosition usage found in the function ParryEffectAction.

Spoiler

The trigger Parry init vars appears to be a config trigger. That said, attempting to modify values within this trigger will not work, since they are overridden by the succeeding triggers.

Done. I've clarified in the comments.

Spoiler

The trigger Parry cast event can work just as well with (A unit starts the effect of an ability).

That is correct. However, for the purpose of demonstration, I used Berserk, which happens to be a spell that only UNIT_SPELL_FINISH event fires consistently with each cast.

Spoiler

You might want to caution users regarding the usage of the following variables within the trigger Parry user defined effect

Done.

Spoiler

Just to be safe (if abilities do leak), it would be preferable to null the local ability handles at the end of the function ParryEffectAction.

Done. Still, I hope abilities don't leak, since they're a new type of handle, yet completely lack "destroy" functions.

Spoiler

Since the coordinates of the source and the target are already accessible, there's no need to use SetUnitPosition to reposition both the source and the target, unless order interruption is desired for both units.

Yes, order interruption is intended here.

 

[MyPad]

The spell works fine, though there is a small activation window between casting the parry ability and the moment the caster is attacked. Parry carefully, and pray to the god-platypus Perry that your ping permits you to do so.

Approved

 

[HandsOfficial]

damn dude thats awesome
dark souls map 2023????

 

[Lt_Hawkeye]

damn dude thats awesome
dark souls map 2023????

There is actually already a dark souls map in existence.

 

[Izzetin]

Is it possible to ''Parry'' not attacks but direct Spells ?

 

[Pyrogasm]

Is it possible to ''Parry'' not attacks but direct Spells ?

Yes you just need to change the Parry Attacker Event trigger event and all of the event responses that depend on the original event:

• Events
  • Unit - A unit starts the effect of an ability
• Conditions
  • (Level of Parry__Ability for (Target unit of ability being cast)) Not equal to 0
  • ((Triggering unit) belongs to an enemy of (Owner of (Target unit of ability being cast)).) Equal to True
• Actions
  • Custom script: local unit u = GetTriggerUnit()
  • Custom script: call SaveUnitHandle(udg_Hash_Parry,tid,udg_Parry__CKey_Caster,GetSpellTargetUnit())