player_weapons_update2: weapon.clip returns 255 for weapon_knife on CS:GO

[KirillMysnik]

The problem is that CS:GO uses get_property_uchar/set_property_uchar for getting/setting ammo and clips.

So the following code in player_weapons_update2 does not work:

    def get_clip(self):
        """Return the amount of ammo in the weapon's clip."""
        return self.clip if self.clip != -1 else 0

    def set_clip(self, value):
        """Set the amount of ammo in the weapon's clip."""
        # Does the weapon have ammo?
        if self.clip != -1:

            # Set the clip amount
            self.clip = value

As self.clip always returns 255.

Edit: possible solution might be using

return self.clip if self.clip % 256 != 255 else 0

[KirillMysnik]

A little update on the issue message: ammo is specifically ushort property in CS:GO, not uchar. That's true for grenades, as for other weapons .primary_ammo_count is used instead.

[satoon101]

It's the same for weapon_c4 in CS:GO, as well. In CS:S, it returns 30 for weapon_c4. Maybe we should utilize the weapon data we store for verifying if a weapon has ammo/clip values.

    def _validate_clip(self):
        """Test if the weapon has a clip."""
        if (
            self.classname in weapon_manager and
            weapon_manager[self.classname].clip is None
        ) or self._clip == -1:
            raise ValueError('Weapon does not have a clip.')

    def _validate_ammo(self):
        """Test if the weapon has a valid ammoprop and an owner."""
        if (
            self.classname in weapon_manager and
            weapon_manager[self.classname].ammoprop is None
        ) or self.ammoprop == -1:
            raise ValueError(
                'Unable to get ammoprop for {weapon}'.format(
                    weapon=self.classname
                )
            )

This, of course, will require us to change the default for clip to None instead of 0, which is probably the right thing to do anyway.

[satoon101]

This is implemented in 6559950. I forgot to reference this issue in the commit message. Please test this out and post your thoughts.

[jordanbriere]

I don't necessary think we should store that ourself when we can access it from their WeaponInfo instance. Testing for ammo could simply be done using:

if not weapon_scripts[self.classname].primary_ammo_type:
    raise

Actually, a lot of the value we store are redundant - slot, clip and cost, for example are all accessible from their WeaponInfo as slot_index, default_primary/secondary_clip and price respectively. Those values are modifiable, as well (for everything that is not handled/predicted client-side).

[KirillMysnik]

Sorry for the delay.
I've just tested and Satoon's fix works fine. Exception is raised for weapon_knife and weapon_c4.

My only thought is maybe make _validate_clip / _validate_ammo public so that scripters can check if the clip is available without the need to call get_clip and catch the exceptions? Or implement something like has_clip, has_ammo that would simply return a boolean value.

[satoon101]

@invincibleqc - I will try to work on that this weekend. I originally tried to do that a while back, but the WeaponInfo for CS:GO was broken, so I decided to just use the data as we have stored it.

@KirillMysnik - Thank you for testing. I definitely like that suggestion. I'll get that implemented this weekend unless you have time and want to create a pull request.

[satoon101]

To clarify, I meant adding has_clip and has_ammo, not making the validation public.

[satoon101]

@invincibleqc - Started working on implementing the weapon_scripts. weapon_scripts[self.classname].primary_ammo_type shows as 0 for all weapons in CS:S. They do, however, have proper values for primary_ammo_name. Which, unfortunately, is not an attribute used in CS:GO. Continued testing with other games only shows more caveats. I think using our stored data will probably be the best all-encompassing solution.

On a side note, I am having a lot of issues (errors) with sp dump weapon_scripts for CS:GO.

[jordanbriere]

primary_ammo_name is available on CS:GO, just missing in our data. As for the errors, they probably added more members to the CCSWeaponInfo structure. I will work updating and adding the missing ones tomorrow. May also looks to add the structures for other games/engines we support - are the binaries still up-to-date on your DB?

[satoon101]

Sorry, for some reason I did not notice your last question until just now. The binaries were up-to-date a week ago, but I have not updated them since (I think) Tuesday. I will update them here in a couple hours.

[Ayuto]

I guess this can be closed if we continue using our weapon data, right?

[satoon101]

Yes, this should be fixed. If they didn't constantly update the WeaponInfo for CS:GO, I could see that as a viable option.