[dietcoke]

Does anyone know why this crashes my server when I execute the SDKCall?

StartPrepSDKCall(SDKCall_Player);
PrepSDKCall_SetFromConf(hConf, SDKConf_Signature, "CTFGameStats::ResetPlayerStats");
if ((g_hResetPlayerStats = EndPrepSDKCall()) == null) SetFailState("Failed to create SDKCall for CTFGameStats::ResetPlayerStats signature!");

SDKCall(g_hResetPlayerStats, client);

The symbol I am using is _ZN12CTFGameStats16ResetPlayerStatsEP9CTFPlay er

[nosoop]

You're calling a non-static function on the CTFGameStats class; you need a CTFGameStats instance in addition to the player parameter.

StartPrepSDKCall(SDKCall_Raw); // pass the address of a CTFGameStats as 'this'
PrepSDKCall_SetFromConf(hConf, SDKConf_Signature, "CTFGameStats::ResetPlayerStats");
PrepSDKCall_AddParameter(SDKType_CBasePlayer, SDKPass_Pointer); // this is when you pass the player
g_hResetPlayerStats = EndPrepSDKCall();

// call it -- g_pGameStats is an address of a CTFGameStats instance
SDKCall(g_hResetPlayerStats, g_pGameStats, client);

[dietcoke]

Originally Posted by nosoop You're calling a non-static function on the CTFGameStats class; you need a CTFGameStats instance in addition to the player parameter. StartPrepSDKCall(SDKCall_Raw); // pass the address of a CTFGameStats as 'this' PrepSDKCall_SetFromConf(hConf, SDKConf_Signature, "CTFGameStats::ResetPlayerStats"); PrepSDKCall_AddParameter(SDKType_CBasePlayer, SDKPass_Pointer); // this is when you pass the player g_hResetPlayerStats = EndPrepSDKCall(); // call it -- g_pGameStats is an address of a CTFGameStats instance SDKCall(g_hResetPlayerStats, g_pGameStats, client);

Thanks for the reply. How do I create an instance/get the address of CTFGameStats ?

[nosoop]

Originally Posted by dietcoke Thanks for the reply. How do I create an instance/get the address of CTFGameStats ?

It's a global singleton, so the easiest way would be to look at anything that calls a function on CTFGameStats.

On Windows, you can look at the CTFPlayer::RemoveNemesisRelationships() function (which has a unique string) and read the absolute offset from where it gets moved into the ecx register before calling into CTFGameStats::ResetKillHistory().
On Linux / Mac you should be able to use the @CTF_GameStats symbol as the signature (CTF_GameStats is the name of the singleton).

Regardless of platform, you'll need the gameconfig address mechanism with GameConfGetAddress().

[dietcoke]

Originally Posted by nosoop It's a global singleton, so the easiest way would be to look at anything that calls a function on CTFGameStats. On Windows, you can look at the CTFPlayer::RemoveNemesisRelationships() function (which has a unique string) and read the absolute offset from where it gets moved into the ecx register before calling into CTFGameStats::ResetKillHistory(). On Linux / Mac you should be able to use the @CTF_GameStats symbol as the signature (CTF_GameStats is the name of the singleton). Regardless of platform, you'll need the gameconfig address mechanism with GameConfGetAddress().

This is good info, thanks again. Are you familiar with extensions? If so, do you know why when I detour some static, non-member functions the server crashes? Some work just fine, others don't.
And when I try to hook/detour these with dhooks, the server crashes as well.

[nosoop]

Originally Posted by dietcoke This is good info, thanks again. Are you familiar with extensions? If so, do you know why when I detour some static, non-member functions the server crashes? Some work just fine, others don't. And when I try to hook/detour these with dhooks, the server crashes as well.

Without seeing which functions you're working with and how you're hooking them, I can't say for sure. Make sure you're using the correct macros (for CDetour) / call conventions (dynhooks) for it.

I use dynhooks plenty and most issues I come across stem from some fault in my own code, and I also use CDetours to some extent and haven't run into problems with the detours themselves (though I think I've only detoured member functions so far).

Getting mixed results is strange, though. They might not be what you think they are.