You don't need to use/have the count to set it to 0. Once this is done, the weapon will disappear, but like I said it may reappear at new round. Take a look at my plugin to check what I did.
set_pdata_int( ent , m_iCount , 0 , XoCArmoury )
Also not sure but the player is touching the ent so it may get picked up before it is set to 0 so this may be a bad idea. Just kill the entity. Maybe set to 0 then return PLUGIN_HANDLED?
Ok i will do it .. but after a while, now i'm preparing to go back in my country so i will be busy some days .. so will took a while until i will try again but i will firstrly check your armoury manager, it may give me a new look about armoury_entity
Not all the weapons are WeaponBox, weapons wich you can already find on the floor ( like weapons from fy_snow, iceworld, buzzkill, etc .. ) are not weaponsbox, they are armoury_entity and set_pev cannot delete them, however , let me test your code before i'm talking.
Edit: Yes is not working, i have problems removing/blocking drop armoury_entity, as you see in the code you've posted, even Arkshine separe them because he know he can't remove them using set_pev nextthink. .... however i will look in bugsy code is ok man
Also you call 2 times plugin_init but i know they are two separate plugins so it is ok
Not all the weapons are WeaponBox, weapons wich you can already find on the floor ( like weapons from fy_snow, iceworld, buzzkill, etc .. ) are not weaponsbox, they are armoury_entity and set_pev cannot delete them, however , let me test your code before i'm talking.
Sure you can't delete armoury enentities by forcing think, that's not how they work. It works for weaponbox, because it's think function is set to Kill and is delayed by 300 seconds.
When think is enforced the 300.0 "countdown" is overriden and the Kill function is executed immediately.
To keep it short, as Bugsy said, when you pickup an armoury_entity a weapon entity is created and given to player. After drop, that weapon is packed inside weaponbox.
I never told you that you can't remove them with EngFunc_RemoveEntity, what I said is:
Quote:
If you want to remove an armoury_entity, you should not actually delete the entity. This entities are a bit special, if you remove them they won't respawn the next round again and this is the issue if cvar is changed or key is removed.
What I mean is:
1. cspum_type is 1, armoury_entity is removed
2. cspum_type is set to 2 after some time, but the removed entities will remain removed. IMO you should allow them to respawn next round. If you don't want that, simply calling EngFunc_RemoveEntity will do the job. Otherwise, use that:
Inside ArmouryTouch there is a check for m_iCount offset, and if you set it to 0 in TouchPre I don't think there will be any kind of issue. Basically, if it's 0 the function will do nothing.
Just block picking them up then...
The code that forbids players to pick them up should work perfectly ( i use it on zombie plague to forbid zombies picking up armor )
I should have provided this earlier, though you may have found it in my Armoury Manager plugin. The value returned by m_iType is not the CSW_ weapon constant that you may have expected. Use the below enum to determine weapon type based on the returned m_iType value. I also provided code for how to delete/restore armoury_entity's.
To get the CSW_ index of a m_iType value, use g_ArmouryTypes[ (m_iType value) ][ WeaponIndex ]
I did the armoury_entity work and some code cleanup for you.. I added comments where I did everything, please review to see what I did and ask if you have any questions.
Something you should try to avoid is using magic numbers in your code, such is if ( cvar == 1 ), if ( iWeaponType == 0 ) etc. When other people look at your code, they do not have a clue as to what these values mean without reviewing other parts of your code. Instead, define an enum that holds all possible values and name them something that makes sense to others. This is something I did in your code.
I would also prefer the weapons to be stored in a bitsum using a single vault entry. Using an entry for each with the weapon name as key and a "1" for the value works, but it is less efficient. String comparisons and multiple nvault reads versus a single nvault read and a bitwise AND.
The way the armoury_entity handling works is when you add an armoury to the block list and they are touched (with cvar=1), the count is set to 0 and they disappear. When this weapon is removed from the block list or the block list is cleared, the armoury entity will re-appear in its original location and can be picked up.
Added GetWeaponIndex() function to get the weapon index based on keyword. It will return GWI_Duplicate on duplicate, GWI_NotFound on no matching weapon found. On successful find it will return the weapon index.
//Define constants for the touch forward so you know which weapon type was touched. Cleaner than
//assigning a 1 for weaponbox and armoury.
enum WeaponTypes
{
WT_Weaponbox,
WT_Armoury,
WT_Shield
}
//Define the cvar cspum_type values so the code makes more sense than using '1' or '2' and having to
//remember what action each corresponds to.
enum BlockType
{
BT_Remove = 1,
BT_BlockPickup
}
switch ( iFoundIndex )
{
case GWI_NotFound:
{
client_print( id , print_console, "Unable to find the key '%s', type amx_cspum_keylist for all keys available to insert." , szWeaponArg );
return PLUGIN_HANDLED;
}
case GWI_Duplicate:
{
client_print( id , print_console, "Duplicate weapons were found. Please be more specific with the weapon you want to add." , szWeaponArg );
return PLUGIN_HANDLED;
}
default:
{
if ( gBlockWeapons & ( 1 << iFoundIndex ) )
{
client_print( id , print_console , "'%s' is already saved in the pick up manager list." , gKeyList[ iFoundIndex ] );
return PLUGIN_HANDLED;
}
}
}
//Replaced iWeaponType variable with wtType. This way, wtType gets assigned a constant for the weapon type
//that it is. It makes more sense for people looking at your code to see the actual weapon type instead of
//1=armoury/weaponbox and 0=shield.
if ( iWeaponID && ( gBlockWeapons & ( 1 << iWeaponID ) ) )
{
//Eliminated variable for the cvar value. Since the value is used only once, psas it
//directly into the switch.
switch( get_pcvar_num( giTypeCvar ) )
{
//Replaced magic numbers with constants so it's easier to understand what is going on.
case BT_Remove:
{
switch ( wtType )
{
//Added handling for armoury. Set count to 0 to make it disappear and set
//SOLID_NOT flag so no subsequent touches will occur.
case WT_Armoury:
{
set_pdata_int( ent , m_iCount , 0 , XoCArmoury );
set_pev( ent , pev_solid , SOLID_NOT );
}
case WT_Weaponbox:
{
call_think( ent );
}
case WT_Shield:
{
engfunc( EngFunc_RemoveEntity, ent );
}
}
}
case BT_BlockPickup:
{
return PLUGIN_HANDLED;
}
default:
{
return PLUGIN_CONTINUE;
}
}
}
return PLUGIN_CONTINUE;
}
cs_get_weaponbox_type( iWeaponBox )
{
new iWeapon
new const m_rgpPlayerItems_CWeaponBox[ 6 ] = { 34 , 35 , ... };
for ( new i = 1 ; i <= 5 ; i++ )
{
if( ( iWeapon = get_pdata_cbase( iWeaponBox , m_rgpPlayerItems_CWeaponBox[ i ] , XoCArmoury ) ) > 0 )
{
return cs_get_weapon_id( iWeapon )
}
}
return 0
}
GetWeaponIndex( const szKeyword[] )
{
new iFound = GWI_NotFound;
Amazing work bugsy, now it works perfect .. just one small problem i have been observed :
if i write amx_cspum_addkey 'x' or 'e' or 'u' they will be saved, output:
Quote:
] amx_cspum_addkey r
You successfully added 'r' to the list!
] amx_cspum_addkey u
You successfully added 'u' to the list!
] amx_cspum_addkey p
You successfully added 'p' to the list!
] amx_cspum_addkey p
This key is already saved in the pick up manager list.
] amx_cspum_addkey l
You successfully added 'l' to the list!
Anyway, thats being not my original problem so i should solve by myself, but thanks everybody for their time and effort! Hamlet and Bugsy <3
# Also bugsy, can you please next time post codes with [code] Tag and [spoiler] because now i need to re-indent all the code, because [php] tag broke them, anyway will not take to much time but thanks fi you take in consideration <3 <3 )
but i know they are two separate plugins so it is ok 
Linear Mode
