[Chdata]

So I have two questions:

How may I change an item's name upon giving a player a weapon?

With SpawnWeapon(); I can't just use attribute...

PHP Code:

        "2024"
        {
            "name"                    "item name text override"
            "attribute_class"        "item_name_text_override"
            "attribute_type"        "string"
            "hidden"                "1"
        } 


Because the attribute string is... a string and putting "2024 ; "ItemName"" doesn't make any sense at all.

Secondly, how can I add an attribute to a player's existing weapon? For example, depending on the player's disguise, I want to add the airdash attribute to their weapons (triple jump) and remove it otherwise. Would I really have to just remove their weapon, and SpawnWeapon again or can I append the attribute in some way?

[Velture]

It's for australium weapon name.

[Oshizu]

FlaminSarge managed to use this attribute somehow
http://steamcommunity.com/sharedfile.../?id=202838853

For me it crashes player who looks / sees / tries to see name of the item

[Velture]

Same for me. Anyone who tried to see my item have had a tf2 crash.

[wgooch]

The bottom line with string attributes is that they cannot safely be changed or added by the server.
String attribute values are actually pointers to a CAttribute_String object that stores information on the string. This object is created on both the server and the client separately and is never directly networked by the server meaning that the client has to create the string in the end.
While you can create the attribute on the server and network it to a client, you're always going to end up creating a pointer to some random piece of memory on the client which will result in undefined behavior, and generally crashes on the client.

In the end the best the server can do with string attributes is read them, or remove them entirely by preventing iteration of the SOCData attributes on an item.

This bit of C++ code should allow you to safely READ the data from a string attribute.

// CAttribute_String structure
class CAttribute_String
{
private:
    char padding[12];
    const char **m_pStr;
public:
    const char *GetString();
    void SetString(const char* pString);
};

// Get string
const char *CAttribute_String::GetString()
{
    return *m_pStr;
}

// Set string - UNSAFE
void CAttribute_String::SetString(const char *pString)
{
    m_pStr = &pString;
}

void SomeFunction( CEconItemView *pItemView )
{
    if( !pItemView )
        return;

    CEconItem *pSOCData = pItemView->GetSOCData();

    // Ensure SOCData exists
    if ( !pSOCData || pSOCData->m_pCustomData )
        return;

    CEconItemCustomData *pCustomData = pSOCData->m_pCustomData;

    // Iterate attributes
    for ( int i = 0; i < pCustomData->m_Attributes.Count(); i++ )
    {
        attribute_t *pAttribute = &pCustomData->m_Attributes[i];

        // Is this a custom name attribute?
        if ( pAttribute->m_unDefinitionIndex == 500 )
        {
            CAttribute_String *pStringAttribute = pAttribute->m_value.asString;

            // Print item's custom name to the server
            Msg( "Item %d has the name %s\n", 
                pItemView->m_iItemID,
                pStringAttribute->GetString() );
        }
    }
}

[Velture]

Dude I'm so high right now that I have no idea what you nigga is talkimg about..... It took me like 5 minuter to write whis shit..... Flaming sarge has the best dope!

[napalm00]

Originally Posted by wgooch -snip-

Epic explanation sir, to you!

[FlaminSarge]

There's several string attributes that kinda allow you to set the strings involved: the "additional halloween response criteria name" and "taunt success sound" ones. The halloween one is only used by the server and so it should be (relatively) safe to mess with. The taunt one works by performing an EmitSound with the specified string, so the server ends up sending the string to the client (the same way any other sound is emitted).
Now, if you attempt to edit any of these, you may end up stepping outside the area allocated for these strings, so ideally for these you would create a new CAttribute_String with the proper amount of memory allocated, as well as allocate a decent amount of memory for the actual string. (There's some additional stuff going on when it's a pyrovision-only sound such as for the Infernal Orchestrina, so... careful).

In other news, my Boston Boom-Bringer now shouts "IS EVERYONE READY" whenever I taunt.

[wgooch]

I was unaware that there were attributes used solely by the server. You're right, in the case of those it would be safe to change them assuming the client is never given the opportunity to read them. CAttribute_String points to a zero terminated string so you should be able to safely go over the original length of the string just by allocating space for the string value itself, not an entirely CAttribute_String object. I would actually advise against attempting to create a whole new CAttribute_String object unless you have the entire structure devoid of any padding, and if you do, please do share. It is possible that CAttribute_String has a length value that will prevent it from attempting to read past a certain point, and this would prevent you from being able to go over the original string length without modifying it.

[FlaminSarge]

The only thing I'm worried about is how the Infernal Orchestrina emits noise only to players using Pyrovision. If the CAttribute_String has some property that affects that, then we ought to know that as well before messing with it. After all, the behavior I discovered for strings greater than 15 characters is really strange:
Let's say strpt = *(CAttribute_String+12);
If the string is less than 16 characters (I'm not sure if null is included at this point), then strpt is the location of the string. However, at greater than 16 characters, the string is moved elsewhere, and strpt holds the address of the string.
strpt+16 holds the number of characters (excluding null terminator) in the string. strpt+20 holds either the values 15 or 31; if 31, strpt is treated as a pointer to the string, and if 15, strpt is treated as the location of the string.

These are the only things I could find out about it, and they're empirical, so I don't know much else (I tested using the items that add halloween response contexts and taunt success sounds). The address of the >15char strings I was testing on was always strpt+40, but it used the full address value instead of a relative value, so I guess it could be anywhere.

However, editing the string at the address did properly change the sound played on taunt, and seemed to modify the context rules added. Of course, since the attribute value for a particular string is the same for all players, it modified it for all players, not just one.