Quote:
Originally Posted by Ambit
That's strange. I figured at first that my issue was that I had the parameters marked to be passed by reference (it wouldn't make sense since altering the values wouldn't do anything after the function has already run), but when I removed them I got a compiler error saying that the function signature didn't match. I assumed that I must have had it correct since as it is right now I don't get a compiler error.
|
The reason just removing the &s didn't work is because the correct function also changes the return type (from Action tag to no tag).
The problem is that the signatures for all the callback functions are in one gigantic funcenum (a set of callback functions with the same name) named SDKHookCB, and the compiler doesn't know which the extension expects you to use for which hook type.
For reference, here's the entire set of callback declarations, taken from the 2.1 sdkhooks.inc. The comments above each type are the hook types it applies to:
PHP Code:
funcenum SDKHookCB
{
// PreThink/Post
// PostThink/Post
public(client),
// Spawn
Action:public(entity),
// GroundEntChanged
// SpawnPost
// Think/Post
// VPhysicsUpdate/Post
public(entity),
// EndTouch
// StartTouch
// Touch
Action:public(entity, other),
// EndTouchPost
// StartTouchPost
// TouchPost
public(entity, other),
// SetTransmit
Action:public(entity, client),
// WeaponCanSwitchTo
// WeaponCanUse
// WeaponDrop
// WeaponEquip
// WeaponSwitch
Action:public(client, weapon),
// WeaponCanSwitchToPost
// WeaponCanUsePost
// WeaponDropPost
// WeaponEquipPost
// WeaponSwitchPost
public(client, weapon),
// OnTakeDamage
// Note: Force application is dependent on game and damage type(s)
// SDKHooks 1.0+
Action:public(victim, &attacker, &inflictor, &Float:damage, &damagetype),
// SDKHooks 2.0+
Action:public(victim, &attacker, &inflictor, &Float:damage, &damagetype, &weapon, Float:damageForce[3], Float:damagePosition[3]),
// SDKHooks 2.1+ (can check for support at runtime using GetFeatureStatus on SDKHook_DmgCustomInOTD capability.
// DON'T attempt to access 'damagecustom' var if feature status != available
Action:public(victim, &attacker, &inflictor, &Float:damage, &damagetype, &weapon,
Float:damageForce[3], Float:damagePosition[3], damagecustom),
// OnTakeDamagePost
public(victim, attacker, inflictor, Float:damage, damagetype),
public(victim, attacker, inflictor, Float:damage, damagetype, weapon, const Float:damageForce[3], const Float:damagePosition[3]),
// FireBulletsPost
public(client, shots, const String:weaponname[]),
// TraceAttack
Action:public(victim, &attacker, &inflictor, &Float:damage, &damagetype, &ammotype, hitbox, hitgroup),
// TraceAttackPost
public(victim, attacker, inflictor, Float:damage, damagetype, ammotype, hitbox, hitgroup),
// ShouldCollide
bool:public(entity, collisiongroup, contentsmask, bool:originalResult),
// Use
Action:public(entity, activator, caller, UseType:type, Float:value),
// UsePost
public(entity, activator, caller, UseType:type, Float:value),
// Reload
Action:public(weapon),
// Reload post
public(weapon, bool:bSuccessful)
};
The only way to fix this would be to make a separate hook function and callback function for each callback type, which would break backward compatibility... and make things harder to read in general.
Quote:
Originally Posted by Ambit
I also saw
Code:
int Hook_OnTakeDamage(CTakeDamageInfoHack &info);
int Hook_OnTakeDamagePost(CTakeDamageInfoHack &info);
in the source code and figured that meant that they must take the same parameters and have the same return type. |
Crossing the border between the C++ and SourcePawn sides is tricky. The return value is always a cell_t when crossing, and cell_t is an int on the C++ side. However, in the actual native itself, you pass things back via references using functions in the global smutils (iirc) object, and as such, values declared as references
are treated differently.
__________________