Re: [TF2] TF2Attributes (v1.0.0, 03/08/2013)
 

Gonna play with this see what fun stuff can be done. Thnx as always for your work

Re: [TF2] TF2Attributes (v1.0.0, 03/08/2013)
 

Some of you may have noticed that certain attributes added to weapons that really take effect on the player, such as "max health additive bonus", don't work when the attribute is added to the weapon. The reason is that the player's attribute manager cache isn't cleared when the weapon's attributes are updated (Valve corrects for this in their own code, calling ClearCache on the player's attributes right after they make calls to add attributes to weapons), and it only updates when they regen/respawn.

So I'm adding TF2Attrib_ClearCache(entity), which would perform ClearCache on an entity's attributes.
Note, however, that Set/Remove/RemoveAll already call ClearCache on the entity that is being added to/removed from (internally), and the only issue is the entity's OWNER (a weapon's player, for instance) not being updated. Thus, should I even add this native, or should I simply clear the attribute cache of m_hOwnerEntity of whatever entity is being used in Set/Remove/RemoveAll?

Long story short, we don't NEED TF2Attrib_ClearCache(entity), and I can simply just call ClearCache on the m_hOwnerEntity of any weapons/wearables passed into Set/Remove/RemoveAll. Should I add the native anyways?

Re: [TF2] TF2Attributes (v1.0.0, 03/08/2013)
 

I don't see why not, it would be useful to most people to minimize their code.

Re: [TF2] TF2Attributes (v1.0.0, 03/08/2013)
 

I'm not entirely sure if I'm understanding what your reply means, but it seems to me like the first half contradicts the second half: "I don't see why not" = "I don't see why you wouldn't add the native"; "it would be useful to most people to minimize their code" = not having the native, but making the automatic owner cache change a built-in part of the plugin would be useful since then plugin authors don't have to do it in their own code.

Which of the two do you mean?

Re: [TF2] TF2Attributes (v1.0.0, 03/08/2013)
 

I'm just saying that it's a good idea to put it in.

Re: [TF2] TF2Attributes (v1.0.0, 03/08/2013)
 

The next update won't be adding the TF2Attrib_ClearCache native, as it's probably just better to call ClearCache on an entity's m_hOwnerEntity whenever add/remove/removeall are called, just to make sure attributes are properly updated each time they're given/removed. As such, it'll just do that call internally (with proper checks) instead of forcing plugin devs to call it whenever they need the attribute manager cache updated.

Re: [TF2] TF2Attributes (v1.0.0, 03/08/2013)
 

Scratch that last bit, ClearCache is sometimes necessary after editing an attribute's value via TF2Attrib_SetValue(), etc., so that native's going to exist.

Side note, DO NOT USE THE RETURN OF TF2Attrib_SetByName(). It's not the address of the created attribute. I botched that. It's some arbitrary other address that seems to be related to the entity or client who got the attribute. It IS, however, nonzero if the attribute creation was successful, so the next update will change that to bool:TF2Attrib_SetByName(). Hopefully I'm not breaking/misaligning anything by using SetReturnInfo when there isn't supposed to be a return (SetOrAddAttributeByName returns void, apparently).

To get the address of an attribute you just created, you'll have to call Get right after Set and hope it grabs the address.

Re: [TF2] TF2Attributes (v1.0.0, 03/08/2013)
 

Should I assume there's no function to set attributes by attribute index rather than by name?

Freak Fortress 2 operates on these not just for boss attributes (and there are hundreds of bosses out now) but also for functions that give new weapons to bosses.

Re: [TF2] TF2Attributes (v1.0.0, 03/08/2013)
 

Yeah, it would be a good thing to add.

Then when I was testing, I did not realize that I needed to put the name of the attribute, not the index.

Re: [TF2] TF2Attributes (v1.0.0, 03/08/2013)
 

Nothing for *cleanly* adding attributes by index rather than name, unfortunately. You could probably wrap something around TF2ItemsInfo for that.

Or I could try constructing CEconItemAttribute in pawn. But apparently that's messy and bad and don't do it.

However, since each attribute index maps to a name, it shouldn't be an issue and should actually make your code more readable than arbitrary numbers would, were you to switch to using this in place of attribs by index.