Implement GetArmorDamageFactor hook

[Vaqtincha]

No description provided.

[StevenKal]

Something I suggested to s1lentq but who ignore as usual, here is a better format I recommend and the reasons why.
Feel free to keep your function name, this worth too, but my format is better & more enhanced regarding possibilities.

QUOTE FROM MY EMAIL TO HIM:

Request #5 (on ReGameDLL_CS):

On L1086 inside player.cpp, all the content of the armor ratios are internally hardcoded inside that "if (pAttack->m_pActiveItem)" part, I would like you make a new API hook chain for that whole content, in order to allow coders to alter armor ratios.

I might recommend a format like:
float CBasePlayer_GetArmorRatioFromAttackerWeapon(CBasePlayer *pPlayerTargetCBase, CBasePlayer *pAttackerTargetCBase, CBasePlayerItem *pAttackerItemCBase, int iAttackerWeaponTypeID, float flRatio, float flBonus, float flShieldRatio)

And it should return in the "float" the new value of "flRatio" (flRatio = CBasePlayer_GetArmorRatioFromAttackerWeapon(...)).

Feel free to name it differently, but all of the parameters I have specified must be added (useful informations), so we can know the attacker's informations and what is the current ratio depending on some conditions (VIP/Shield holding, etc.), and readjust it, and also set "flShieldRatio" parameter to 0.0 in case of we do not want to perform different armor ratio protection for victim clients holding shield (I personnaly do not see why the game has been coded with such differences about armor ratios, and I even think it is not realistic, because despite in real life there are different kind of "bullet proof vests", they usually protect the same way, the "higher protection ones" are the military's ones where soldiers can put "metal plates" in it to make it more resistant or even stop large calibers).

It will also be good if this new function could be used for grenade/blast damage (so, also put in some lines above, like around L903 inside player.cpp).

[StevenKal]

Better, but you still could add more of the parameters I have suggested. The "CBasePlayerItem *pAttackerItemCBase" could be skipped (because we can if we wish, retrieve it via the attacker's CBasePlayer pointer & inventory item type ID), but the others are useful (the victim & attacker infos could be used in a lot of situations for different settings), and the "flBonus" could be passed via reference in order to allow us to alter it before the armor code (around 30 lines after the end of that part) got executed.

If a new useful hook is added, most complete it is, better this is huh!

[StevenKal]

And put the hooks in the end of the API to avoid breaking listing.

[Vaqtincha]

@StevenKal
by the way, this piece of code should be higher
https://github.com/s1lentq/ReGameDLL_CS/blob/8d6bf017f5c63efdb83b91b58f51f40c539ff10f/regamedll/dlls/player.cpp#L1020-L1024

[StevenKal]

Yes, and armor calculation process code being "duplicated" is kind of ugly.
But I was mainly refering about the L1157 to make "flBonus" changeable (if we could via that hook), and as I suggested it would be also good to implement this new hook before, for a compatibility with granadas/blast too.

[StevenKal]

You could even add support for other entities, as "func_tank" (with different ratios depending on the bullet type used from the tank), because right now this will use the holstered active item ratio when someone shoot a client via a tank sentry.

[Vaqtincha]

@StevenKal Unfortunately, my knowledge does not yet allow it to be beautifully done.

[StevenKal]

Whatever it is true or not, I think you can at least add the parameters I have specified, like:
(CBasePlayer *pPlayerTargetCBase, CBasePlayer *pAttackerTargetCBase, int iAttackerWeaponTypeID, float flRatio, float *flBonus, float flShieldRatio).
Because with the both first "CBasePlayer *", we could add ourselves support for func_tank, etc. (custom changes depending on kind of attacker/victim, etc.), in a custom plugin. And I even think the "inflictor" should be passed too.
Without those, the hook remains too much limited in my opinion.

[StevenKal]

Well, I like it better now, sounds good.
But maybe you could swap "flRatio" with "bitsDamageType" but it does not matter much.

The "flShieldRatio" is no longer alterable via parameter, but, we can still "workaround" by unsetting shield/VIP properties in a PRE hook of that function, then set them back at their previous status in a POST one, so not dramatic.

[Vaqtincha]

@StevenKal works!

#include <amxmodx>
#include <reapi>

public plugin_init()
{
	register_plugin("GetArmorDamageFactor", "1.0", "GABE")
	RegisterHookChain(RG_CBasePlayer_GetArmorDamageFactor, "GetArmorDamageFactor", .post = 1)
}

public GetArmorDamageFactor(const pPlayer, const pevAttacker, const pevInflictor, Float:flBonus, Float:flBaseRatio, const bitsDamageType)
{
 	new szInflictor[32]
	
	if (!is_nullent(pevInflictor))
		get_entvar(pevInflictor, var_classname, szInflictor, charsmax(szInflictor))	

	server_print("pPlayer %n | pevAttacker %n | szInflictor %s | flBonus %0.2f | flBaseRatio %0.2f | flRatio %0.2f", pPlayer, pevAttacker, szInflictor, flBonus, flBaseRatio, GetHookChainReturn(ATYPE_FLOAT))
	return HC_CONTINUE	
}

[Vaqtincha]

little plugin (super armor for bomb explosion)

#include <amxmodx>
#include <reapi>

public plugin_init()
{
	register_plugin("GetArmorDamageFactor", "1.0", "GABE")
	RegisterHookChain(RG_CBasePlayer_GetArmorDamageFactor, "GetArmorDamageFactor", .post = 0)
}

public GetArmorDamageFactor(const pPlayer, const pevAttacker, const pevInflictor, Float:flBonus, Float:flBaseRatio, const bitsDamageType)
{
	if ((bitsDamageType & DMG_BLAST) && FClassnameIs(pevInflictor, "grenade"))
	{
		SetHookChainArg(5, ATYPE_FLOAT, flBaseRatio * 0.1)
		SetHookChainArg(4, ATYPE_FLOAT, flBonus * 0.1)
	}

	return HC_CONTINUE	
}

[StevenKal]

Good too, I will just recommend to put "bitsDamageType" parameter right after "pevInflictor" in order to "follow a bit" the "TakeDamage" order, and keep "flBonus" & "flBaseRatio" at the end.
And also, put the hooks in the end of the API (below "FireBullets3") to avoid breaking listing, and also boost API version.

EDIT: You could still add default support for "func_tank" entitites (above "if(pAttack->m_pActiveItem)") if you find some motivation for that!

[Vaqtincha]

And also, put the hooks in the end of the API (below "FireBullets3") to avoid breaking listing, and also boost API version.

well now the hook has stopped working.

[StevenKal]

Because some parts in the AMXX's ReAPI module have missing code (in "reapi/include/cssdk/dlls/regamedll_api.h" for example, this must contain same functions than the ReGameDLL_CS binary, so the 3 Fire* functions to have same IDs positions when the hooks are loaded). Make your other PR in ReAPI module use the same functions and problem will be solved after recompiling your both ReGameDLL_CS & ReAPI binaries.
I guess you know that but maybe you did not pay attention to the latest Fire* hooks added to the ReGameDLL binary.
That's why the listing order of the functions (in "regamedllcs_api.h") must be respected & the new functions added at the suite to avoid breaking backward compatibility, however, major should be pushed instead of minor (if you put a new function in middle of the list, but this should not be done this way, because users updating will require to update both binaries to ensure proper working, but not everyone do that).

So in ReAPI's "regamedll_api.h", change this:
virtual IReGameHookRegistry_CBasePlayer_GetArmorDamageFactor *CBasePlayer_GetArmorDamageFactor() = 0;

Into:
virtual IReGameHookRegistry_CBaseEntity_FireBullets *CBaseEntity_FireBullets() = 0;
virtual IReGameHookRegistry_CBaseEntity_FireBuckshots *CBaseEntity_FireBuckshots() = 0;
virtual IReGameHookRegistry_CBaseEntity_FireBullets3 *CBaseEntity_FireBullets3() = 0;

virtual IReGameHookRegistry_CBasePlayer_GetArmorDamageFactor *CBasePlayer_GetArmorDamageFactor() = 0;

And also add the typedef ... of the Fire* functions (from ReGameDLL_CS's "regamedllcs_api.h" file).

[StevenKal]

What? Why closed? Do you give it up, or want to rework it?

About the "func_tank" entities support, not much people use them, and not many maps have them, but there are also possible plugins which has such entities, like a M2 I made.
But this worth to add it for realism regarding those funny guns.

You could easily implement the code right before your "if (pAttack->m_pActiveItem)", do a "if(pAttack->m_pTank) {", then inside, check if class name is "func_tank", if yes, do a switch with "pAttack->m_pTank->m_bulletType" (like it is done in "CFuncTankGun::Fire"), then do not forget a "default" where you set, probably the same value you will put than for the "TANK_BULLET_9MM" value, set some default values for "flRatio" & the "TANK_BULLET_*" (high for the 12mm please!).
Then do a else and check for "func_tanklaser", put another default value multiplier for "flRatio" (but which one should be? What is the "penetration power of a laser compared to some bullets? Need to check on the web if we can figure this out. Besides, there are different lasers), then do another "else" and put another value for both rocket/mortar tanks, but since they use "DMG_BLAST" the code will not be called for them, but stopped in the granada check in "CBasePlayer::TakeDamage", so probably you can ignore those blast versions.

[Vaqtincha]

No.

[StevenKal]

Bouhhhhh...
One more false hope.

[StevenKal]

Any chance you open & push it back? I do not get the reason why this has been closed, while it is an useful hook.
I guess either you do not want to do that I asked (but at worse you can push it in the actual status my wishes could be done manually in the hook), or either this is s1lentq who does not want this to be added.

[metita]

Not sure if ignored, maybe you will have better chance quoting wopox or silent, just be patient...