WeaponID

[Kami]

Hello guys,

if been reworking a restriction system I made and I used this hook to determine which weapon was bought:

Syntax: Select all

@EntityPreHook(EntityCondition.is_player, 'buy_internal')
def pre_buy(args):
    """Called when a player is about to buy something."""
    # Get a PlayerEntity object from the pointer passed
    player = Player(index_from_pointer(args[0]))
    userid = player.userid
    
    # Get the weapon name the player is about to buy
     weapon = 'weapon_'+args[1]

The problem is that args[1] does no longer return a weapons name but rather a number. I looked for the WeaponID constants and when I printed args[1] I found that the numbers did not match. AK47 for example is defined as 27 in the constants but when I buy it it prints 15. AWP is defined as 17 but prints 18 for me.

The question is if the data is outdated or if I'm doing something wrong.

Thank you :)

[satoon101]

In case you are unaware, SP has a restriction system you can either use directly or inherit from:
https://github.com/Source-Python-Dev-Te ... ictions.py

Also, which game is this for? If it's for CS:GO, the name should be in the 3rd position:
https://github.com/Source-Python-Dev-Te ... ns.py#L402

*Edit: I guess I missed the "TODO" right above in the last link I gave. Hmmm...we'll have to figure out what that number means, because for my limited testing just now, the 3rd parameter is always an empty string. The integer in the 2nd parameter seems to be consistent, but I'll have to do more testing to verify. That number does not correspond to the ItemDefinitionIndex, unfortunately.

[Kami]

Thank you for your answer. I am aware that there is already a restrictions system provided by Source Python, I'm just trying to figure out myself how to do certain things and how they work^^

I tried printing args[2]:

Syntax: Select all

@EntityPreHook(EntityCondition.is_player, 'buy_internal')
def pre_buy(args):
    """Called when a player is about to buy something."""
    # Get a PlayerEntity object from the pointer passed
    player = Player(index_from_pointer(args[0]))
    userid = player.userid
    if userid not in restrictions:
        restrictions[userid] = ""
    
    # Get the weapon name the player is about to buy
    core.console_message("Weapon: "+args[2])

but it does not print anything after "Weapon: ", so it seems args[2] is empty

[satoon101]

Yeah, I edited my post right before you posted. The only parameter that seems useful is the 2nd one (integer), but it seems to be the same for USP-S and P2000, so I'm really not sure at the moment what to do.

[Kami]

So in order to get the restrictions to work I'd have to go through all weapons and write the number down, right?

Also, when I tried using the source python restrictions i get this error:



When I looked through the restrictions.py I could only find the line where it creates the dict, but not where it adds the player to it. Not sure if thats needed here though. I'm a bit confused sorry :D

[satoon101]

Well, again, even writing all the numbers down won't fully help. The same integer was given in my testing for USP-S and P2000, which are based on player inventory preferences.

As for your error, you likely overwrite the __init__ method and don't call super().__init__, since it says it has no attribute "player_restrictions".

[Kami]

Okay, I found the error, I used WeaponRestrictionHandler not WeaponRestrictionHandler().

Even though buying the weapon cannot be prevented I think that's just a minor problem, as the other parts of restricting still seem to work.

Thank you for helping me out :)

€: Also the number seems to be the slot number on the buy menu. like the pistols go from 1 - 5 then mps 8 -12 and so on. I doubt you can read info from that slot that leads to what weapon exactly the user has equipped, without accessing the inventory info and checking which weapon he has in that slot.

[satoon101]

Okay, I found the error, I used WeaponRestrictionHandler not WeaponRestrictionHandler().

Ah, yeah, that would do it, as well. Although, you should only have one instance of the handler instead of constantly creating them. I would suggest creating 1 instance in the global scope and then using that instance to add/remove restrictions.

[Kami]

I just did a test with SourceMod, and it seems that they figured out how to to this. I tried to go through the source code but I could not figure out exactly how. Maybe more experienced people can do it! :)

[L'In20Cible]

The question is if the data is outdated or if I'm doing something wrong.

Probably is. The bastards at VALVe are changing weapons stuff daily for CS:GO.

[BackRaw]

Kinda OT question: Nothing to do with weapon restrictions but the buy command. An entity pre hook on buy_internal as well as the client command buy all return "unused" as the weapon name (SP build #666) - only tested on CSGO. I'm sorry if this has already been pointed out, but I can't find anything on the forums. Is this issue known?

[satoon101]

I'm not sure where you are seeing "unused", but as noted in the discussion above, it is messed up in CS:GO. Right now, the buy_internal hook yields values similar to the following:

Syntax: Select all

(<_memory.Pointer object at 0x1BEC4710>, 15, '', True)

The first argument is the Player. The third used to be where the item name was, but that changed more than a year ago now. It now passes the integer as the second argument. Unfortunately, depending on the player's personal inventory choices, the weapon there is not necessarily exclusive to 1 type. For instance, USP-S and P2000 will give the same value for that argument, so it's difficult to know which one it's "supposed" to be. I'm not even sure we have a way of checking the player's inventory to know which weapon to check against, at least not 'easily'.

[BackRaw]

I'm not sure where you are seeing "unused", but as noted in the discussion above, it is messed up in CS:GO. Right now, the buy_internal hook yields values similar to the following:

Syntax: Select all

(<_memory.Pointer object at 0x1BEC4710>, 15, '', True)

Sorry, my memory was faulty. For the hook the empty string is returned and for the client command "unused" is returned.

The first argument is the Player. The third used to be where the item name was, but that changed more than a year ago now. It now passes the integer as the second argument. Unfortunately, depending on the player's personal inventory choices, the weapon there is not necessarily exclusive to 1 type. For instance, USP-S and P2000 will give the same value for that argument, so it's difficult to know which one it's "supposed" to be. I'm not even sure we have a way of checking the player's inventory to know which weapon to check against, at least not 'easily'.

Thanks for clearing that up. I didn't know this has been the way for a year now. So basically at the moment any buy hook (entity or client command) won't return the correct weapon the player is about to buy and there's no fix for it in the foreseeable future?

[Ayuto]

It's possible to get the weapon. This is how the SM guys did it:
https://github.com/alliedmodders/source ... /659/files

[BackRaw]

It's possible to get the weapon. This is how the SM guys did it:
https://github.com/alliedmodders/source ... /659/files

Nice! Time to study then? :D

[Ayuto]

I know what's happening there, but never found the motivation/time to add it to SP.