AlliedModders Wiki - User contributions [en]

Virtual Offsets (Source Mods)

2012-09-30T21:41:01Z

Berni:

[[Category:Metamod:Source Development]]
== Calling virtual functions ==
I got this method from [[User:Mani|Mani]], who I believe got it from [[User:PM|Pavol Marko]]. Thank you!

I hope to expand on an actual explanation when I have the time (and understand it better). Hopefully, someone can expand on this, but for now I'll just post the examples and a list of the CCSPlayer virtual function table offsets.

== Offset Lists ==
==== Automated Offsets ====
You can get automatically updated offsets from Berni's VTable Offset list. It automatically updates the offsets when an update is pushed by valve, making it a very resourceful tool.
* [http://www.sourcemodplugins.org/vtableoffsets Automated Offsets - Thanks to Berni]
==== Counter-Strike: Source ====
* [[CCSPlayer Offset List (Counter-Strike: Source)|CCSPlayer]]
* [[CBaseCombatWeapon Offset List (Counter-Strike: Source)|CBaseCombatWeapon]]
* [[CCSGameRules Offset List (Counter-Strike: Source) | CCSGameRules]]
* [[CBaseGrenade Offset List (Counter-Strike: Source) | CBaseGrenade]]
* [[CDEagle Offset List (Counter-Strike: Source) | CDEagle]]

==== Day of Defeat: Source ====
* [[CDODPlayer Offset List (Day of Defeat: Source)|CDODPlayer]]

==== Dystopia ====
* [[CDYSPlayer Offset List (Dystopia)|CDYSPlayer]]

==== Empires v2.12 ====
* [[CSDKPlayer Offset List (Empires)|CSDKPlayer]]

==== Fortress Forever ====
* [[CFFPlayer Offset List (Fortress Forever)|CFFPlayer]]

==== Half-Life 2: Capture the Flag ====
* [[CHL2_Player Offset List (Half-Life 2: Capture the Flag)|CHL2_Player]]

==== Half-Life 2: Deathmatch ====
* [[CHL2MP_Player Offset List (Half-Life 2: Deathmatch)|CHL2MP_Player]]

==== Hidden: Source ====
* [[CSDKPlayer Offset List (Hidden: Source)|CSDKPlayer]]

==== Insurgency ====
* [[CINSPlayer Offset List (Insurgency)|CINSPlayer]]

==== Left 4 Dead ====
* [[CTerrorPlayer Offset List (Left 4 Dead)|CTerrorPlayer]]

==== Left 4 Dead 2 ====
* [[CTerrorPlayer Offset List (Left 4 Dead 2)|CTerrorPlayer]]

==== Obsidian Conflict ====
* [[CHL2MP_Player Offset List (Obsidian Conflict)|CHL2MP_Player]]

==== Pirates, Vikings, and Knights II ====
* [[CPVK2Player Offset List (Pirates, Vikings, and Knights II)|CPVK2Player]]

==== The Ship ====
* [[CShipPlayer Offset List (The Ship)|CShipPlayer]]

==== SourceForts ====
* [[CHL2MP_Player Offset List (SourceForts)|CHL2MP_Player]]

==== Synergy ====
* [[CHL2MP_Player Offset List (Synergy)|CHL2MP_Player]]

==== Synergy SteamWorks (Synergy Orange Box Edition)====
* [[CHL2MP_Player Offset List (SynergyOB)|CHL2MP_Player]]

==== Team Fortress 2 ====
* [[CTFPlayer Offset List (Team Fortress 2)|CTFPlayer]]

==== Zombie Master ====
* [[CHL2MP_Player Offset List (Zombie Master)|CHL2MP_Player]]

==== Zombie Panic: Source ====
* [[CHL2MP_Player Offset List (Zombie Panic: Source)|CHL2MP_Player]]

==== GoldenEye: Source ====
* [[CGEPlayer Offset List (GoldenEye: Source)|CGEPlayer]]

== How to use the examples ==

Basically, this lets you call any [[virtual function]] by knowing it's offset. A table is created for each class that lists the address of the function for each virtual function. This method takes advantage of that to call those addresses.

Look at the examples below and edit to match the function you want to call:
Use the offset for the function you want to call in this line. ([[CCSPlayer_offset_list_(SourceMM)]])
<cpp>void *func = vtable[m_Off_GiveNamedItem];</cpp>
Change this line to match your return type and parameters:
<cpp>union {CBaseEntity *(VfuncEmptyClass::*mfpnew)(const char *, int );</cpp>
Call the original function with your parameters (change the return type to match the function you're calling):
<cpp>return (CBaseEntity *) (reinterpret_cast<VfuncEmptyClass*>(this_ptr)->*u.mfpnew)(ItemName, iSubType);</cpp>

You'll need to add an empty class for the union. Something like this:
<cpp>class VfuncEmptyClass {};</cpp>

== Examples ==

These examples are for CSS. Mani has created a set of macros to make this easier. If you ask nicely, maybe he'll give them to you or let you post them here.

<cpp>datamap_t *VFuncs::GetDataDescMap(CBaseEntity *pThisPtr)
{
void **this_ptr = *(void ***)&pThisPtr;
void **vtable = *(void ***)pThisPtr;
void *func = vtable[m_Off_GetDataDescMap];

union {datamap_t *(VfuncEmptyClass::*mfpnew)();
#ifndef __linux__
void *addr; } u; u.addr = func;
#else /* GCC's member function pointers all contain a this pointer adjustor. You'd probably set it to 0 */
struct {void *addr; intptr_t adjustor;} s; } u; u.s.addr = func; u.s.adjustor = 0;
#endif

return (datamap_t *) (reinterpret_cast<VfuncEmptyClass*>(this_ptr)->*u.mfpnew)();

}

void VFuncs::SetModel(CBaseEntity *pThisPtr, const char *ModelName)
{
void **this_ptr = *(void ***)&pThisPtr;
void **vtable = *(void ***)pThisPtr;
void *func = vtable[m_Off_SetModel];

union {void (VfuncEmptyClass::*mfpnew)(const char *);
#ifndef __linux__
void *addr; } u; u.addr = func;
#else // GCC's member function pointers all contain a this pointer adjustor. You'd probably set it to 0
struct {void *addr; intptr_t adjustor;} s; } u; u.s.addr = func; u.s.adjustor = 0;
#endif

(void) (reinterpret_cast<VfuncEmptyClass*>(this_ptr)->*u.mfpnew)(ModelName);

}

void VFuncs::Teleport(CBaseEntity *pThisPtr, const Vector *newPosition, const QAngle *newAngles, const Vector *newVelocity)
{
void **this_ptr = *(void ***)&pThisPtr;
void **vtable = *(void ***)pThisPtr;
void *func = vtable[m_Off_Teleport];

union {void (VfuncEmptyClass::*mfpnew)(const Vector *, const QAngle *, const Vector *);
#ifndef __linux__
void *addr; } u; u.addr = func;
#else // GCC's member function pointers all contain a this pointer adjustor. You'd probably set it to 0
struct {void *addr; intptr_t adjustor;} s; } u; u.s.addr = func; u.s.adjustor = 0;
#endif

(void) (reinterpret_cast<VfuncEmptyClass*>(this_ptr)->*u.mfpnew)(newPosition, newAngles, newVelocity);

}

Vector VFuncs::EyePosition( CBaseEntity *pThisPtr )
{
void **this_ptr = *(void ***)&pThisPtr;
void **vtable = *(void ***)pThisPtr;
void *func = vtable[m_Off_EyePosition];

union {Vector (VfuncEmptyClass::*mfpnew)( void );
#ifndef __linux__
void *addr; } u; u.addr = func;
#else // GCC's member function pointers all contain a this pointer adjustor. You'd probably set it to 0
struct {void *addr; intptr_t adjustor;} s; } u; u.s.addr = func; u.s.adjustor = 0;
#endif

return (Vector) (reinterpret_cast<VfuncEmptyClass*>(this_ptr)->*u.mfpnew)( );

}

QAngle &VFuncs::EyeAngles( CBaseEntity *pThisPtr )
{
void **this_ptr = *(void ***)&pThisPtr;
void **vtable = *(void ***)pThisPtr;
void *func = vtable[m_Off_EyeAngles];

union {QAngle& (VfuncEmptyClass::*mfpnew)( void );
#ifndef __linux__
void *addr; } u; u.addr = func;
#else // GCC's member function pointers all contain a this pointer adjustor. You'd probably set it to 0
struct {void *addr; intptr_t adjustor;} s; } u; u.s.addr = func; u.s.adjustor = 0;
#endif

return (QAngle&) (reinterpret_cast<VfuncEmptyClass*>(this_ptr)->*u.mfpnew)( );

}

void VFuncs::Ignite(CBaseEntity *pThisPtr, float flFlameLifetime, bool bNPCOnly, float flSize, bool bCalledByLevelDesigner)
{
void **this_ptr = *(void ***)&pThisPtr;
void **vtable = *(void ***)pThisPtr;
void *func = vtable[m_Off_Ignite];

union {void (VfuncEmptyClass::*mfpnew)(float , bool , float , bool );
#ifndef __linux__
void *addr; } u; u.addr = func;
#else // GCC's member function pointers all contain a this pointer adjustor. You'd probably set it to 0
struct {void *addr; intptr_t adjustor;} s; } u; u.s.addr = func; u.s.adjustor = 0;
#endif

(void) (reinterpret_cast<VfuncEmptyClass*>(this_ptr)->*u.mfpnew)(flFlameLifetime, bNPCOnly, flSize, bCalledByLevelDesigner);

}

CBaseEntity *VFuncs::GiveNamedItem(CBaseEntity *pThisPtr, const char *ItemName, int iSubType)
{
void **this_ptr = *(void ***)&pThisPtr;
void **vtable = *(void ***)pThisPtr;
void *func = vtable[m_Off_GiveNamedItem];

union {CBaseEntity *(VfuncEmptyClass::*mfpnew)(const char *, int );
#ifndef __linux__
void *addr; } u; u.addr = func;
#else // GCC's member function pointers all contain a this pointer adjustor. You'd probably set it to 0
struct {void *addr; intptr_t adjustor;} s; } u; u.s.addr = func; u.s.adjustor = 0;
#endif

return (CBaseEntity *) (reinterpret_cast<VfuncEmptyClass*>(this_ptr)->*u.mfpnew)(ItemName, iSubType);
}

void VFuncs::CommitSuicide(CBaseEntity *pThisPtr)
{
void **this_ptr = *(void ***)&pThisPtr;
void **vtable = *(void ***)pThisPtr;
void *func = vtable[m_Off_CommitSuicide];

union {CBaseEntity *(VfuncEmptyClass::*mfpnew)( void );
#ifndef __linux__
void *addr; } u; u.addr = func;
#else // GCC's member function pointers all contain a this pointer adjustor. You'd probably set it to 0
struct {void *addr; intptr_t adjustor;} s; } u; u.s.addr = func; u.s.adjustor = 0;
#endif

(reinterpret_cast<VfuncEmptyClass*>(this_ptr)->*u.mfpnew)();
}
</cpp>

Timers (SourceMod Scripting)

2012-07-17T20:15:39Z

Berni: /* Data Packs */

Timers in [[SourceMod]] are timed events that occur once or repeatedly at a given interval.

=Introduction=
Timers allow you to set an interval, a function to use as the event callback, and an optional Handle to pass through the callback. This is useful for saving data asynchronously.

All timer functions are in <tt>plugins/include/timers.inc</tt>.

=Basic Usage=
==One-Time Timers==
One-time timers are timers that only execute once. An example of a one-time timer might look like:

<pawn>public OnPluginStart()
{
CreateTimer(5.0, LoadStuff)
}

public Action:LoadStuff(Handle:timer)
{
PrintToServer("Loading stuff!")
}</pawn>

This code will print "Loading stuff!" to the server console five seconds after the map loads. The return value has no meaning for one-time timers.

==Repeatable Timers==
Repeatable timers execute infinitely many times, once every interval. Based on the return value, they either continue or cancel.

For example, say you want to display a message five times, once every three seconds:
<pawn>
someFunction()
{
CreateTimer(3.0, Timer_PrintMessageFiveTimes, _, TIMER_REPEAT);
}

public Action:Timer_PrintMessageFiveTimes(Handle:timer)
{
// Create a global variable visible only in the local scope (this function).
static numPrinted = 0;

if (numPrinted >= 5) {
return Plugin_Stop;
}

PrintToServer("Warning! This is a message.");
numPrinted++;

return Plugin_Continue;
}</pawn>

Note that <tt>Plugin_Stop</tt> stops the timer, and <tt>Plugin_Continue</tt> allows it to continue repeating.

=Passing Data=
==Simple Values==
As mentioned earlier, timers let you pass values on to the callback function. This value can be any type. For example, let's say we want to print a message to a player fifteen seconds after they connect. However, we want to cancel the timer if the player disconnects. Implementing this is very easy:

<pawn>
new Handle:WelcomeTimers[MAXPLAYERS+1]

public OnClientPutInServer(client)
{
WelcomeTimers[client] = CreateTimer(15.0, WelcomePlayer, client)
}

public OnClientDisconnect(client)
{
if (WelcomeTimers[client] != INVALID_HANDLE)
{
KillTimer(WelcomeTimers[client])
WelcomeTimers[client] = INVALID_HANDLE
}
}

public Action:WelcomePlayer(Handle:timer, any:client)
{
PrintToConsole(client, "Welcome to the server!")
WelcomeTimers[client] = INVALID_HANDLE
}</pawn>

==Handles==
If you want to pass a Handle as a value, you have the option of using <tt>TIMER_HNDL_CLOSE</tt>, which will automatically call <tt>CloseHandle()</tt> for you once the timer dies.

==Data Packs==
Data packs are packable structures that can be used to hold asynchronous data (data that must be saved and unpacked for later). They are especially useful for timers, and thus there exists a helper function, called <tt>CreateDataTimer()</tt>, which creates a timer using a data pack handle. The handle is created and closed automatically for you.

The above example could be rewritten as:
<pawn>
new Handle:WelcomeTimers[MAXPLAYERS+1]

public OnClientPutInServer(client)
{
new Handle:pack
WelcomeTimers[client] = CreateDataTimer(15.0, WelcomePlayer, pack)
WritePackCell(pack, client)
WritePackString(pack, "Welcome to the server!")
}

public OnClientDisconnect(client)
{
if (WelcomeTimers[client] != INVALID_HANDLE)
{
KillTimer(WelcomeTimers[client])
WelcomeTimers[client] = INVALID_HANDLE
}
}

public Action:WelcomePlayer(Handle:timer, Handle:pack)
{
decl String:str[128]
new client

/* Set to the beginning and unpack it */
ResetPack(pack)
client = ReadPackCell(pack)
ReadPackString(pack, str, sizeof(str))

PrintToConsole(client, "%s", str)
WelcomeTimers[client] = INVALID_HANDLE
}</pawn>

=Notes=
==Accuracy==
The smallest possible interval is 0.1 seconds. Timers have high precision (floating point) but low accuracy, as the current time is based on the in-game tick count, not the system clock. This has two implications:
*If the server is paused (not ticking), timers will not run.
*The server will not always tick at an exact interval.

For example, a 1.234 second interval timer starting from time <tt>t</tt> might not tick until <tt>t+1.242</tt> at a tickrate of 66 ticks per second.

==Timer Death==
All timers are guaranteed to die either by:
*<tt>CloseHandle()</tt> being called (or on plugin unload);
*<tt>KillTimer()</tt> being called;
*<tt>Plugin_Stop</tt> being returned from a repeatable timer;
*<tt>TriggerTimer()</tt> being called on a one-time timer;
*Execution of a one-time timer finishes.

When a timer dies, if <tt>TIMER_HNDL_CLOSE</tt> is set, the Handle will always be closed with the permissions that <tt>CloseHandle()</tt> uses by default. Since timers cannot be cloned, there should be no ownership issues.

==Changing Intervals==
The interval of a timer cannot be changed as of this writing. The timer must be killed and a new one created.

==AMX Mod X==
Unlike [[AMX Mod X]]'s <tt>set_task</tt> function, you cannot pass arrays using <tt>CreateTimer</tt>. To accomplish this, you should use the data pack functionality explained above.

Similarly, there are no flags for counted repeats (non-infinite loops) or timers based on the map start or end. These must be done manually.

=External Links=
*[http://www.sourcemod.net/devlog/?p=130 On Timer Design, Part 3] (SourceMod DevLog)
*[http://www.sourcemod.net/devlog/?p=119 On Timer Design, Part 2] (SourceMod DevLog)
*[http://www.sourcemod.net/devlog/?p=118 On Timer Design, Part 1] (SourceMod DevLog)

[[Category:SourceMod Scripting]]

{{LanguageSwitch}}

Timers (SourceMod Scripting)

2012-07-17T20:15:24Z

Berni: /* Simple Values */

Timers in [[SourceMod]] are timed events that occur once or repeatedly at a given interval.

=Introduction=
Timers allow you to set an interval, a function to use as the event callback, and an optional Handle to pass through the callback. This is useful for saving data asynchronously.

All timer functions are in <tt>plugins/include/timers.inc</tt>.

=Basic Usage=
==One-Time Timers==
One-time timers are timers that only execute once. An example of a one-time timer might look like:

<pawn>public OnPluginStart()
{
CreateTimer(5.0, LoadStuff)
}

public Action:LoadStuff(Handle:timer)
{
PrintToServer("Loading stuff!")
}</pawn>

This code will print "Loading stuff!" to the server console five seconds after the map loads. The return value has no meaning for one-time timers.

==Repeatable Timers==
Repeatable timers execute infinitely many times, once every interval. Based on the return value, they either continue or cancel.

For example, say you want to display a message five times, once every three seconds:
<pawn>
someFunction()
{
CreateTimer(3.0, Timer_PrintMessageFiveTimes, _, TIMER_REPEAT);
}

public Action:Timer_PrintMessageFiveTimes(Handle:timer)
{
// Create a global variable visible only in the local scope (this function).
static numPrinted = 0;

if (numPrinted >= 5) {
return Plugin_Stop;
}

PrintToServer("Warning! This is a message.");
numPrinted++;

return Plugin_Continue;
}</pawn>

Note that <tt>Plugin_Stop</tt> stops the timer, and <tt>Plugin_Continue</tt> allows it to continue repeating.

=Passing Data=
==Simple Values==
As mentioned earlier, timers let you pass values on to the callback function. This value can be any type. For example, let's say we want to print a message to a player fifteen seconds after they connect. However, we want to cancel the timer if the player disconnects. Implementing this is very easy:

<pawn>
new Handle:WelcomeTimers[MAXPLAYERS+1]

public OnClientPutInServer(client)
{
WelcomeTimers[client] = CreateTimer(15.0, WelcomePlayer, client)
}

public OnClientDisconnect(client)
{
if (WelcomeTimers[client] != INVALID_HANDLE)
{
KillTimer(WelcomeTimers[client])
WelcomeTimers[client] = INVALID_HANDLE
}
}

public Action:WelcomePlayer(Handle:timer, any:client)
{
PrintToConsole(client, "Welcome to the server!")
WelcomeTimers[client] = INVALID_HANDLE
}</pawn>

==Handles==
If you want to pass a Handle as a value, you have the option of using <tt>TIMER_HNDL_CLOSE</tt>, which will automatically call <tt>CloseHandle()</tt> for you once the timer dies.

==Data Packs==
Data packs are packable structures that can be used to hold asynchronous data (data that must be saved and unpacked for later). They are especially useful for timers, and thus there exists a helper function, called <tt>CreateDataTimer()</tt>, which creates a timer using a data pack handle. The handle is created and closed automatically for you.

The above example could be rewritten as:
<pawn>#define MAX_PLAYERS 256

new Handle:WelcomeTimers[MAX_PLAYERS+1]

public OnClientPutInServer(client)
{
new Handle:pack
WelcomeTimers[client] = CreateDataTimer(15.0, WelcomePlayer, pack)
WritePackCell(pack, client)
WritePackString(pack, "Welcome to the server!")
}

public OnClientDisconnect(client)
{
if (WelcomeTimers[client] != INVALID_HANDLE)
{
KillTimer(WelcomeTimers[client])
WelcomeTimers[client] = INVALID_HANDLE
}
}

public Action:WelcomePlayer(Handle:timer, Handle:pack)
{
decl String:str[128]
new client

/* Set to the beginning and unpack it */
ResetPack(pack)
client = ReadPackCell(pack)
ReadPackString(pack, str, sizeof(str))

PrintToConsole(client, "%s", str)
WelcomeTimers[client] = INVALID_HANDLE
}</pawn>

=Notes=
==Accuracy==
The smallest possible interval is 0.1 seconds. Timers have high precision (floating point) but low accuracy, as the current time is based on the in-game tick count, not the system clock. This has two implications:
*If the server is paused (not ticking), timers will not run.
*The server will not always tick at an exact interval.

For example, a 1.234 second interval timer starting from time <tt>t</tt> might not tick until <tt>t+1.242</tt> at a tickrate of 66 ticks per second.

==Timer Death==
All timers are guaranteed to die either by:
*<tt>CloseHandle()</tt> being called (or on plugin unload);
*<tt>KillTimer()</tt> being called;
*<tt>Plugin_Stop</tt> being returned from a repeatable timer;
*<tt>TriggerTimer()</tt> being called on a one-time timer;
*Execution of a one-time timer finishes.

When a timer dies, if <tt>TIMER_HNDL_CLOSE</tt> is set, the Handle will always be closed with the permissions that <tt>CloseHandle()</tt> uses by default. Since timers cannot be cloned, there should be no ownership issues.

==Changing Intervals==
The interval of a timer cannot be changed as of this writing. The timer must be killed and a new one created.

==AMX Mod X==
Unlike [[AMX Mod X]]'s <tt>set_task</tt> function, you cannot pass arrays using <tt>CreateTimer</tt>. To accomplish this, you should use the data pack functionality explained above.

Similarly, there are no flags for counted repeats (non-infinite loops) or timers based on the map start or end. These must be done manually.

=External Links=
*[http://www.sourcemod.net/devlog/?p=130 On Timer Design, Part 3] (SourceMod DevLog)
*[http://www.sourcemod.net/devlog/?p=119 On Timer Design, Part 2] (SourceMod DevLog)
*[http://www.sourcemod.net/devlog/?p=118 On Timer Design, Part 1] (SourceMod DevLog)

[[Category:SourceMod Scripting]]

{{LanguageSwitch}}

Timers (SourceMod Scripting)

2012-07-17T13:34:26Z

Berni: /* Repeatable Timers */

Timers in [[SourceMod]] are timed events that occur once or repeatedly at a given interval.

=Introduction=
Timers allow you to set an interval, a function to use as the event callback, and an optional Handle to pass through the callback. This is useful for saving data asynchronously.

All timer functions are in <tt>plugins/include/timers.inc</tt>.

=Basic Usage=
==One-Time Timers==
One-time timers are timers that only execute once. An example of a one-time timer might look like:

<pawn>public OnPluginStart()
{
CreateTimer(5.0, LoadStuff)
}

public Action:LoadStuff(Handle:timer)
{
PrintToServer("Loading stuff!")
}</pawn>

This code will print "Loading stuff!" to the server console five seconds after the map loads. The return value has no meaning for one-time timers.

==Repeatable Timers==
Repeatable timers execute infinitely many times, once every interval. Based on the return value, they either continue or cancel.

For example, say you want to display a message five times, once every three seconds:
<pawn>
someFunction()
{
CreateTimer(3.0, Timer_PrintMessageFiveTimes, _, TIMER_REPEAT);
}

public Action:Timer_PrintMessageFiveTimes(Handle:timer)
{
// Create a global variable visible only in the local scope (this function).
static numPrinted = 0;

if (numPrinted >= 5) {
return Plugin_Stop;
}

PrintToServer("Warning! This is a message.");
numPrinted++;

return Plugin_Continue;
}</pawn>

Note that <tt>Plugin_Stop</tt> stops the timer, and <tt>Plugin_Continue</tt> allows it to continue repeating.

=Passing Data=
==Simple Values==
As mentioned earlier, timers let you pass values on to the callback function. This value can be any type. For example, let's say we want to print a message to a player fifteen seconds after they connect. However, we want to cancel the timer if the player disconnects. Implementing this is very easy:

<pawn>#define MAX_PLAYERS 256

new Handle:WelcomeTimers[MAX_PLAYERS+1]

public OnClientPutInServer(client)
{
WelcomeTimers[client] = CreateTimer(15.0, WelcomePlayer, client)
}

public OnClientDisconnect(client)
{
if (WelcomeTimers[client] != INVALID_HANDLE)
{
KillTimer(WelcomeTimers[client])
WelcomeTimers[client] = INVALID_HANDLE
}
}

public Action:WelcomePlayer(Handle:timer, any:client)
{
PrintToConsole(client, "Welcome to the server!")
WelcomeTimers[client] = INVALID_HANDLE
}</pawn>

==Handles==
If you want to pass a Handle as a value, you have the option of using <tt>TIMER_HNDL_CLOSE</tt>, which will automatically call <tt>CloseHandle()</tt> for you once the timer dies.

==Data Packs==
Data packs are packable structures that can be used to hold asynchronous data (data that must be saved and unpacked for later). They are especially useful for timers, and thus there exists a helper function, called <tt>CreateDataTimer()</tt>, which creates a timer using a data pack handle. The handle is created and closed automatically for you.

The above example could be rewritten as:
<pawn>#define MAX_PLAYERS 256

new Handle:WelcomeTimers[MAX_PLAYERS+1]

public OnClientPutInServer(client)
{
new Handle:pack
WelcomeTimers[client] = CreateDataTimer(15.0, WelcomePlayer, pack)
WritePackCell(pack, client)
WritePackString(pack, "Welcome to the server!")
}

public OnClientDisconnect(client)
{
if (WelcomeTimers[client] != INVALID_HANDLE)
{
KillTimer(WelcomeTimers[client])
WelcomeTimers[client] = INVALID_HANDLE
}
}

public Action:WelcomePlayer(Handle:timer, Handle:pack)
{
decl String:str[128]
new client

/* Set to the beginning and unpack it */
ResetPack(pack)
client = ReadPackCell(pack)
ReadPackString(pack, str, sizeof(str))

PrintToConsole(client, "%s", str)
WelcomeTimers[client] = INVALID_HANDLE
}</pawn>

=Notes=
==Accuracy==
The smallest possible interval is 0.1 seconds. Timers have high precision (floating point) but low accuracy, as the current time is based on the in-game tick count, not the system clock. This has two implications:
*If the server is paused (not ticking), timers will not run.
*The server will not always tick at an exact interval.

For example, a 1.234 second interval timer starting from time <tt>t</tt> might not tick until <tt>t+1.242</tt> at a tickrate of 66 ticks per second.

==Timer Death==
All timers are guaranteed to die either by:
*<tt>CloseHandle()</tt> being called (or on plugin unload);
*<tt>KillTimer()</tt> being called;
*<tt>Plugin_Stop</tt> being returned from a repeatable timer;
*<tt>TriggerTimer()</tt> being called on a one-time timer;
*Execution of a one-time timer finishes.

When a timer dies, if <tt>TIMER_HNDL_CLOSE</tt> is set, the Handle will always be closed with the permissions that <tt>CloseHandle()</tt> uses by default. Since timers cannot be cloned, there should be no ownership issues.

==Changing Intervals==
The interval of a timer cannot be changed as of this writing. The timer must be killed and a new one created.

==AMX Mod X==
Unlike [[AMX Mod X]]'s <tt>set_task</tt> function, you cannot pass arrays using <tt>CreateTimer</tt>. To accomplish this, you should use the data pack functionality explained above.

Similarly, there are no flags for counted repeats (non-infinite loops) or timers based on the map start or end. These must be done manually.

=External Links=
*[http://www.sourcemod.net/devlog/?p=130 On Timer Design, Part 3] (SourceMod DevLog)
*[http://www.sourcemod.net/devlog/?p=119 On Timer Design, Part 2] (SourceMod DevLog)
*[http://www.sourcemod.net/devlog/?p=118 On Timer Design, Part 1] (SourceMod DevLog)

[[Category:SourceMod Scripting]]

{{LanguageSwitch}}

Timers (SourceMod Scripting)

2012-07-17T13:33:52Z

Berni: /* Repeatable Timers */

Timers in [[SourceMod]] are timed events that occur once or repeatedly at a given interval.

=Introduction=
Timers allow you to set an interval, a function to use as the event callback, and an optional Handle to pass through the callback. This is useful for saving data asynchronously.

All timer functions are in <tt>plugins/include/timers.inc</tt>.

=Basic Usage=
==One-Time Timers==
One-time timers are timers that only execute once. An example of a one-time timer might look like:

<pawn>public OnPluginStart()
{
CreateTimer(5.0, LoadStuff)
}

public Action:LoadStuff(Handle:timer)
{
PrintToServer("Loading stuff!")
}</pawn>

This code will print "Loading stuff!" to the server console five seconds after the map loads. The return value has no meaning for one-time timers.

==Repeatable Timers==
Repeatable timers execute infinitely many times, once every interval. Based on the return value, they either continue or cancel.

For example, say you want to display a message five times, once every three seconds:
<pawn>
DoMessage()
{
CreateTimer(3.0, Timer_PrintMessageFiveTimes, _, TIMER_REPEAT);
}

public Action:Timer_PrintMessageFiveTimes(Handle:timer)
{
// Create a global variable visible only in the local scope (this function).
static numPrinted = 0;

if (numPrinted >= 5) {
return Plugin_Stop;
}

PrintToServer("Warning! This is a message.");
numPrinted++;

return Plugin_Continue;
}</pawn>

Note that <tt>Plugin_Stop</tt> stops the timer, and <tt>Plugin_Continue</tt> allows it to continue repeating.

=Passing Data=
==Simple Values==
As mentioned earlier, timers let you pass values on to the callback function. This value can be any type. For example, let's say we want to print a message to a player fifteen seconds after they connect. However, we want to cancel the timer if the player disconnects. Implementing this is very easy:

<pawn>#define MAX_PLAYERS 256

new Handle:WelcomeTimers[MAX_PLAYERS+1]

public OnClientPutInServer(client)
{
WelcomeTimers[client] = CreateTimer(15.0, WelcomePlayer, client)
}

public OnClientDisconnect(client)
{
if (WelcomeTimers[client] != INVALID_HANDLE)
{
KillTimer(WelcomeTimers[client])
WelcomeTimers[client] = INVALID_HANDLE
}
}

public Action:WelcomePlayer(Handle:timer, any:client)
{
PrintToConsole(client, "Welcome to the server!")
WelcomeTimers[client] = INVALID_HANDLE
}</pawn>

==Handles==
If you want to pass a Handle as a value, you have the option of using <tt>TIMER_HNDL_CLOSE</tt>, which will automatically call <tt>CloseHandle()</tt> for you once the timer dies.

==Data Packs==
Data packs are packable structures that can be used to hold asynchronous data (data that must be saved and unpacked for later). They are especially useful for timers, and thus there exists a helper function, called <tt>CreateDataTimer()</tt>, which creates a timer using a data pack handle. The handle is created and closed automatically for you.

The above example could be rewritten as:
<pawn>#define MAX_PLAYERS 256

new Handle:WelcomeTimers[MAX_PLAYERS+1]

public OnClientPutInServer(client)
{
new Handle:pack
WelcomeTimers[client] = CreateDataTimer(15.0, WelcomePlayer, pack)
WritePackCell(pack, client)
WritePackString(pack, "Welcome to the server!")
}

public OnClientDisconnect(client)
{
if (WelcomeTimers[client] != INVALID_HANDLE)
{
KillTimer(WelcomeTimers[client])
WelcomeTimers[client] = INVALID_HANDLE
}
}

public Action:WelcomePlayer(Handle:timer, Handle:pack)
{
decl String:str[128]
new client

/* Set to the beginning and unpack it */
ResetPack(pack)
client = ReadPackCell(pack)
ReadPackString(pack, str, sizeof(str))

PrintToConsole(client, "%s", str)
WelcomeTimers[client] = INVALID_HANDLE
}</pawn>

=Notes=
==Accuracy==
The smallest possible interval is 0.1 seconds. Timers have high precision (floating point) but low accuracy, as the current time is based on the in-game tick count, not the system clock. This has two implications:
*If the server is paused (not ticking), timers will not run.
*The server will not always tick at an exact interval.

For example, a 1.234 second interval timer starting from time <tt>t</tt> might not tick until <tt>t+1.242</tt> at a tickrate of 66 ticks per second.

==Timer Death==
All timers are guaranteed to die either by:
*<tt>CloseHandle()</tt> being called (or on plugin unload);
*<tt>KillTimer()</tt> being called;
*<tt>Plugin_Stop</tt> being returned from a repeatable timer;
*<tt>TriggerTimer()</tt> being called on a one-time timer;
*Execution of a one-time timer finishes.

When a timer dies, if <tt>TIMER_HNDL_CLOSE</tt> is set, the Handle will always be closed with the permissions that <tt>CloseHandle()</tt> uses by default. Since timers cannot be cloned, there should be no ownership issues.

==Changing Intervals==
The interval of a timer cannot be changed as of this writing. The timer must be killed and a new one created.

==AMX Mod X==
Unlike [[AMX Mod X]]'s <tt>set_task</tt> function, you cannot pass arrays using <tt>CreateTimer</tt>. To accomplish this, you should use the data pack functionality explained above.

Similarly, there are no flags for counted repeats (non-infinite loops) or timers based on the map start or end. These must be done manually.

=External Links=
*[http://www.sourcemod.net/devlog/?p=130 On Timer Design, Part 3] (SourceMod DevLog)
*[http://www.sourcemod.net/devlog/?p=119 On Timer Design, Part 2] (SourceMod DevLog)
*[http://www.sourcemod.net/devlog/?p=118 On Timer Design, Part 1] (SourceMod DevLog)

[[Category:SourceMod Scripting]]

{{LanguageSwitch}}

SRCDS Hardening

2011-07-31T10:48:39Z

Berni: /* Linux File Premission Setup */

= Securing your server =
== General Tips ==
* Do not enable sv_cheats, do not run any plugins that do so.
* [http://www.goodpassword.com/ Use secure passwords.] This should be obvious, but your clan name is not a good rcon password, nor is "password".
* Don't blindly give admin out. Depending on what flags you give people, you could allow them to take over the server.
* Don't piss people off. Many servers get attacked because players get pissed off that admins are abusing them.

== File Permissions ==
If you are running your own server (not renting one from a GSP), there are some things you can do to prevent many of the more malicious exploits. The basic theory here is to give srcds as little access to the machine as possible. It only needs write access to the following directories:
* downloads/
* cache/
* addons/sourcemod/gamedata/
* addons/sourcemod/data/
* addons/sourcemod/logs/
* logs/
Note that some plugins rely on being able to write to directories other then these, and permissions may break them. At the very least, it's a good idea to make sure srcds is running as a user that does not have permission to change anything outside of it's own directory. That will prevent your machine from being comprised and made into a botnet client.

== Linux File Permission Setup ==

Create a unprivileged users to run the server.

'''useradd -m -s /bin/bash -d /home/srcds srcds'''

* useradd = Linux command to add users
* -m = Creates the user's home directory if it does not exist.
* -s /bin/bash = Users login shell ( if you are not sure what this should be leave it blank)
* -d /home/srcds = Location of users home directory.

Set a password for the account make sure it is secure.

'''passwd srcds'''

* passwd srcds = Linux change password command

Now move your existing srcds install to the new home dir or do a fresh install.

'''cp -r /path/to/old/install /path/to/new/users/home'''

*cp = Linux copy command

'''chown -R srcds:scrds'''

* chown = Linux command to change owner of files
* -R = Changes all the directory you are in and all subdirectories

The last things you want to do is make the files read only and run the srcds as the new user.

'''chmod -R 444 * /path/to/srcds/'''

*chmod = Linux change permission command
* -R = Change files and directories recursively
* 444 = Read only
* <nowiki>*</nowiki> = wild card[http://www.tuxfiles.org/linuxhelp/wildcards.html]

Now you need to make the files mentioned above to read and write and a few exec.

Read Write (chmod 644):
* downloads/
* cache/
* addons/sourcemod/gamedata/
* addons/sourcemod/data/
* addons/sourcemod/logs/
* logs/

Read and exec (cmond 744):
* /orangebox/srcds_linux
* /orangebox/srcds_run

== Plugins ==
There are a few plugins that can be installed to prevent exploits. Some of the recommended ones include [https://forums.alliedmods.net/showthread.php?p=841590 Rcon locker / exploit fix], [https://forums.alliedmods.net/showthread.php?p=779851 Forlix FloodCheck], [https://forums.alliedmods.net/showthread.php?t=109453 D-FENS], and [http://www.sourceop.com/modules.php?name=Downloads&d_op=viewdownload&cid=9 DAF].

Many of the Eventscripts plugins that claim to fix exploits are mostly useless at best, or actively harmful to your server at worst. If you are running the plugins listed in the previous paragraph, you do not need anything else to protect your server. Installing extra plugins other then those will likely cause issues with your server, and is not recommended.

= Current Exploits =

== Crashes ==

=== Invalid RCON Crash ===
SRCDS will crash on some machines if you attempt to use an incorrect rcon password too many times. It seems that some machines are affected by this, while others are not. Valve has been notified a few times, and has been unwilling/unable to fix this.

*Fix: Firewall off rcon (TCP port 27015) from everyone except for certain whitelisted IP's.

=== HalfConnected Crash ===
If a command is received as the client is connecting, the server will crash or enter a state where it does not accept new connections, but has not crashed. This exploit can also happen if you remove the players entity, which shouldn't happen under normal circumstances. Valve has been notified, and is unwilling to fix this.

*Fix: [https://forums.alliedmods.net/showthread.php?p=841590 Rcon locker / exploit fix]

=== Disconnect Crash ===
Using modified clients, it is possible to send disconnect messages with large numbers of special characters. These have a variety of effects, including crashing the server or crashing all connected clients.

*Fix: [https://forums.alliedmods.net/showthread.php?p=841590 Rcon locker / exploit fix]

=== "K" packet Crash ===
Using modified clients, it is possible to send a Steam auth packet that contains an invalid header length. Upon receiving this packet, the server will crash.

*Fix: 4/19/10: Apply the latest steam beta patch. Run hldsupdatetool with "-beta cs0419" to get this.

== Takeover ==
=== ent_fire server takeover ===
If cheats are enabled on a server, the point_servercommand entity can be created, which can be used by clients to execute rcon commands on the server. Premade scripts exist for this that will change the rcon password, and add the client as an admin. Valve has been notified, and is unwilling to fix this.

*Fix: [https://forums.alliedmods.net/showthread.php?p=841590 Rcon locker / exploit fix] will prevent the rcon password from being changed, as well as disallowing the point_servercommand entity. The alternative is to not run with sv_cheats 1, and take other measures to ensure it is never enabled.
=== ES_Tools changelevel exploit ===
The "changelevel" command can be abused when ES_tools is running to execute commands on the server

*Fix: [https://forums.alliedmods.net/showthread.php?p=841590 Rcon locker / exploit fix] will prevent this. Alternatively, remove es_tools if at all possible.
=== File upload/download ===
It's possible to convince the server to let you upload or download random files from it. Valve has been attempting to fix this, but there still seem to be some workarounds to their fixes.

If you are running your own servers (not rented from a GSP), you can set file permissions on them to fix the upload issue.

*Fix: [https://forums.alliedmods.net/showthread.php?t=109453 dfens] will prevent this.

== Lag/DOS ==
=== A2C_PRINT Spam ===
SRCDS does not do any sort of authentication on A2C_PRINT messages. This means that anyone can print messages to the servers console, simply by sending UDP packets. It seems this is a legacy feature, and is not actually used by anything. Valve has been notified, and doesn't see this as a problem.

*Fix: Block any packets beginning with \xFF\xFF\xFF\xFF\x6C or run [http://www.sourceop.com/modules.php?name=Downloads&d_op=viewdownload&cid=9 DAF]
=== A2S_INFO Spam ===
If large numbers of A2S_INFO packets are sent at the server, the FPS will severely drop, making the server essentially unplayable. Since these packets can be spoofed, rate limiting one IP is fairly useless

*Fix: You can use sv_max_queries_sec_global to limit this, though that would mean your server would be invisible on the master server list while the attacks are in progress. [https://forums.alliedmods.net/showthread.php?t=114787 Query Cache] (a SM extension) will also work.
*'''Fixed in:''' TF2 (partial fix) (August 13, 2009)

=== Command spam ===
Various commands built into the game can be spammed to lag or crash the server. Some of these commands can cause the ingame physiscs to freeze up. The fix for most of these is quite simple, just disable them by adding the cheats flag. Valve has been notified, and fixes commands in the occasional patch.

*Fix: [https://forums.alliedmods.net/showthread.php?p=779851 Forlix FloodCheck] can be used to kick players who have been caught spamming, [https://forums.alliedmods.net/showthread.php?p=841590 Rcon locker / exploit fix] adds the cheats flag to most of the known commands. [https://forums.alliedmods.net/showthread.php?p=880328 Scortched Earth] will disable all commands except for those on a whitelist, which is the "better" way to fix this, but can break other addons.

=== Bell characters in name ===
If your name contains bell characters, this can be used to lag the server on windows.

Fix: [https://forums.alliedmods.net/showthread.php?p=841590 Rcon locker / exploit fix] will kick players with these characters in their name.
=== Force fullupdate ===
If you send an empty packet to the server, you can force it to send you the full state of the game, which will lag the server if done enough. Valve has been notified, and is unwilling to fix this.

*Fix: [http://www.sourceop.com/modules.php?name=Downloads&d_op=viewdownload&cid=9 DAF] has a partial workaround

== Annoyances ==
=== Teleport exploit ===
If you use very large values for your mouse sensitivity, you can overwrite your X and Y coordinates, letting you teleport around. This has the potential to crash the server as well. Valve has been notified, and is unwilling to fix this.

*Fix: [https://forums.alliedmods.net/showthread.php?p=841590 Rcon locker / exploit fix] has a partial fix for this.
*'''Fixed in:''' TF2 (July 14 2009)
=== Clientside plugins ===
The VSP interface built into the game can be used to load plugins on the game client, allowing them to change cheat-flagged cvars. This can allow them to have wallhacks, or alter weapon recharge rates. Valve has been notified, and is unwilling to fix this.

*Fix: [https://forums.alliedmods.net/showthread.php?p=841590 Rcon locker / exploit fix] has a partial fix for this.
=== Empty name / unconnected ===
Players can set their name to an empty string using the setinfo console command. Some admin plugins will be unable to kick or perform other actions on them. Valve has been notified, and is unwilling to fix this.

*Fix: [https://forums.alliedmods.net/showthread.php?p=841590 Rcon locker / exploit fix] will automatically kick anyone found to have an empty name
=== Special name characters ===
If certain special characters are added to your name, you can create messages that appear to be sent by the server administrator.

*Fix: [https://forums.alliedmods.net/showthread.php?p=841590 Rcon locker / exploit fix]

= Fixed Exploits =
== Memory corruption crash ==
See [http://aluigi.altervista.org/adv/sourcefraghof-adv.txt this link]

Fix: none
*'''Fixed in:''' Orangebox, L4D (August 21 2009) CSS (August 25 2009)

== Arbitrary file upload ==
See [http://aluigi.altervista.org/adv/sourceupfile-adv.txt this link]

Fix: [https://forums.alliedmods.net/showthread.php?p=905647 File upload exploit fix]
*'''Fixed in:''' Orangebox, L4D (August 21 2009) CSS (August 25 2009)

== "ProcessClientInfo: SourceTV can not connect to game directly" crash ==
See [http://aluigi.altervista.org/adv/sourcenotvnull-adv.txt this link]

Fix: Add "tv_enable 1" to cfg/autoexec.cfg, and (optionally) "tv_enable 0" to server.cfg (You only need tv_enable 0 if you don't want sourcetv)
*'''Fixed in:''' Orangebox, L4D (August 21 2009) CSS (August 25 2009)

== Player disconnect crash ==
See [http://aluigi.altervista.org/adv/sourcefs-adv.txt this link]

Fix: [https://forums.alliedmods.net/showthread.php?p=841590 Rcon locker / exploit fix] has what may be a partial fix.
*'''Fixed in:''' Orangebox, L4D (August 21 2009) CSS (August 25 2009)