Crowd Control & Tenacity

[MyPad]

A largely compact resource that incorporates and handles common CC effects swimmingly well, drastically reducing the groundwork of the mapper. It has already seen usage in other approved spell resources (mostly Hero Concepts), so approval for this bundle is merely a formality.

Spoiler: Code Review

There are certain parts of the code that could use some refactoring for clarity that I didn't notice before. Nothing too major though, so it should be easy to deal with.

Utilities library:

• In the function GetEnemyUnitsInRange(player enemyOf, real x, real y, real aoe, boolean structures, boolean magicImmune), multiple versions of what is functionally the same loop exists. At the cost of evaluating the provided boolean values once, you can rewrite it as the following:
  
  

  loop
      set w = FirstOfGroup(h)
      exitwhen w == null
          if IsUnitEnemy(w, enemyOf) and UnitAlive(w) and /*
         */ (structures or (not IsUnitType(w, UNIT_TYPE_STRUCTURE))) and /*
         */ (magicImmune or (not IsUnitType(w, UNIT_TYPE_MAGIC_IMMUNE))) then
              call GroupAddUnit(g, w)
          endif
      call GroupRemoveUnit(h, w)
  endloop

  
  
• The same applies for the function UnitDamageArea(unit source, [...], boolean structures, boolean magicImmune, boolean allies). You can rewrite it like this:
  
  

  loop
      set w = FirstOfGroup(h)
      exitwhen w == null
          if (UnitAlive(w) and w != source) and /*
          */ (allies or IsUnitEnemy(w, enemyOf)) and /*
          */ (structures or (not IsUnitType(w, UNIT_TYPE_STRUCTURE))) and /*
          */ (magicImmune or (not IsUnitType(w, UNIT_TYPE_MAGIC_IMMUNE))) then
              call UnitDamageTarget(source, w, damage, true, false, atkType, dmgType, null)
          endif
      call GroupRemoveUnit(h, w)
  endloop

  
  
• Same point applies once more for the function UnitDamageCone(unit source, ...).

Crowd Control library:

• These are quite minor, so feel free to implement changes how you see fit.
  
  
• In the static method CrowdControl.onEvent(integer key), the nested loop inside the if-then block can be moved outside, to reduce the number of indentations.
  
  

  private static method onEvent takes integer key returns nothing
      local integer i = 0
      local integer next = -1
      local integer prev = -2
      set count = count + 1
      if count - CROWD_CONTROL_KNOCKUP >= RECURSION_LIMIT then
          set count = count - 1
          set .key = key
      endif
      loop
          exitwhen type[key] == next or (i - CROWD_CONTROL_KNOCKUP > RECURSION_LIMIT)
          set next = type[key]
     
          // The following block below might appear to be a messy implementation of a continue statement, because it is.
          // The inner loop's presence will guarantee that control will be restored to the outer loop upon exiting.
          loop
              if event[next] != null then
                  call TriggerEvaluate(event[next])
              endif
              if type[key] != next then
                  set i = i + 1
                  exitwhen true
              endif
              exitwhen next == prev
             
              call TriggerEvaluate(trigger)
              if type[key] != next then
                  set i = i + 1
                  set prev = next
              endif
              exitwhen true
          endloop
      endloop
      set count = count - 1
      set .key = key
  endmethod

Status:

• Approved

Version Reviewed:

• 1.0

 

[Kakerate]

Haven't looked in the testmap yet, but does the tenacity apply to all of those debuff types? Is the offset a way of of specifying tenacity for a certain debuff type?

 

[Tal'Rarity]

Is it possible to modify this in order for it to work on older patches without losing too many features?

 

[Pyrogasm]

Generally, no. This system heavily relies on using call BlzSetAbilityRealLevelField(ability, ABILITY_RLF_DURATION_HERO, 0, duration) to modify the duration of CC-applying abilities right before a dummy unit casts them. The alternative would require running a bunch of timers to manually remove the buff after its appropriate duration, which is a lot more work.

You could go back as far as 1.30 when they were introduced (I believe that's the patch).

 

[Tal'Rarity]

Generally, no. This system heavily relies on using call BlzSetAbilityRealLevelField(ability, ABILITY_RLF_DURATION_HERO, 0, duration) to modify the duration of CC-applying abilities right before a dummy unit casts them. The alternative would require running a bunch of timers to manually remove the buff after its appropriate duration, which is a lot more work.

You could go back as far as 1.30 when they were introduced (I believe that's the patch).

Wouldn't infinite duration along with timers as you mentioned do about the same thing?

 

[Pyrogasm]

Yes... but it requires either running a timer for every instance of CC or putting all the instances of all CC into a big list that a single timer iterates over. And making sure that additional CC of the same type doesn't get removed early by another timer expiring before the subsequent one has finished (when the buff should be removed). It's not complicated, it just fundamentally changes how this system is designed. The beauty of using buffs and the same static cc-applying abilities is that the stacking and removal stuff is taken care of for you without having to do any of that.

 

[BoatyMcBoatface300]

Is it possible to modify this in order for it to work on older patches without losing too many features?

Only method I can think of that wont be pretty but will be handled internally without using timers, so it wont run into the issues pyro said, is using the same abilities but with many, many levels for the duration.

 

[darkravenbest]

Hello, i have an issue when try to use examples from this system along with JASS GUI version of relativistic missiles. It shows error when compile which states following:
"Member name already in use by a parent type."
It point at "private onFinish method" in the case in thunderbolt trigger.
And then point at onFinish metond in the "Missiles struct "in "Missiles" library, as "First time used here".
This problem is absent in Tenacity example map, where used, as it seems, different version of Missiles system, preharps non GUI JASS, but how i can fix this incompatibility with GUI version?

 

[Ricola3D]

Hello !

Nice system.
Does "knockback" knocks wards or units with "UnitPropWindow" equal to 0 ? Or skips them ?

Edit: I just realized that W3 doesn't allow to check if a unit is a ward or not. What a shame :S

 

[Bribe]

Hello !

Nice system.
Does "knockback" knocks wards or units with "UnitPropWindow" equal to 0 ? Or skips them ?

Edit: I just realized that W3 doesn't allow to check if a unit is a ward or not. What a shame :S

They might either have a movement speed of 0 or may not even have the 'Amov' ability at all. Try checking for those; you will likely find either option viable.

 

[Uncle]

Hello !

Nice system.
Does "knockback" knocks wards or units with "UnitPropWindow" equal to 0 ? Or skips them ?

Edit: I just realized that W3 doesn't allow to check if a unit is a ward or not. What a shame :S

There's like 5 wards in Warcraft 3 by default. It wouldn't be too difficult to give each of them a hidden passive ability that you can then check in your Conditions. These pseudo classifications are very easy to work with:

• Conditions
  • (Level of Ward (Class) for Knockback_Target) Equal to 0