[a7811311622]

It would be more appropriate to use FM_TraceLine...(Personal point of view)

[ConnorMcLeod]

Originally Posted by a7811311622 It would be more appropriate to use FM_TraceLine...(Personal point of view)

Not really, would need to hook TraceLine only during PrimaryAttack function.
Still better to replace deafult value with custom value with orpheu module, simple and über efficient ;)

[nikhilgupta345]

Originally Posted by ConnorMcLeod RegisterCVars function doesn't need to be public g_szWeaponClassnames shouldn't be global, declare it in RegisterCVars function so memory is free when you exit the function. i < MAX_WEAPON + 1 i <= MAX_WEAPON would make more sense Little tip : PHP Code:             formatex( szCVarName, charsmax( szCVarName ), "max_distance_%s", g_szWeaponClassnames[ i ] );                          replace( szCVarName, charsmax( szCVarName ), "weapon_", "" );  -> PHP Code:             formatex( szCVarName, charsmax( szCVarName ), "max_distance_%s", g_szWeaponClassnames[ i ][ 7 ] );  PHP Code:         static Float:flAttackerOrigin[ 3 ];         static Float:flVictimOrigin[ 3 ];  Static is not needed at all there.         if( !g_pWeaponCVARs[ iWeapon ] )             return HAM_IGNORED;                 new iMaxDistance = get_pcvar_num( g_pWeaponCVARs[ iWeapon ] ); You read 2 times the same array, would be better to cache pointer result. DMG_HEGRENADE check is useless, it will never happen. Your plugin only allow to lower default weapon distance, and not to raise it. With orpheu you could lower or raise this distance, and you could also change bullets penetration (number of times a bullet can go thru a wall). So your way is very limitated.

Well, I'm not sure how to use Orpheu, and also, I can't seem to find exactly where they determine the weapon max distance in CSSDK.

[Arkshine]

The max distance and the bullet penetration are used in CBaseEntity::FireBullets3().
Example with AK47, from CAK47:AK47Fire() :

Vector vecDir = m_pPlayer->FireBullets3( m_pPlayer->GetGunPosition(), gpGlobals->v_forward,
		flSpread, 8192.0, AK47_PENETRATION, BULLET_PLAYER_762MM, AK47_DAMAGE, AK47_RANGE_MODIFIER, m_pPlayer->pev, 0, m_pPlayer->random_seed );

With orpheu, you can't hook FireBullets3().

One of a possible solution is :

- You get PrimaryAttack() function address
- From this address, you get the *Fire() function address
- From this address, you replace 8192 by another value.

To do the 2 first, you can follow this method : https://forums.alliedmods.net/showpo...02&postcount=7
To do the last, use simply OrpheuMemoryReplaceAtAddress().

Note: If you intend to make your plugin dynamic (I mean, if you the value can be changed in real time), save the address and you could use directly OrpheuMemorySetAtAddress().

Ask if there is something you don't understand.

[nikhilgupta345]

Originally Posted by Arkshine The max distance and the bullet penetration are used in CBaseEntity::FireBullets3(). Example with AK47, from CAK47:AK47Fire() : Vector vecDir = m_pPlayer->FireBullets3( m_pPlayer->GetGunPosition(), gpGlobals->v_forward, flSpread, 8192.0, AK47_PENETRATION, BULLET_PLAYER_762MM, AK47_DAMAGE, AK47_RANGE_MODIFIER, m_pPlayer->pev, 0, m_pPlayer->random_seed ); With orpheu, you can't hook FireBullets3(). One of a possible solution is : - You get PrimaryAttack() function address - From this address, you get the *Fire() function address - From this address, you replace 8192 by another value. To do the 2 first, you can follow this method : https://forums.alliedmods.net/showpo...02&postcount=7 To do the last, use simply OrpheuMemoryReplaceAtAddress(). Note: If you intend to make your plugin dynamic (I mean, if you the value can be changed in real time), save the address and you could use directly OrpheuMemorySetAtAddress(). Ask if there is something you don't understand.

Would I have to have a separate function for each individual weapon? + Make a new sig for each weapon? And what address would I pass in OrpheuMemory[Set/Replace]AtAddress()?

[Arkshine]

That's something you will do one time in the plugin_init for example.
You work with memory address. You need to loop using the method from the link (2 first line in plugin_init) with all the weapon, and for each weapon replacing the default distance with the cvar value.

Well, will show you a basic example tomorrow, since you don't know much about orpheu, better to show you a concrete example. Plus you need to know the default distance for all weapons.

[nikhilgupta345]

Originally Posted by Arkshine That's something you will do one time in the plugin_init for example. You work with memory address. You need to loop using the method from the link (2 first line in plugin_init) with all the weapon, and for each weapon replacing the default distance with the cvar value. Well, will show you a basic example tomorrow, since you don't know much about orpheu, better to show you a concrete example. Plus you need to know the default distance for all weapons.

Yea, that would be great, thanks. I've been trying to get into orpheu, but I have no idea where to start (making signatures and stuff). I know there are a lot of example plugins, but I feel a basic plugin would help a lot.

[a7811311622]

I also don't know how to change bullets penetration with Orpheu...

I just know how to change bullets penetration with Fakemeta and Hamsandwich, but I don't know to get the correct texture same as UTIL_TextureHit...

[Arkshine]

Originally Posted by nikhilgupta345 Yea, that would be great, thanks. I've been trying to get into orpheu, but I have no idea where to start (making signatures and stuff). I know there are a lot of example plugins, but I feel a basic plugin would help a lot.

Well, it's going to be a pain for linux...

In windows, the value like 8192 is referenced directly inside the *Fire() function. So, what I've done seems to work properly by replacing a value by another, searching inside this function.

In linux, the memory is handled differently. That's not all, it's slightly different between the hlbeta/stable version because how it's compiled. In hlbeta, A value like 8192 is referenced in a specific zone, so what we see inside the *Fire() function is an address to this reference and not the value directly. To change the value, we have to know this address. In the stable version, It's more or less the same, except the address is based on the GOT (Global Offset Table). To get the real address, you need add the address of the GOT.
From that 2 things to solve :
1/ Find a way to detect user is using the hlbeta or not. Valve has released only the dedicated part public. The CS part has not been released yet. But in the both case, the engine build version is the same, and we can't check this way anymore.
2/ Find a way to search the address of the reference of the value, because we can't search with the value anymore. Though I've some tricky solution in my mind.

Fuck linux.

I wanted just to explain the current status.
I will try some things. Are you sill interested to see the windows part ?

[nikhilgupta345]

Originally Posted by Arkshine Well, it's going to be a pain for linux... In windows, the value like 8192 is referenced directly inside the *Fire() function. So, what I've done seems to work properly by replacing a value by another, searching inside this function. In linux, the memory is handled differently. That's not all, it's slightly different between the hlbeta/stable version because how it's compiled. In hlbeta, A value like 8192 is referenced in a specific zone, so what we see inside the *Fire() function is an address to this reference and not the value directly. To change the value, we have to know this address. In the stable version, It's more or less the same, except the address is based on the GOT (Global Offset Table). To get the real address, you need add the address of the GOT. From that 2 things to solve : 1/ Find a way to detect user is using the hlbeta or not. Valve has released only the dedicated part public. The CS part has not been released yet. But in the both case, the engine build version is the same, and we can't check this way anymore. 2/ Find a way to search the address of the reference of the value, because we can't search with the value anymore. Though I've some tricky solution in my mind. Fuck linux. I wanted just to explain the current status. I will try some things. Are you sill interested to see the windows part ?

Sure.