[Chdata]

Useful for anyone modding weapons or anything related to them.

This should also work for weapons with custom attributes and custom spawned weapons.

Anyway, TF2 doesn't seem to have a netprop or datamap for a weapon's max clip/ammo, meaning you have to use an SDKCall to GetMaxAmmo / GetMaxClip1 to get it. Maybe there's hidden ones really, but yeah.

It also properly accounts for mult_clip_size. I believe it returns -1 for energy weapons though. m_iClip1 will be -1 for energy weapons anyway. (Such as the Cow Mangler).

I also threw in GetDefaultClip (whatever that is) and GetSlot.

And well... see the attached files!

Oh, I only set it up for Linux/Mac, because I'm lazy.

[Powerlord]

Weapons have a virtual function that can be called to get this information, but Bacardi was saying it doesn't work on TF2 or CS:GO... maybe because they're CEconItems and not standard weapons.

[Chdata]

I thought of that too, but this is less work and easier.

Also now that I think of it... wow those GetWeaponX functions must be old.

But I'm not sure, how would one rewrite those exactly?

I think GetWeaponClip would just be

PHP Code:

stock GetWeaponClip(weapon)
{
    if (IsValidEntity(weapon))
    {
        return GetEntProp(weapon, Prop_Send, "m_iClip1");
    }
    return 0;
} 


[Powerlord]

To be honest, after doing a bit of research, it's a bit of a pain to check ammo levels using methods. Hell, you'd need a signature to call CAmmDef::MaxCarry as it has no entity.

Incidentally, why would you need a TF2Items callback to get accurate numbers? Doesn't the post_inventory_application event fire after a player is given a new inventory? You could just iterate over their item slots then.

[psychonic]

Originally Posted by Chdata Anyway, TF2 doesn't seem to have a netprop or datamap for a weapon's max clip/ammo, meaning you have to get their 'current' clip/ammo...

As Powerlord mentioned, there are virtual methods for this on the weapon itself. They exist in every game and it would be a good candidate of something to be added to SDKTools as it also handles any game-specific logic rather than just reading the weapon script. Additionally, default ammo/clip is not guaranteed to be the max.

There are multiple other issues here as well.

Originally Posted by Chdata #define TF_MAX_PLAYERS 34

There isn't much of a reason to not uses (MAXPLAYERS + 1) here instead of making your own define. Srcds already has a much higher memory variance than the 1.5kb you're saving with this. Additionally, if other people try to do the same, the define could conflict with another, or even be defined differently in the case of someone doing the same, but having it as 33 and then doing a +1.

Originally Posted by Chdata new iOffset = GetEntProp(weapon, Prop_Send, "m_iPrimaryAmmoType", 1)*4; new iAmmoTable = FindSendPropInfo("CTFPlayer", "m_iAmmo"); return GetEntData(owner, iAmmoTable+iOffset, 4);

Originally Posted by Chdata new AmmoClipTable = FindSendPropInfo("CTFWeaponBase", "m_iClip1"); return GetEntData(weapon, AmmoClipTable);

GetEntProp should be used, else cache is being bypassed and for extra complication of code.

Originally Posted by Chdata if (!IsValidEnt(iWeapon) || !GetEdictClassname(iWeapon, szClassname, sizeof(szClassname)))

This is checking whether it's a valid entity, but then getting the edict classname. Not all entities have edicts. GetEntityClassname or IsValidEdict would be more appropriate.

Originally Posted by Chdata stock bool:IsValidEnt(iEnt)

This is ambiguously named and requires extra effort to figure out what the difference between IsValidEntity and IsValidEnt are.

[Powerlord]

Originally Posted by psychonic GetEntProp should be used, else cache is being bypassed and for extra complication of code.

To add to this, GetEntProp's size and element values for m_iAmmo would be 4 and iOffset respectively. The 4 doesn't even need to be set as GetEntProp can figure it out on its own.

[Chdata]

Originally Posted by Powerlord To be honest, after doing a bit of research, it's a bit of a pain to check ammo levels using methods. Hell, you'd need a signature to call CAmmDef::MaxCarry as it has no entity. Incidentally, why would you need a TF2Items callback to get accurate numbers? Doesn't the post_inventory_application event fire after a player is given a new inventory? You could just iterate over their item slots then.

Hm, I used to use post_inventory_application but had problems. I ought to test it again.

and isvalident is something I mostly use privately, usually I edit that out of public things, dunno why I didn't here

So...

PHP Code:

stock GetWeaponAmmo(weapon)
{
    new owner = GetEntPropEnt(weapon, Prop_Send, "m_hOwnerEntity");
    if (owner == -1) return 0;
    if (IsValidEntity(weapon))
    {
        new iOffset = GetEntProp(weapon, Prop_Send, "m_iPrimaryAmmoType", 1);
        return GetEntProp(owner, Prop_Send, "m_iAmmo", _, iOffset);
    }
    return 0;
}] 


I'd make an sdkcall but i'm too lazy.

Originally Posted by Powerlord The 4 doesn't even need to be set as GetEntProp can figure it out on its own.

What exactly does "GetEntProp" do to "figure it out"? I see it has a default value of 4 for the size, but I don't see anything like sizeof(int) or something.

[Chdata]

edit: Gonna update this soon with some sdkcalls

[Powerlord]

Originally Posted by Chdata What exactly does "GetEntProp" do to "figure it out"? I see it has a default value of 4 for the size, but I don't see anything like sizeof(int) or something.

Whoops, I missed this last month.

If you check a netprops / datamaps list, you'll notice that it includes the number of bits each thing takes up. That's because the SendProp class (which is what netprops are) stores this information¹. I'm assuming the DataMap equivalent does as well.

¹Unless it's a CUtlVector SendProp or one of its direct children. These are really a wrapper around a CUtlVector object on the server side and not an actual number/string property.

[psychonic]

Originally Posted by Powerlord If you check a netprops / datamaps list, you'll notice that it includes the number of bits each thing takes up. That's because the SendProp class (which is what netprops are) stores this information1. I'm assuming the DataMap equivalent does as well.

Both store a data type (int, float, etc.), and SendProps also store a count of bits to be networked.