[ConnorMcLeod]

Originally Posted by meTaLiCroSS Gonna take that in account, thanks again buddy

Also on windows it shows no return, and if you search on linux where the function is called, you can see no value is waited there.
Just set the linux function with no return and things gonna become clear

void __cdecl packPlayerItem(CBasePlayer *pPlayer, CBasePlayerItem *pItem, bool bPackAmmo)
{
  CWeaponBox *pWeaponBox; // esi@4
  entvars_t *pevWeaponBox; // ecx@4
  float flVelocity_Y; // ST40_4@4
  float flVelocity_X; // ST3C_4@4
  float flVelocity_Z; // ST44_4@4
  int v8; // eax@4
  void *v9; // edx@4
  int v10; // ST08_4@5
  char *pszModel; // [sp+18h] [bp-10h]@1

  pszModel = 0;
  if ( pItem )
    pszModel = GetCSModelName(pItem->m_iId);
  if ( pszModel )
  {
    pWeaponBox = CBaseEntity::Create("weaponbox", pPlayer->pev->origin, pPlayer->pev->angles, pPlayer->pev->pContainingEntity);
    LODWORD(pWeaponBox->pev->angles[0]) = 0;
    LODWORD(pWeaponBox->pev->angles[2]) = 0;
    pevWeaponBox = pWeaponBox->pev;
    flVelocity_Y = pPlayer->pev->velocity[1] * 0.75;
    flVelocity_X = pPlayer->pev->velocity[0] * 0.75;
    flVelocity_Z = 0.75 * pPlayer->pev->velocity[2];
    pWeaponBox->pev->velocity[0] = flVelocity_X;
    pevWeaponBox->velocity[1] = flVelocity_Y;
    HIWORD(v8) = HIWORD(flVelocity_Z);
    pevWeaponBox->velocity[2] = flVelocity_Z;
    LOWORD(v8) = 0;
    v9 = g_engfuncs_ptr.pfnFadeClientVolume;
    pWeaponBox->m_pfnThink_Flag = v8 | 0xFFFF0000;
    pWeaponBox->m_pfnThink = v9;
    pWeaponBox->pev->nextthink = gpGlobals->time + 300.0;
    CWeaponBox::PackWeapon(pWeaponBox);
    if ( bPackAmmo )
    {
      v10 = pPlayer->m_rgAmmo[(pItem->vtable->CBasePlayerItem__PrimaryAmmoIndex)(pItem)];
      CWeaponBox::PackAmmo(pWeaponBox, *&CBasePlayerItem::ItemInfoArray[44 * pItem->m_iId + 8] - gpGlobals->pStringBase);
    }
    g_engfuncs.pfnSetModel(pWeaponBox->pev->pContainingEntity, pszModel);
  }
}

[Arkshine]

I won't trust windows too. You should just not look return with IDA. The only valid point is to check where it's called and figuring out if it returns something (checking first HLSDK/Google, of course), and sometimes function could returns something but is not used, so you will need to test with/without at this point.

[meTaLiCroSS]

Originally Posted by Arkshine I won't trust windows too. You should just not look return with IDA. The only valid point is to check where it's called and figuring out if it returns something (checking first HLSDK/Google, of course), and sometimes function could returns something but is not used, so you will need to test with/without at this point.

In this case packPlayerItem supposes to return something, but isn't used, so anyway + your explanation I won't take in care a return for this function

Thanks for the snippet!

[meTaLiCroSS]

Argument type "CBasePlayer *" validated
			Argument type "CBasePlayerItem *" validated
			Argument type "bool" validated
			Searching for name "packPlayerItem__FP11CBasePlayerP15CBasePlayerItemb"... NOT FOUND

And my IDAPro with the cs binaries of my server said:

; Attributes: bp-based frame

; packPlayerItem(CBasePlayer *, CBasePlayerItem *, bool)
packPlayerItem__FP11CBasePlayerP15CBasePlayerItemb proc near

EDIT: Solution found: https://forums.alliedmods.net/showpo...&postcount=986

[ConnorMcLeod]

Did it ever worked ?
When you had the return problem, was it only on windows ?

[meTaLiCroSS]

Originally Posted by ConnorMcLeod Did it ever worked ? When you had the return problem, was it only on windows ?

Well, the return issue wasn't a problem, it was just a question because in the decompiled function I saw that it returned "int", but i've tested it without return and it worked well

Also, don't worry, Arkshine gave me the solution.

{
    "name"      : "packPlayerItem",
    "library"   : "mod",
    "arguments" :
    [
        {
            "type" : "CBasePlayer *"
        },
        {
            "type" : "CBasePlayerItem *"
        },
        {
            "type" : "bool"
        }
    ],
    "identifiers" :
    [
        {
            "os"    : "windows",
            "mod"   : "cstrike",
            "value" : [0x83,"*","*",0x53,0x57,0x8B,"*","*","*",0x33,0xDB,0x3B,0xFB,0x0F,"*","*","*","*","*",0x8B,0x87]
        },
        {
            "os"    : "linux",
            "mod"   : "cstrike",
            "value" : [0x55,0x89,"*",0x83,"*","*",0x57,0x56,0x53,0xE8,"*","*","*","*",0x81,"*","*","*","*","*",0xC7,"*","*","*","*","*","*",0x83,"*","*","*",0x74,"*",0x8B]
        }
    ]
}

"Some functions symbols name doesn't work for some reasons, it might be the case for this one too. Some symbols doesn't work and I don't think it's related to orpheu itself."

It's a weird issue, but anyway, the solution was doing a signature of bytes for founding directly the function

[meTaLiCroSS]

CBasePlayerWeapon::HasSecondaryAttack and CBasePlayerWeapon::AddPrimaryAmmo are not used by the engine? They seem to be useful functions at the area of weapon modifications :/

[ConnorMcLeod]

CBasePlayerWeapon::HasSecondaryAttac is used in CBasePlayerWeapon::ItemPostFrame but is inlined (may be same at some other places).
CBasePlayerWeapon::AddPrimaryAmmo is integrated to CBasePlayerWeapon::ExtractAmmo

So, developers have created those functions, but compiler optimized it putting the code directly where the function is used, because the function is small or is used only 1 time or any oscur reason
Arkshine may tell more about this.

[meTaLiCroSS]

Originally Posted by ConnorMcLeod CBasePlayerWeapon::HasSecondaryAttac is used in CBasePlayerWeapon::ItemPostFrame but is inlined (may be same at some other places). CBasePlayerWeapon::AddPrimaryAmmo is integrated to CBasePlayerWeapon::ExtractAmmo So, developers have created those functions, but compiler optimized it putting the code directly where the function is used, because the function is small or is used only 1 time or any oscur reason Arkshine may tell more about this.

I thought that it was something like that :/ both functions are inlined on windows and linux? I was trying to find a direct method for changing weapons max clip, in HLSDK iMaxClip() is used on ItemPostFrame, AddPrimaryAmmo (as from I you said, it's integrated with ExtractAmmo), and a hardcoded value is used on DefaultReload which is easily modifiable, on ItemPostFrame I should care about the post-reloading function (plus calling TabulateAmmo), on DefaultReload just change a param value, and i don't know what to do now on ExtractAmmo, because values are hardcoded :/

[Arkshine]

both functions are inlined on windows and linux? Check yourself ? It's anyway depending, sometimes both are inline, sometimes not. Something you can check easily since you use already IDA.

About changing maxclip, I would do like in WeaponMod, you block original weapon and you register a new one ; and of course depending what you want you can use the same value as the original weapon but changing only max clip. It's the best and fastest way since it would require to hook just one function at precache and doing nothing else. Of course, it's not suitable for "dynamic" change.