API: Added new API funcs (6) and new Hookchains (21)

[dystopm]

• Ordered PM_LadderMove declarations
• Deleted API funcs declarations in CAPI_Impl.h
• Moved API func definitions in CAPI_Impl.cpp to the top
• Corrected EXT_FUNC order in function definitions
• Added six new API funcs to export:
  • UTIL_DecalTrace
  • UTIL_Remove
  • AddAmmoNameToAmmoRegistry
  • TextureTypePlaySound
  • CreateWeaponBox
  • SpawnGrenade
• Added twenty one new Hookchains:
  • PM_WaterJump ([Feature Requests] New hooks to API #741 (comment))
  • PM_CheckWaterJump
  • PM_Jump (API: Implement PM_Jump hook #753)
  • PM_Duck (API: Implement PM_UnDuck hook #743)
  • PM_UnDuck (API: Implement PM_UnDuck hook #743)
  • PM_PlayStepSound ([Feature Requests] New hooks to API #741 (comment))
  • PM_AirAccelerate ([Feature Requests] New hooks to API #741 (comment))
  • ClearMultiDamage
  • AddMultiDamage
  • ApplyMultiDamage
  • BuyItem (@Vaqtincha)
  • CSGameRules::Think (@WaLkZa)
  • CSGameRules::TeamFull
  • CSGameRules::TeamStacked
  • CSGameRules::PlayerGotWeapon
  • CBotManager::OnEvent (Added Hookchain for CBotManager::OnEvent #795)
  • CBasePlayer::CheckTimeBasedDamage ([Feature Requests] New hooks to API #741 (comment))
  • CBasePlayer::EntSelectSpawnPoint
  • CBasePlayerWeapon::ItemPostFrame ([Feature Requests] New hooks to API #741 (comment))
  • CBasePlayerWeapon::KickBack (Implemented CBasePlayerWeapon::KickBack hook  #738)
  • CBasePlayerWeapon::SendWeaponAnim
• AddAmmoNameToAmmoRegistry refactory:
  • Changed return type from void to int, it now returns generated ammo index.
  • Changed first ammo index in looping and after overflow to 1, based on CBasePlayer::GetAmmoIndex behaviour.
  • Function now checks string validity inside it to make it API friendly.
  • Latests modifications were not enclosed in FIXES macro because those undesired behaviour cannot be archivable on unmodded routines.

[WaLkZa]

Can you add:

• PM_PlayStepSound (usage in Jump Sound Blocker)
• PM_SpectatorMove (usage in Fly mode)
• SG_TumbleThink (usage in HEs destroy grenades)
• CGameRules::Think (usage in Timer Controller)

You can look in this list as well: #741 (comment)

[StevenKal]

Nice!
PS: Adding some forgotten game rules functions (like the ones of the healthkits [FlHealthChargerRechargeTime...], chargers, etc.) will be welcomed (because ReGameDLL_CS does not has all of them), but you are already "unchained" at filling RG_CS recently! Hahaha that sudden activity on it!
Also, this is "kind of useless" to add new "*_api" functions for standard functions which redirect to them, except if the format or return type is changed. But maybe approvers prefer having such.

Let's hope now for approvers not be so snail to merge this!

[dystopm]

@WaLkZa

• PM_PlayStepSound (usage in Jump Sound Blocker)
• CGameRules::Think (usage in Timer Controller)

Seems reasonable

• PM_SpectatorMove (usage in Fly mode)

This one is a direct call to the function, which means it would be an API function, but judging by the code there's no need to call PM_SpectatorMove, you can easily recreate that behaviour without calling it.

• SG_TumbleThink (usage in HEs destroy grenades)

Judging by the context, it is enough with hooking Think, there's no need to directly call that function. By that time coders used a lot of Orpheu to achieve their proposals but in fact most of them were not really neccesary. You have ExplodeHeGrenade hook and you can explode a nade by just changing dmgtime value.

You can look in this list as well: #741 (comment)

I can say that 50% of those hook proposals are not really worth it, because many are viable with other hooks and you have comments in that post that prove that. I'll patiently wait for people to request hooks, like you did, to achieve the functionality they want.

I'll be editing this PR in response to this

[dystopm]

@StevenKal

Nice! PS: Adding some forgotten game rules functions (like the ones of the healthkits [FlHealthChargerRechargeTime...], chargers, etc.) will be welcomed

If you want to propose a hook besides the ones asked in the given link, you can take advange now

(because ReGameDLL_CS does not has all of them)

Clearly it wont, it's part of the project goals and I respect that

but you are already "unchained" at filling RG_CS recently! Hahaha that sudden activity on it!

Thanks. Wanted to dirty my hands a bit with C++ since I'm working with in my job, and now I'm porting my whole AMXX projects to this engine.

Also, this is "kind of useless" to add new "*_api" functions for standard functions which redirect to them, except if the format or return type is changed. But maybe approvers prefer having such.

IMO it's a reasonable and modern way to separate API functions from the original ones in case it is needed. It does not generate any other discomfort than a visual one. Programmers needs to get an exclusive control of their OCD when joining collaborative projects with specific goals.

Let's hope now for approvers not be so snail to merge this!

No pressure, they have their schedule. I don't see a disvantage on that coming from a huge and public disassembly project, also publicly distributable and editable. We all got time for our things. In desperate cases, everybody is able to fork their own branch. which is not desirable but anyways I'm contributing with technical, detailed and separate commits which I makes things easier here for all. Bless

[WaLkZa]

Judging by the context, it is enough with hooking Think, there's no need to directly call that function. By that time coders used a lot of Orpheu to achieve their proposals but in fact most of them were not really neccesary. You have ExplodeHeGrenade hook and you can explode a nade by just changing dmgtime value.

There is a discussion about your proposal between plugin author and Arkshine on 3 and 4 page. So it's seems reasonable to use SG_TumbleThink hook.

[dystopm]

Judging by the context, it is enough with hooking Think, there's no need to directly call that function. By that time coders used a lot of Orpheu to achieve their proposals but in fact most of them were not really neccesary. You have ExplodeHeGrenade hook and you can explode a nade by just changing dmgtime value.

There is a discussion about your proposal between plugin author and Arkshine on 3 and 4 page. So it's seems reasonable to use SG_TumbleThink hook.

A 10 year old discussion, in which there's no concret proof of using SG_TumbleThink directly, in a case where this specific grenade changes between 2 Think functions: SG_TumbleThink and SG_Detonate. I still think it's unnecesary.

OrpheuRegisterHook(OrpheuGetFunction("SG_TumbleThink", "CGrenade"),"CGrenade_SG_TumbleThink", OrpheuHookPost)

->

RegisterHam(Ham_Think, "grenade", "OnCGrenade_Think_Post", true)

And

public OrpheuHookReturn:CGrenade_SG_TumbleThink(sg)
{
	if(!pev_valid(sg))
		return OrpheuIgnored
		
	static Float:explTime
	
	pev(sg, SG_EXPLOSION_TIME, explTime)
	
	// time to explode
	if(explTime && get_gametime() >= explTime)
		OrpheuCall(handle_SG_Detonate, sg)
		
	return OrpheuIgnored
}

->

public OnCGrenade_Think_Post(ent)
{
	if(!pev_valid(ent))
		return HAM_IGNORED
		
	if(GetGrenadeType(ent) != WEAPON_SMOKEGRENADE || get_member(ent, m_Grenade_bDetonated))
		return HAM_IGNORED
		
	static Float:explTime
	
	pev(ent, SG_EXPLOSION_TIME, explTime)
	
	// time to explode
	if(explTime && get_gametime() >= explTime)
	{
		set_pev(ent, pev_dmgtime, -9999.0)
		set_member(ent, m_Grenade_bDetonated, true)
		ExecuteHamB(Ham_Think, ent)
	}
		
	return OrpheuIgnored
}

(I took less time in coding this than adding an API to be honest)

[dystopm]

Added 3 new PM_ functions to the Hookchain list, post edited.

• PM_WaterJump
• PM_PlayStepSound (@WaLkZa)
• PM_AirAccelerate

[dystopm]

Added 2 class functions to the Hookchain list, post edited.

• CBasePlayer::CheckTimeBasedDamage (@RauliTop)
• CBasePlayerWeapon::ItemPostFrame

[StevenKal]

If you want to propose a hook besides the ones asked in the given link, you can take advange now
Clearly it wont, it's part of the project goals and I respect that

Well, game rules is something important, as the names say, it "rules the game", and, a lot of hooks (huge %) have been added to the API, adding the "missing ones" could worth, because those are useful.

IMO it's a reasonable and modern way to separate API functions from the original ones in case it is needed. It does not generate any other discomfort than a visual one. Programmers needs to get an exclusive control of their OCD when joining collaborative projects with specific goals.

Well, different perspective probably, but I personnaly see two inconvenients at adding function like "RadiusDamage_api" which just point to "RadiusDamage" and without changing any return & parameters type/format:
1 -> This adds a "one more function" (duplicates it, like via IDA listing etc.) for "nothing".
2 -> We loose the possibility to easily retrieve the address of the "real function" (RadiusDamage) if we have the address of "g_ReGameApiFuncs" (people can easily use on AMXX, as example, OrpheuGetAtAddress with related offset to get "RadiusDamage" function address with ease, & reliable way, except if listing order of "ReGameFuncs_t" is suddently broken but it will not, since new functions are added at the suite).
As advantage I might only see the fact it informs about a function "available as API", but API structures are "public" so I do not see much the point, because people is aware of such listing of structure "ReGameFuncs_t" (the project is public & full open source).

No pressure, they have their schedule. I don't see a disvantage on that coming from a huge and public disassembly project, also publicly distributable and editable. We all got time for our things. In desperate cases, everybody is able to fork their own branch. which is not desirable but anyways I'm contributing with technical, detailed and separate commits which I makes things easier here for all. Bless

Well, everyone has a life, specific time to allocate for X or Y thing, motivation etc., no problem, but when a contributor takes time to add for example a new API hook, then this last remains pending not 1 month, but 6 months, or 1 year... while everything is simple (just a few lines added), clean & properly implemented & the approvers know it is, by just looking because they know "that a new API hook needs & which files need to be edited", that is abused it remains dormant all this time, while approvers are around, but do not merge anything, this is disappointing & does not give motivation to contributors to continue submitting PRs.
And I am pretty sure all people waiting for such PRs (which are often personal demands/requests they did) to be merged will agree with me!
People usually do not exige something to get merged the next day of its submission, obviously, but for things simple to understand for approvers & which do not need deep reviews or tests, this will worth if they could be merged much sooner than "1 year later"!

[Vaqtincha]

Please add hook "BuyItem"

Change "MakeVip" "void" hook to "bool" + change logic function PickNextVip (like "if (m_pVIP->MakeVIP())" ) useful for 3rd plugins.

[Vaqtincha]

And implement your version of my pr #600 with better code

[dystopm]

Please add hook "BuyItem"

Just thought why hasn't been added.

Change "MakeVip" "void" hook to "bool" + change logic function PickNextVip (like "if (m_pVIP->MakeVIP())" ) useful for 3rd plugins.

I think that change can be done if the major version is upgraded since (correct me if I'm wrong) I think you can broke some 3rd party plugins functionalities because headers changed.

And implement your version of my pr #600 with better code

Not really in my interests now, but I do not close myself to the possibility. Try to get it up and do a better coding anyways.

[dystopm]

If you want to propose a hook besides the ones asked in the given link, you can take advange now
Clearly it wont, it's part of the project goals and I respect that

Well, game rules is something important, as the names say, it "rules the game", and, a lot of hooks (huge %) have been added to the API, adding the "missing ones" could worth, because those are useful.

IMO it's a reasonable and modern way to separate API functions from the original ones in case it is needed. It does not generate any other discomfort than a visual one. Programmers needs to get an exclusive control of their OCD when joining collaborative projects with specific goals.

Well, different perspective probably, but I personnaly see two inconvenients at adding function like "RadiusDamage_api" which just point to "RadiusDamage" and without changing any return & parameters type/format: 1 -> This adds a "one more function" (duplicates it, like via IDA listing etc.) for "nothing". 2 -> We loose the possibility to easily retrieve the address of the "real function" (RadiusDamage) if we have the address of "g_ReGameApiFuncs" (people can easily use on AMXX, as example, OrpheuGetAtAddress with related offset to get "RadiusDamage" function address with ease, & reliable way, except if listing order of "ReGameFuncs_t" is suddently broken but it will not, since new functions are added at the suite). As advantage I might only see the fact it informs about a function "available as API", but API structures are "public" so I do not see much the point, because people is aware of such listing of structure "ReGameFuncs_t".

I see that your opinion is highly based on the fact memhacking is obstaculized (which also obstaculizes your personal projects I guess, mine too), which is not in the sight of this project and this has been discussed long time in this repository. I do not put the rules here (my house my rules?), but indeed, that's not the main topic in this PR. I am not going against that. The (1)st and (2)nd point aren't an inconvenient on a project which isn't taking memhack an option.

As @s1lentq said

We shouldn't be concerned about the fact that with these minor changes we can break compatibility 3-rd party things when they use memhacks.

Your perspective is as valid as that of the supporters of this repository. You are free to edit this as you like in your own fashion. Not going to argue on that.

No pressure, they have their schedule. I don't see a disvantage on that coming from a huge and public disassembly project, also publicly distributable and editable. We all got time for our things. In desperate cases, everybody is able to fork their own branch. which is not desirable but anyways I'm contributing with technical, detailed and separate commits which I makes things easier here for all. Bless

Well, everyone has a life, specific time to allocate for X or Y thing, motivation etc., no problem, but when a contributor takes time to add for example a new API hook, then this last remains pending not 1 month, but 6 months, or 1 year... while everything is simple (just a few lines added), clean & properly implemented & the approvers know it is, by just looking because they know "that a new API hook needs & which files need to be edited", that is abused it remains dormant all this time, while approvers are around, but do not merge anything, this is disappointing & does not give motivation to contributors to continue submitting PRs. And I am pretty sure all people waiting for such PRs (which are often personal demands/requests they did) to be merged will agree with me! People usually do not exige something to get merged the next day of its submission, obviously, but for things simple to understand for approvers & which do not need deep reviews or tests, this will worth if they could be merged much sooner than "1 year later"!

And if they do not merge this request I'll find it highly valid. Nobody is pressuring me to use this software, and by the way I'll use this in my own personal way. If your proposal follows the interests or the schema that repository owners also share, they will merge them. If they wont, they will have their reasons. If you do not see a response from them, that's also a response. But you can't blame them or force them to please our desires and interests, and more importantly, "answer us". They have worked on this for free and publicly, same as our costless contributions; and by "they" I'm reffering to anybody who contributed to this repository agreeing with the fact (1) memhacking isn't an option and (2) they may not be interested on your contributions.

Thanks for your responses. I strongly ask you to align with the topic that is being requested to merge since it is what is of interest at the moment 🙌

[dystopm]

Added 2 functions to the Hookchain. Post edited

• BuyItem (@Vaqtincha)
• CSGameRules::Think (@WaLkZa)

I think I'm done for now, wont be adding until a merge @s1lentq @wopox1337. Thanks to all contributors.

[StevenKal]

PS:
Do not forget version minor upgrade (version.h + two API files) in your API PRs!
But from my opinion this is more needed on official release update (in "Releases" section, right before the build), so when it includes API changes, s1lentq or wopox should increase it. But can still worth to upgrade it every time a new API is merged since people can also get & use artifacts in actions.

[dystopm]

PS: Do not forget version minor upgrade (version.h + two API files) in your API PRs! But from my opinion this is more needed on official release update (in "Releases" section, right before the build), so when it includes API changes, s1lentq or wopox should increase it. But can still worth to upgrade it every time a new API is merged since people can also get & use artifacts in actions.

Was going to answer you that I keep that detail to the maintainers besides the fact anyone can PR an API extension editing the version; consider this PRs to be fully mutable by them.

[dystopm]

Edited AddAmmoNameToAmmoRegistry function in order to extend its behaviour without altering its functionality.

[StevenKal]

Hi!
A hook "CBasePlayer::IsArmored" will be welcomed too (at least to remove armor protection on arms, because in real life, most kevlars do not have protection on arms!).

[StevenKal]

@s1lentq : Approved, good, now press "Merge" (+version upgrade)! One click, you can do it! Hehehe!

[StevenKal]

@dystopm: Can you try a hook of "CBotManager::OnEvent" in a plugin, & tell me if it also crashes for you? Thanks.