GetPrimaryAttribute v2.1 (GUI)

[MyPad]

I would suggest a slightly-more elegant approach, involving the unit's base damage, though it relies on the gameplay constant Damage Bonus per Attribute not being equal to 0, while the native GetHeroPrimaryAttribute has not been publicly exposed. (This is based on the common.j file in 1.30.1)

Before performing a check, let's make sure that the unit is a Hero. If not, return a default null expression of your choice.
If the unit's type's primary stat attribute has already been obtained, just return the result from it. Otherwise, get the unit's base damage from both indices (do not assume that only 1 will ever be used). Store those, because we'll need it later.

Now, we temporarily increment the Strength of the Hero by 1. If the current base damage is not equal to the previously stored base damage, we flag that as the main attribute. Then, with or without Strength being the main attribute, we decrement the Strength of the Hero by 1 (to counteract the addition operation earlier). Repeat with Agility and Intelligence.

Once we get the appropriate stat attribute, we then store it in a hashtable, and return the value.

 

[TriggerHappy]

The unexposed BlzGetHeroPrimaryStat native works.

Warcraft III - Patch 1.29 PTR

 

[El Saif]

The unexposed BlzGetHeroPrimaryStat native works.

Warcraft III - Patch 1.29 PTR

Really? i just realize it by now.

 

[Wrda]

Well, rip.
This could actually have been a potential resource.
Looks like blizzard is one step ahead on natives

 

[MyPad]

For a previous version

This would have been a potentially good resource, even as a snippet. Sadly, this would require manually implementing the flags on the scale that goes up the more Heroes you have, which can be quite heavy for some. There is also the potential for it to bug when a Hero transforms into another Hero, and back.

The ability to translate the values into something more readable is very much appreciated in this resource, as it would have made those using this understand their triggers better.

As functional as it may be, the reasons above would prevent it from being approved.

Status:

• Substandard

 

[MyPad]

Snippet Review:

Notes:

• In function PrimaryStatCondition within trigger PrimaryStat, the condition can be simplified so that it would only require a single line.
  
  

      return IsUnitType(udg_GetHeroUnit, UNIT_TYPE_HERO)

  
  
• In function CreatePrimaryStatEnd within trigger PrimaryStat, you leak a triggeraction, since the invocation of DestroyTrigger does not destroy triggeractions associated with it. Two solutions are possible, do not destroy the trigger, (recreate if trigger was manually destroyed, or convert the line, adding a triggeraction into a triggercondition.

Status:

• Pending

 

[El Saif]

Hmm, sorry. It is okay if i do it like this? within ResetActions or CreatePrimaryStatEnd?
Link : I've got a function I want delted after its called, how?

Or just remove the DestroyTrigger()? which is better?

 

[MyPad]

I'd say remove the DestroyTrigger call, since all the trigger does is invoke ResetActions, which would completely nullify all relevant data related to the Hero unit, and destroy the listening trigger, which would mean that you'll have to recreate the trigger again.

For that to happen, you must create the trigger on the init function, and leave it be. Add a warning to users so that they don't accidentally destroy that.

 

[El Saif]

I'd say remove the DestroyTrigger call, since all the trigger does is invoke ResetActions, which would completely nullify all relevant data related to the Hero unit, and destroy the listening trigger, which would mean that you'll have to recreate the trigger again.

For that to happen, you must create the trigger on the init function, and leave it be. Add a warning to users so that they don't accidentally destroy that.

Ah, ok.

EDIT :

Updated to v2.1.

 

[Dr Super Good]

I am of mixed opinions about the usefulness of this. In 1.31 PTR it is fairly easy to use the new natives to look up the primary attribute of a hero unit. However that is still a PTR.

 

[El Saif]

I am of mixed opinions about the usefulness of this. In 1.31 PTR it is fairly easy to use the new natives to look up the primary attribute of a hero unit. However that is still a PTR.

Well, maybe that's why i won't updates this resource again. You can reject it after the new patch updated.

 

[Dr Super Good]

Comment:

Although some people may find this useful it is important to note that it relies on unexposed natives functions (as of 1.30.4). Now these might be exposed in future patches but they might also be completely removed which could cause compatibility issues. As such I cannot really recommend people use this.

In the upcoming 1.31 patch there are likely other fully exposed approaches one could use to resolve the hero primary attribute.

The JASS coding quality itself is also a bit lacking. I do not see the purpose PrimaryStatEnd serves seeing how if the unit fed to PrimaryStat is not a hero it could implicitly reset resulting in a simpler API.

​