AlliedModders Wiki - User contributions [en]

What

2007-07-15T16:01:42Z

Faluco: Reverted edits by Lu1Cg0 (Talk); changed back to last version by BAILOPAN

{{Gaben|what|[[what?]]}}

[[Image:What.png|300px|thumb|A up-close photograph of What after reaching the inner core.]]

==what==
===hello===
==is==
==this==

"What" pages are joke pages that are created as tests, alternatives to talk discussions, jokes, or anything that's off-topic. For example, [[User:BAILOPAN]] is also [[User:BAILOPAN (What)]].

what

==Childhood==
What was given to the first humans by BAILOPAN. The early humans rubbed it on their bodies for warmth.
As humans evolved and split into two distinct races: the intelligent and the morbidly stupid, what split as well. The first type of what was used by the intelligent to confuse the morbidly stupid even more. The second type was used by the morbidly stupid as a form of communication, somewhat like a grunt.

==Maturity==
BAILOPAN saw that for true intelligent expansion, humans needed other questions such as how and where. He created them and gave them to the morbidly stupid. The morbidly stupid took the new questions and hit each other with them. BAILOPAN laughed and force lightning'd the poor fools. As a joke he showed his true form while utterly destroying them. They proclaimed him the devil and formed 17 distinct religions around him.

What managed to get some alone time with how and where. From this holy union came the word whereforewhatthefuck...and porn. Greentryst saw the porn (over BAILOPAN's shoulder) and declared that the world was good.

Category:3rd Party Modules (AMX Mod X)

2007-07-15T15:56:32Z

Faluco: Reverted edits by LbgYhi (Talk); changed back to last version by BAILOPAN

[[Category:AMX Mod X]]

Debugging Plugins (AMX Mod X)

2007-07-15T15:55:50Z

Faluco: Reverted edits by XpyPru (Talk); changed back to last version by BAILOPAN

[[AMX Mod X]] features a greatly enhanced plugin debugger over AMX Mod. If your plugin is giving runtime errors, you should enable the debugger by opening amxmodx/configs/plugins.ini and appending " debug" to your plugin's entry, like so:

<pre>
myplugin.amxx debug
</pre>

When you get a runtime error, it will show a full trace of the problem:

<pre>
L 09/15/2004 - 17:38:17: [AMXX] Run time error 4 (index out of bounds)
on line 46 (file "debug.sma").
L 09/15/2004 - 17:38:17: [AMXX] Debug Trace =>
L 09/15/2004 - 17:38:17: [AMXX] [0] Line 40, File "debug.sma"
L 09/15/2004 - 17:38:17: [AMXX] [1] Line 25, File "debug.sma"
</pre>

This type of error is called an AMX run time error - one that occured directly in the plugin interpreter. From this output, we know that this order of events happened:

#Line 25 was called in debug.sma
#Line 25 jumped to line 40 in debug.sma
#Line 40 jumped to line 46 in debug.sma, where an error occured

This specific error is one of the three common errors. It means that an array was improperly indexed, for example:

<pre>
new array[5]
new x = 500
array[x] = x
</pre>

Will generate this message. Another common message is AMX_ERR_STACKERR, which means your plugin ran out of memory. The fix for this is to increase the default size from 16KB:

<pre>
#pragma dynamic 32768
</pre>

This will increase the memory allocated to 128KB. The dynamic size is measured in cells, which are four bytes each (eight bytes on AMD64). AMX_ERR_STACKLOW and AMX_ERR_HEAPLOW are similar. The most common error by far is AMX_ERR_NATIVE, which means a native function in the AMX Mod X core signaled an error message.

Native errors are usually caused by some error checking failure on the part of the script programmer. For example, supplying an invalid connection id to an SQL function, or trying to modify the data on a player that doesn't exist. These errors will usually give a more helpful error message along with the call trace, as well as the actual name of the native that failed.

[[Category:Scripting (AMX Mod X)]]

Handles (SourceMod Scripting)

2007-03-25T19:22:51Z

Faluco: added KV handle type

Handles are a special data type used in [[SourceMod Scripting]]. They represent a single internal and unique object. For example, there are "File" Handles for files, and "Menu" Handles for menus, but they are both encapsulated under the "Handle" [[Tags (SourceMod Scripting)|tag]].

Handles are more than "pointers" from C or C++ because they have a ''reference count''. This means that the number of copies floating around in memory is tracked. The actual internal object is not destroyed until each copy is also destroyed.

Since SourcePawn does not have [[Garbage Collection]], Handles are a special way of intelligently allowing plugins and SourceMod to manage their own memory.

For more information on using Handles in the SourceMod API, see [[Handles (SourceMod API)]].

=Opening Handles=
Opening a Handle is usually done implicitly by a native function. For example, OpenDirectory opens a new Handle which is used in other Directory natives. This associates a ''type'' with the Handle. Trying to use a Directory Handle with any other non-Directory native will cause an error (HandleError_Type), because Handles are type checked.

<pawn>new Handle:hndl = OpenDirectory("addons/sourcemod/configs");
</pawn>

=Closing Handles=
==Basic operation==
Closing a Handle means seeing if the internal object can be removed from memory. For example, if a plugin creates an SQL connection, closing the Handle means closing and destroying the connection. This is almost always done using the CloseHandle() native function.

==When to close==
When a plugin unloads, all of its Handles are automatically destroyed. This does not mean, however, that closing Handles is optional. Consider the following code:

<pawn>stock bool:IsFileInFolder(const String:path[], const String:file[])
{
new String:path[PLATFORM_MAX_PATH];
new FileType:type;

new Handle:dir = OpenDirectory(path);
if (dir == INVALID_HANDLE)
{
return false;
}

while (ReadDirEntry(dir, path, sizeof(path), type))
{
if (type == FileType_File && StrEqual(path, file))
{
return true;
}
}

CloseHandle(dir);

return false;
}
</pawn>

This function searches a directory for a single file. If this function were to omit the call to CloseHandle, it would [[Memory Leak|leak memory]] every time it was called, and eventually the script would fill up with a large number of lingering Handles that were left open.

So, when do you close Handles? There are generally two rules of thumb to go by:
*If the native uses terminology such as "Opens a [...]" or "Creates a [...]" or gives explicit directions for closing.
*If the Handle represents a temporary object or piece of information, and you will no longer be using it.

Most of the time, you will be closing Handles. Check the Handle Type documentation at the end of this page.

==When you can't close==
There are a few Handle types that cannot be closed. The major one is the Handle which identifies a plugin. Plugins cannot unload themselves, and thus destroying their own Handles is not allowed.

Furthermore, a script cannot close a Handle that is owned by another plugin. This is for protection against API mistakes and accidental errors. For example, if a Handle is shared between two plugins, one accidental free could invalidate a Handle unexpectedly. To allow the sharing of Handles, see [[#Cloning Handles|Cloning Handles]].

==Reference counters==
Closing Handles does not always destroy the internal data. This is the case when Handles are [[#Cloning Handles|cloned]]. Each clone adds a ''reference count'' to the Handle, and closing each clone removes one reference count. The original object is only actually destroyed once the Handle has no more reference counters.

=Cloning Handles=
As briefly described earlier, there is a problem when scripts try to share Handles. Imagine this scenario:
*Plugin 'A' creates a Handle.
*Plugin 'B' received the Handle.
*Plugin 'A' is unloaded, and the Handle is destroyed.
*Plugin 'B' tries to use the Handle.

To prevent this, the CloneHandle native is provided. This function returns a ''new'' Handle that is a "copy" of the original. While their values won't be equal, they contain the same internal data. The data itself will not be destroyed until each copy and the original are closed with CloseHandle. It does not matter what order they are freed in, however, each Handle can only be freed once.

There are two ways of cloning. A plugin can either clone a Handle itself, and become the owner, or it can explicitly set a new owner. The difference is one of API design. Example of the former:
<pawn>new Handle:g_hSQL;
/**
* The other plugin calling this function must pass his ID in,
* but doesn't have to call CloneHandle()
*/
public Handle:GetGlobalSQL(Handle:otherPlugin)
{
return CloneHandle(g_hSQL, otherPlugin);
}

/**
* This code would appear in the other plugin
*/
new Handle:sql = GetGlobalSQL(myself);
/* ... */
CloseHandle(sql);
</pawn>

Example of the latter:
<pawn>new Handle:g_hSQL;
/**
* The calling plugin must call CloneHandle() himself.
*/
public Handle:GetGlobalSQL()
{
return g_hSQL;
}

/**
* This code would appear in the other plugin
*/
new Handle:sql = GetGlobalSQL();
if (sql != INVALID_HANDLE)
{
sql = CloneHandle(sql);
}
CloseHandle(sql);
</pawn>

=Handle Types=
The following is a list of the known Handle types provided by SourceMod and some documentation on each.
==BitBuffers==
{{HandleType|bf_read or bf_write|Only if explicitly stated|Only if it can also be closed|Core|bitbuffer.inc}}

There are four types of BitBuffer Handles. They are separated into ''bf_write'' (writable buffer) and ''bf_read'' (readable buffer). These are directly abstracted from their Half-Life 2 counterpart. Internally, there are separate Handle types for each; certain functions will use BitBuffer handles that cannot be freed.

==ConVars==
{{HandleType|ConVar|No|No|Core|console.inc}}

ConVar Handles are primarily used for getting and setting a console variable's value. They cannot be cloned nor deleted since they exist until SourceMod is shut down.

==Directories==
{{HandleType|Directory|Yes|Yes|Core|files.inc}}

Directory Handles are used for opening and enumerating the contents of a directory (folder) on the filesystem.

==Events==
{{HandleType|Event|No|No|Core|events.inc}}

Event Handles are used for getting and setting data in Half-Life 2 game events as well as for firing them. They can only be closed using CancelCreatedEvent() if the event was not fired for some reason.

==Files==
{{HandleType|File|Yes|Yes|Core|files.inc}}

File Handles are used for opening, reading from, writing to, and creating to files on the file system.

==Forwards==
{{HandleType|Forward|Yes|Only if explicitly stated|Core|functions.inc}}

Forward Handles are primarily used when calling functions inside a forward container. There are two types of forwards: global and private. Only private forwards can be cloned.

==Plugins==
{{HandleType|Plugin|No|No|Core|sourcemod.inc}}

Plugin Handles are used for the unique identification of a Plugin. They are owned by Core and cannot be cloned or closed by any other plugin or extension. However, plugins can use Handles for certain natives which enumerate or retrieve information on plugins.

Plugin Handles should not be cached globally, as plugins can become unloaded, and the Handle will be invalid.

==Plugin Iterators==
{{HandleType|PluginIter|Yes|No|Core|sourcemod.inc}}

Plugin Iterators allow you to walk over a list of plugins. They are intended for temporary use only.

==SMC Parsers==
{{HandleType|SMC Parser|Yes|No|Core|textparse.inc}}

SMC Parsers are Handles which contain a set of functions for hooking parse events in an SMC file. See more in [[SMC Parsing (SourceMod Scripting)]]. Since they directly reference functions in a plugin, they cannot be cloned.

==Timers==
{{HandleType|Timer|Yes|No|Core|timers.inc}}

Timers are temporary Handles which are automatically closed on any of the following events:
*The timer ends (via Plugin_Stop or being a one-time timer that is finished)
*The timer is killed via <tt>KillTimer</tt>
*The timer is closed via <tt>CloseHandle</tt>
*The timer's parent plugin unloads

==KeyValues==
{{HandleType|KeyValues|Yes|Yes|Core|keyvalues.inc}}

KeyValue Handles are wrapped around KeyValues pointers from the HL2SDK (tier1). Note that they are intended only for root nodes, and have special functions for sub-node iteration.

[[Category:SourceMod Development]]

Translations (SourceMod Scripting)

2007-01-11T01:27:36Z

Faluco: typo

[[SourceMod]], like its AMX Mod X predecessor, contains a built-in Multi-Lingual Translation layer ("ML"). The ML system is one of the secondary SourceMod systems designed to make the platform as flexible as possible. It fully supports UTF-8.

=Introduction=
The SourceMod ML System is based off the following terms:
*'''Languages''': Preset languages defined in <tt>configs\languages.cfg</tt>. If a language is not in this file, it cannot be translated until it is added and the in-memory translation cache rebuilt.
*'''Phrases'''/'''Translation Keys''': Short, generic key phrases used to identify a set of translations. These reside in configuration files in the <tt>translations</tt> folder. These are called <tt>translation files</tt>.
*'''Translations''': A given text translation of a phrase for a given language. These reside in a <tt>translation file</tt>.

'''Note''': Languages and Phrases are both case sensitive.

==File Format==
The ML Translation File format is in standard Valve configuration form. It is comprised of one master section, <tt>"Phrases</tt>,<tt>"</tt> which contains any number of named sub-sections. Each sub-section defines one named <tt>Phrase</tt>, which cannot itself have sub-sections. It allows the following properties:
*'''Key''': "#format"
**'''Value''': Comma-delimited, ordered pairs of indexes and format strings.
*'''Key''': Two-letter language code.
**'''Value''': Language translation string.

Example:
<pre>"Phrases"
{
"Welcome"
{
"en" "Welcome to SourceMod"
"es" "Bienvenidos a SourceMod"
}
}</pre>

In the above example, two translations are defined for the "Welcome" phrase - one for English, and one for Spanish. However, consider a phrase which needs certain words inserted, as in this contrived example:
<pre>"Phrases"
{
"Pants"
{
"en" "pants"
"es" "pantalones"
}
//Example: "Bail's pants are on fire"
"OnFire_plural"
{
"en" "%s's %s are on fire!"
"es" "¡Los %s de %s están en llamas!"
}
}</pre>

In the above example, the word orders have changed. English inserts the subject first, and the direct object second. Spanish associates ownership differently -- literally, ''the pants of Bail are on fire.'' This poses a problem for scripters, who always pass format parameters in one order. To solve this, the <tt>#format</tt> property was introduced. This pre-defines the order of format parameters. Example:
<pre>"Phrases"
{
//Example: "Bail's pants are on fire"
"OnFire_plural"
{
"#format" "{1:s},{2:s}"
"en" "{1}'s {2} are on fire!"
"es" "¡Los {2} de {1} están en llamas"
}
//Example: "Hello, Bail!"
"Hello"
{
"#format" "{1:s}"
"en" "Hello, {1}"
"es" "Hola, {1}"
}
}</pre>

The format string is comprised of comma delimited sections, each section enclosed in brackets. Each section has an ''index'' and a ''format specifier'', which are separated with a colon. Format specifiers follow the general rules of [[Format Class Functions (SourceMod Scripting)|formatting]], however, only the following types are currently allowed:
*'''d'''/'''i''': Digits/Integer display
*'''x''': Hexadecimal display
*'''f''': Floating point display
*'''s''': String display
*'''c''': Character display (UTF-8 compatible)

Note that currently, the special "%T" format type is not allowed inside a language translation string.

=Usage in a Plugin=
Plugins have two main methods of translation strings from the ML system: Inline translation, which is built into all string formatting functions, and manual translation, which is used to manually format a phrase.

Plugins must call <tt>LoadDictionary</tt> on each translation file they wish to use. Failure to do so will cause any translations to fail, even if another plugin loads the same file. This is to help prevent phrase-clashes between plugins.

==Inline Translations==
Inline translation works in any [[Format Class Functions (SourceMod Scripting)|format-class]] of functions. A new format specifier, '%T', is introduced, which instructs the format routine to insert a translated phrase. Unlike all other format specifiers, this requires a minimum of two parameters:
*'''1st Parameter''': A string containing the phrase to be translated.
*'''2nd Parameter''': One of the following:
**The <tt>LANG_SERVER</tt> constant, which specifies a translation to the default language.
**A player ID constant, which specifies a translation to the player's set language.
**A string containing the language's two letter international code.
*'''3rd Parameter and higher''': Inputs into the phrase's format specifiers, if necessary.

Examples of this are:
<pawn>new String:name[32], String:buffer[128];
GetClientName(client, name, sizeof(name));
PrintToPlayer(client, "[SourceMod] %T", "Hello", client, name);
Format(buffer, sizeof(buffer), "[SourceMod] %T", "Hello", LANG_SERVER, name);</pawn>

A breakdown of the format parameters:
*<tt>"Hello"</tt>: The phrase to translate.
*<tt>client/LANG_SERVER</tt>: Who to translate the phrase to.
*<tt>name</tt>: The "Hello" phrase requires one string, so this will appear in the translated phrase.

Lastly, there is a second form of inline translation, using '%t'. This is only allowed in functions which print directly to one or more clients. It eliminates the second parameter, and uses the original client specified. Example:
<pawn>PrintToPlayer(client, "[SourceMod] %t", "Hello", name);</pawn>

As you can see from this example, we did not have to specify the client index more than once. Thus, it is usually more convenient to use the limited '%t' version in functions such as <tt>PrintToPlayer</tt>. However, in functions which are not "player directed," such as <tt>Format</tt> or <tt>PrintToServer</tt>, only '%T' can be used.

==Manual Translations==
If you do not wish to use inlined translation, you can also use natives that manually translate a string to a given buffer. Documentation for these natives can be found in <tt>translation.inc</tt>.
*<tt>GetLanguageID()</tt>: Given a two letter language code, returns its internal ID. English ("en") is always ID 0. An empty string returns the server's language ID.
*<tt>GetLanguageCount()</tt>: Returns the number of languages in the translation cache.
*<tt>GetLanguageInfo()</tt>: Returns a language's name and code given its ID.
*<tt>Translate()</tt>: Translates a phrase given a language code, a translation file Handle (returned by <tt>LoadDictionary</tt>), and a phrase string.
*<tt>GetPlayerLanguage()</tt>: Returns the language ID a player is using.

Translations (SourceMod Scripting)

2007-01-11T01:24:17Z

Faluco: translation fix

[[SourceMod]], like its AMX Mod X predecessor, contains a built-in Multi-Lingual Translation layer ("ML"). The ML system is one of the secondary SourceMod systems designed to make the platform as flexible as possible. It fully supports UTF-8.

=Introduction=
The SourceMod ML System is based off the following terms:
*'''Languages''': Preset languages defined in <tt>configs\languages.cfg</tt>. If a language is not in this file, it cannot be translated until it is added and the in-memory translation cache rebuilt.
*'''Phrases'''/'''Translation Keys''': Short, generic key phrases used to identify a set of translations. These reside in configuration files in the <tt>translations</tt> folder. These are called <tt>translation files</tt>.
*'''Translations''': A given text translation of a phrase for a given language. These reside in a <tt>translation file</tt>.

'''Note''': Languages and Phrases are both case sensitive.

==File Format==
The ML Translation File format is in standard Valve configuration form. It is comprised of one master section, <tt>"Phrases</tt>,<tt>"</tt> which contains any number of named sub-sections. Each sub-section defines one named <tt>Phrase</tt>, which cannot itself have sub-sections. It allows the following properties:
*'''Key''': "#format"
**'''Value''': Comma-delimited, ordered pairs of indexes and format strings.
*'''Key''': Two-letter language code.
**'''Value''': Language translation string.

Example:
<pre>"Phrases"
{
"Welcome"
{
"en" "Welcome to SourceMod"
"es" "Beinvenidos a SourceMod"
}
}</pre>

In the above example, two translations are defined for the "Welcome" phrase - one for English, and one for Spanish. However, consider a phrase which needs certain words inserted, as in this contrived example:
<pre>"Phrases"
{
"Pants"
{
"en" "pants"
"es" "pantalones"
}
//Example: "Bail's pants are on fire"
"OnFire_plural"
{
"en" "%s's %s are on fire!"
"es" "¡Los %s de %s están en llamas!"
}
}</pre>

In the above example, the word orders have changed. English inserts the subject first, and the direct object second. Spanish associates ownership differently -- literally, ''the pants of Bail are on fire.'' This poses a problem for scripters, who always pass format parameters in one order. To solve this, the <tt>#format</tt> property was introduced. This pre-defines the order of format parameters. Example:
<pre>"Phrases"
{
//Example: "Bail's pants are on fire"
"OnFire_plural"
{
"#format" "{1:s},{2:s}"
"en" "{1}'s {2} are on fire!"
"es" "¡Los {2} de {1} están en llamas"
}
//Example: "Hello, Bail!"
"Hello"
{
"#format" "{1:s}"
"en" "Hello, {1}"
"es" "Hola, {1}"
}
}</pre>

The format string is comprised of comma delimited sections, each section enclosed in brackets. Each section has an ''index'' and a ''format specifier'', which are separated with a colon. Format specifiers follow the general rules of [[Format Class Functions (SourceMod Scripting)|formatting]], however, only the following types are currently allowed:
*'''d'''/'''i''': Digits/Integer display
*'''x''': Hexadecimal display
*'''f''': Floating point display
*'''s''': String display
*'''c''': Character display (UTF-8 compatible)

Note that currently, the special "%T" format type is not allowed inside a language translation string.

=Usage in a Plugin=
Plugins have two main methods of translation strings from the ML system: Inline translation, which is built into all string formatting functions, and manual translation, which is used to manually format a phrase.

Plugins must call <tt>LoadDictionary</tt> on each translation file they wish to use. Failure to do so will cause any translations to fail, even if another plugin loads the same file. This is to help prevent phrase-clashes between plugins.

==Inline Translations==
Inline translation works in any [[Format Class Functions (SourceMod Scripting)|format-class]] of functions. A new format specifier, '%T', is introduced, which instructs the format routine to insert a translated phrase. Unlike all other format specifiers, this requires a minimum of two parameters:
*'''1st Parameter''': A string containing the phrase to be translated.
*'''2nd Parameter''': One of the following:
**The <tt>LANG_SERVER</tt> constant, which specifies a translation to the default language.
**A player ID constant, which specifies a translation to the player's set language.
**A string containing the language's two letter international code.
*'''3rd Parameter and higher''': Inputs into the phrase's format specifiers, if necessary.

Examples of this are:
<pawn>new String:name[32], String:buffer[128];
GetClientName(client, name, sizeof(name));
PrintToPlayer(client, "[SourceMod] %T", "Hello", client, name);
Format(buffer, sizeof(buffer), "[SourceMod] %T", "Hello", LANG_SERVER, name);</pawn>

A breakdown of the format parameters:
*<tt>"Hello"</tt>: The phrase to translate.
*<tt>client/LANG_SERVER</tt>: Who to translate the phrase to.
*<tt>name</tt>: The "Hello" phrase requires one string, so this will appear in the translated phrase.

Lastly, there is a second form of inline translation, using '%t'. This is only allowed in functions which print directly to one or more clients. It eliminates the second parameter, and uses the original client specified. Example:
<pawn>PrintToPlayer(client, "[SourceMod] %t", "Hello", name);</pawn>

As you can see from this example, we did not have to specify the client index more than once. Thus, it is usually more convenient to use the limited '%t' version in functions such as <tt>PrintToPlayer</tt>. However, in functions which are not "player directed," such as <tt>Format</tt> or <tt>PrintToServer</tt>, only '%T' can be used.

==Manual Translations==
If you do not wish to use inlined translation, you can also use natives that manually translate a string to a given buffer. Documentation for these natives can be found in <tt>translation.inc</tt>.
*<tt>GetLanguageID()</tt>: Given a two letter language code, returns its internal ID. English ("en") is always ID 0. An empty string returns the server's language ID.
*<tt>GetLanguageCount()</tt>: Returns the number of languages in the translation cache.
*<tt>GetLanguageInfo()</tt>: Returns a language's name and code given its ID.
*<tt>Translate()</tt>: Translates a phrase given a language code, a translation file Handle (returned by <tt>LoadDictionary</tt>), and a phrase string.
*<tt>GetPlayerLanguage()</tt>: Returns the language ID a player is using.

AMX Mod X 1.76 Changes

2006-08-21T02:23:02Z

Faluco:

AMX Mod X 1.76 will be a small feature release and contains mostly bug fixes.
This changelog is brought to you by Batman and ramen.

=New Plugin File Features=
==Per-Map Plugin Files==
You can now have per-map plugin configuration files. AMX Mod X will automatically load any plugins listed in files having the following name: <tt>configs/maps/plugins-<map>.ini</tt>. Thus, <tt>de_dust</tt> specific plugins will be loaded from <tt>configs/maps/plugins-de_dust.ini</tt>.

Map-specific plugin files are parsed after the main plugins.ini is parsed, and after all secondary plugins-*.ini files are parsed in the <tt>configs</tt> folder. This means that a map-specific plugin listing inherits all settings above itself.

==Disabling Plugins==
A second feature was introduced to let users disable plugins per map. In any plugins-*.ini file, you may now add a "disabled" flag to a plugin name. This works like the "debug" flag. Example:
<code>
gaben.amxx disabled
</code>

This will block the plugin from being loaded from any other configuration file. So if <tt>plugins-de_dust.ini</tt> has the example line above, <tt>gaben.amxx</tt> will not be loaded from any other plugins file.

=New Scripting Features=
==Sorting==
AMX Mod X now has a comprehensive array sorting solution. You can sort using pre-defined array types, or use your own custom comparison functions. All of the sorting routines use the qsort() function from the C standard library, which is based on the [http://linux.wku.edu/~lamonml/algor/sort/quick.html Quick Sort] algorithm.

===Basic Sorting===
The follow basic sorting natives were added. These natives sort an array in-place using pre-defined comparison routines. You can change the sorting order using an optional third parameter. By default it is <tt>Sort_Ascending</tt>, and <tt>Sort_Descending</tt> is available as well.
*<tt>[http://www.amxmodx.org/funcwiki.php?go=func&id=1115 SortIntegers]()</tt> - Sorts an array of integers.
*<tt>[http://www.amxmodx.org/funcwiki.php?go=func&id=1116 SortFloats]()</tt> - Sorts an array of floats.
*<tt>[http://www.amxmodx.org/funcwiki.php?go=func&id=1117 SortStrings]()</tt> - Sorts an array of strings.

===Custom Sorting===
Furthermore, you can also define your own custom comparison functions and have the sorting algorithm run them for you. This can be useful in a variety of ways. For example, if you have an array of players and an array of those player's skills, you can easily sort the player ids by skill using this feature.

Custom sorting requires making a function which compares two elements of your array. Given elements e1 and e2:
*Return -1 to mean "e1 comes before e2"
*Return 0 to mean "e1 is equal to e2"
*Return 1 to mean "e1 comes after e2"
For example, a very simple formula to compare integers in this manner is: <tt>e1 - e2</tt>.

The custom sorting natives are:
*<tt>[http://www.amxmodx.org/funcwiki.php?go=func&id=1118 SortCustom1D]()</tt> - Sorts a 1D array given a custom comparison function.
*<tt>[http://www.amxmodx.org/funcwiki.php?go=func&id=1119 SortCustom2D]()</tt> - Sorts a 2D array given a custom comparison function.

===Examples===
You can see an example of each native listed above in the [http://svn.tcwonline.org/viewvc.cgi/trunk/plugins/testsuite/sorttest.sma?root=amxmodx&view=log sorting testing] plugin.

=Full Changelog=
==Core Changes==
===New Features===
*The compiler has been heavily optimized and will now compile plugins much faster.
*Request am[http://forums.alliedmods.net/showthread.php?t=43012 43012]: You can now specify per-map plugins files. For example, you can list de_dust only plugins in configs/maps/plugins-de_dust.ini.
*You can now specify a new "disabled" option after plugin names in plugins.ini files. This will prevent the plugin from being loaded in any config file, and is useful for disabling plugins in map-specific plugin files.
*Request am[http://forums.alliedmods.net/showthread.php?t=42871 42871]: Source file name is shown in the binary logs when the plugin is in the debug mode.

===Bug Fixes===
*Fixed a bug where secondary plugin files would not autoload modules.
*Fixed a serious corruption bug in callfunc_push_intrf, callfunc_push_floatrf, and callfunc_push_str. Strings or data passed with these methods could be easily overwritten internally.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41317 41317]: ExecuteForward() string parameters would be trashed on future internal string calls.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41777 41777]: time.txt was not included in the installer.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=42213 42213]: "amx_logs" was incorrectly listed as "amx_logsdir" in core.ini.
*Fixed a rare bug where passing (1<<31) into a %d format-code would print garbage characters.

==Scripting Changes==
===Additions===
*Request am[http://forums.alliedmods.net/showthread.php?t=23838 23838]: Added natives to sort integers, floats, strings. Also added natives to sort 1D and 2D arrays using custom algorithms.
*Request am[http://forums.alliedmods.net/showthread.php?t=42810 42810]: Added callfunc_push_array() to push an array through a callfunc.
*Request am[http://forums.alliedmods.net/showthread.php?t=42697 42697]: Added SQL_GetQueryString() to find the query string of a query handle.
*Request am[http://forums.alliedmods.net/showthread.php?t=29544 29544]: Added nvault_touch() native for updating key timestamps.
*Request am[http://forums.alliedmods.net/showthread.php?t=41295 41295]: Added CZ model types to the CsInternalModel enumeration.
*Request am[http://forums.alliedmods.net/showthread.php?t=41635 41635]: All string formatting routines can now use '%u' to print integers as unsigned. Note that Pawn only supports signed arithmetic.
*Request am[http://forums.alliedmods.net/showthread.php?t=41585 41585]: Enhanced functionality of glb_pStringBase with global_get() and added a new return type to pev().
*Request am[http://forums.alliedmods.net/showthread.php?t=40967 40967]: set_fail_state() now logs that the plugin is failed.
*Request am[http://forums.alliedmods.net/showthread.php?t=41375 41375]: cs_set_weapon_silen() now has an additional parameter to toggle whether silencer animation is shown.
*Request am[http://forums.alliedmods.net/showthread.php?t=40169 40169]: cs_get_user_team() now has an additional parameter by reference to get the user's internal player model.
*Added amxx_setpl_curweap() to the native exports table.

===Bug Fixes===
*Fixed am[http://forums.alliedmods.net/showthread.php?t=42916 42916]: get_user_aiming did not work on Linux.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=40963 40963]: GeoIP did not strip ports from IP addresses.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41483 41483]: xs.inc did not have double-include prevention.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=43313 43313]: plugin_log() did not actually block log messages on returning PLUGIN_HANDLED.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=42097 42097]: Hooking FM_ServerDeactivate did not work.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=42307 42307]: nvault_open() did not return -1 on failure.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=42383 42383]: SQL_ThreadQuery() was not working when called from plugin_end().

==Plugin Changes==
===Additions===
*Request am[http://forums.alliedmods.net/showthread.php?t=41367 41367]: stats_logging.sma now logs extra weapons from CSX.

===Bug Fixes===
*Fixed am[http://forums.alliedmods.net/showthread.php?t=42013 42013]: TFC team menu did allow for changing from blue team. Also, all plmenu plugins showed team change messages in the language of the admin.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41768 41768]: statssounds.sma for TS had the wrong plugin name.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41563 41563]: TFC plmenu.sma had the wrong team names.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41259 41259]: amx_addadmin was messing users.ini upon new entries.
==Module Fixes==
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41030 41030]: All stats modules could generate files that would break the file parser.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41961 41961]: Fakemeta hooks for GetPlayerAuthId, GetPlayerWONId, and IsMapValid were not being reset on mapchange.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=42321 42321]: TFC's Get/Set ammo natives would not work as expected because of an incorrect offset in Linux servers.
*Fixed bug in Fakemeta where DLLFunc_RegisterEncoders would not actually make a call.

AMX Mod X 1.76 Changes

2006-08-20T21:59:13Z

Faluco:

AMX Mod X 1.76 will be a small feature release and contains mostly bug fixes.
This changelog is brought to you by Batman and ramen.

=New Plugin File Features=
==Per-Map Plugin Files==
You can now have per-map plugin configuration files. AMX Mod X will automatically load any plugins listed in files having the following name: <tt>configs/maps/plugins-<map>.ini</tt>. Thus, <tt>de_dust</tt> specific plugins will be loaded from <tt>configs/maps/plugins-de_dust.ini</tt>.

Map-specific plugin files are parsed after the main plugins.ini is parsed, and after all secondary plugins-*.ini files are parsed in the <tt>configs</tt> folder. This means that a map-specific plugin listing inherits all settings above itself.

==Disabling Plugins==
A second feature was introduced to let users disable plugins per map. In any plugins-*.ini file, you may now add a "disabled" flag to a plugin name. This works like the "debug" flag. Example:
<code>
gaben.amxx disabled
</code>

This will block the plugin from being loaded from any other configuration file. So if <tt>plugins-de_dust.ini</tt> has the example line above, <tt>gaben.amxx</tt> will not be loaded from any other plugins file.

=New Scripting Features=
==Sorting==
AMX Mod X now has a comprehensive array sorting solution. You can sort using pre-defined array types, or use your own custom comparison functions. All of the sorting routines use the qsort() function from the C standard library, which is based on the [http://linux.wku.edu/~lamonml/algor/sort/quick.html Quick Sort] algorithm.

===Basic Sorting===
The follow basic sorting natives were added. These natives sort an array in-place using pre-defined comparison routines. You can change the sorting order using an optional third parameter. By default it is <tt>Sort_Ascending</tt>, and <tt>Sort_Descending</tt> is available as well.
*<tt>[http://www.amxmodx.org/funcwiki.php?go=func&id=1115 SortIntegers]()</tt> - Sorts an array of integers.
*<tt>[http://www.amxmodx.org/funcwiki.php?go=func&id=1116 SortFloats]()</tt> - Sorts an array of floats.
*<tt>[http://www.amxmodx.org/funcwiki.php?go=func&id=1117 SortStrings]()</tt> - Sorts an array of strings.

===Custom Sorting===
Furthermore, you can also define your own custom comparison functions and have the sorting algorithm run them for you. This can be useful in a variety of ways. For example, if you have an array of players and an array of those player's skills, you can easily sort the player ids by skill using this feature.

Custom sorting requires making a function which compares two elements of your array. Given elements e1 and e2:
*Return -1 to mean "e1 comes before e2"
*Return 0 to mean "e1 is equal to e2"
*Return 1 to mean "e1 comes after e2"
For example, a very simple formula to compare integers in this manner is: <tt>e1 - e2</tt>.

The custom sorting natives are:
*<tt>[http://www.amxmodx.org/funcwiki.php?go=func&id=1118 SortCustom1D]()</tt> - Sorts a 1D array given a custom comparison function.
*<tt>[http://www.amxmodx.org/funcwiki.php?go=func&id=1119 SortCustom2D]()</tt> - Sorts a 2D array given a custom comparison function.

===Examples===
You can see an example of each native listed above in the [http://svn.tcwonline.org/viewvc.cgi/trunk/plugins/testsuite/sorttest.sma?root=amxmodx&view=log sorting testing] plugin.

=Full Changelog=
==Core Changes==
===New Features===
*The compiler has been heavily optimized and will now compile plugins much faster.
*Request am[http://forums.alliedmods.net/showthread.php?t=43012 43012]: You can now specify per-map plugins files. For example, you can list de_dust only plugins in configs/maps/plugins-de_dust.ini.
*You can now specify a new "disabled" option after plugin names in plugins.ini files. This will prevent the plugin from being loaded in any config file, and is useful for disabling plugins in map-specific plugin files.
*Request am[http://forums.alliedmods.net/showthread.php?t=42871 42871]: Source file name is shown in the binary logs when the plugin is in the debug mode.

===Bug Fixes===
*Fixed a bug where secondary plugin files would not autoload modules.
*Fixed a serious corruption bug in callfunc_push_intrf, callfunc_push_floatrf, and callfunc_push_str. Strings or data passed with these methods could be easily overwritten internally.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41317 41317]: ExecuteForward() string parameters would be trashed on future internal string calls.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41777 41777]: time.txt was not included in the installer.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=42213 42213]: "amx_logs" was incorrectly listed as "amx_logsdir" in core.ini.
*Fixed a rare bug where passing (1<<31) into a %d format-code would print garbage characters.

==Scripting Changes==
===Additions===
*Request am[http://forums.alliedmods.net/showthread.php?t=23838 23838]: Added natives to sort integers, floats, strings. Also added natives to sort 1D and 2D arrays using custom algorithms.
*Request am[http://forums.alliedmods.net/showthread.php?t=42810 42810]: Added callfunc_push_array() to push an array through a callfunc.
*Request am[http://forums.alliedmods.net/showthread.php?t=42697 42697]: Added SQL_GetQueryString() to find the query string of a query handle.
*Request am[http://forums.alliedmods.net/showthread.php?t=29544 29544]: Added nvault_touch() native for updating key timestamps.
*Request am[http://forums.alliedmods.net/showthread.php?t=41295 41295]: Added CZ model types to the CsInternalModel enumeration.
*Request am[http://forums.alliedmods.net/showthread.php?t=41635 41635]: All string formatting routines can now use '%u' to print integers as unsigned. Note that Pawn only supports signed arithmetic.
*Request am[http://forums.alliedmods.net/showthread.php?t=41585 41585]: Enhanced functionality of glb_pStringBase with global_get() and added a new return type to pev().
*Request am[http://forums.alliedmods.net/showthread.php?t=40967 40967]: set_fail_state() now logs that the plugin is failed.
*Request am[http://forums.alliedmods.net/showthread.php?t=41375 41375]: cs_set_weapon_silen() now has an additional parameter to toggle whether silencer animation is shown.
*Request am[http://forums.alliedmods.net/showthread.php?t=40169 40169]: cs_get_user_team() now has an additional parameter by reference to get the user's internal player model.
*Added amxx_setpl_curweap() to the native exports table.

===Bug Fixes===
*Fixed am[http://forums.alliedmods.net/showthread.php?t=42916 42916]: get_user_aiming did not work on Linux.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=40963 40963]: GeoIP did not strip ports from IP addresses.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41483 41483]: xs.inc did not have double-include prevention.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=43313 43313]: plugin_log() did not actually block log messages on returning PLUGIN_HANDLED.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=42097 42097]: Hooking FM_ServerDeactivate did not work.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=42307 42307]: nvault_open() did not return -1 on failure.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=42383 42383]: SQL_ThreadQuery() was not working when called from plugin_end().

==Plugin Changes==
===Additions===
*Request am[http://forums.alliedmods.net/showthread.php?t=41367 41367]: stats_logging.sma now logs extra weapons from CSX.

===Bug Fixes===
*Fixed am[http://forums.alliedmods.net/showthread.php?t=42013 42013]: TFC team menu did allow for changing from blue team. Also, all plmenu plugins showed team change messages in the language of the admin.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41768 41768]: statssounds.sma for TS had the wrong plugin name.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41563 41563]: TFC plmenu.sma had the wrong team names.
==Module Fixes==
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41030 41030]: All stats modules could generate files that would break the file parser.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41961 41961]: Fakemeta hooks for GetPlayerAuthId, GetPlayerWONId, and IsMapValid were not being reset on mapchange.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=42321 42321]: TFC's Get/Set ammo natives would not work as expected because of an incorrect offset in Linux servers.
*Fixed bug in Fakemeta where DLLFunc_RegisterEncoders would not actually make a call.

AMX Mod X 1.76 Changes

2006-08-20T01:03:23Z

Faluco:

AMX Mod X 1.76 Changes

2006-08-19T20:28:27Z

Faluco: request

AMX Mod X 1.76 Changes

2006-08-18T17:33:26Z

Faluco:

AMX Mod X 1.76 will be a small feature release and contains mostly bug fixes.

=New Plugin File Features=
==Per-Map Plugin Files==
You can now have per-map plugin configuration files. AMX Mod X will automatically load any plugins listed in files having the following name: <tt>configs/maps/plugins-<map>.ini</tt>. Thus, <tt>de_dust</tt> specific plugins will be loaded from <tt>configs/maps/plugins-de_dust.ini</tt>.

Map-specific plugin files are parsed after the main plugins.ini is parsed, and after all secondary plugins-*.ini files are parsed in the <tt>configs</tt> folder. This means that a map-specific plugin listing inherits all settings above itself.

==Disabling Plugins==
A second feature was introduced to let users disable plugins per map. In any plugins-*.ini file, you may now add a "disabled" flag to a plugin name. This works like the "debug" flag. Example:
<code>
gaben.amxx disabled
</code>

This will block the plugin from being loaded from any other configuration file. So if <tt>plugins-de_dust.ini</tt> has the example line above, <tt>gaben.amxx</tt> will not be loaded from any other plugins file.

=Full Changelog=
==Core Changes==
===New Features===
*The compiler has been heavily optimized and will now compile plugins much faster.
*Request am[http://forums.alliedmods.net/showthread.php?t=43012 43012]: You can now specify per-map plugins files. For example, you can list de_dust only plugins in configs/maps/plugins-de_dust.ini.
*You can now specify a new "disabled" option after plugin names in plugins.ini files. This will prevent the plugin from being loaded in any config file, and is useful for disabling plugins in map-specific plugin files.

===Bug Fixes===
*Fixed a bug where secondary plugin files would not autoload modules.
*Fixed a serious corruption bug in callfunc_push_intrf, callfunc_push_floatrf, and callfunc_push_str. Strings or data passed with these methods could be easily overwritten internally.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41317 41317]: ExecuteForward() string parameters would be trashed on future internal string calls.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41777 41777]: time.txt was not included in the installer.

==Scripting Changes==
===Additions===
*Request am[http://forums.alliedmods.net/showthread.php?t=41585 41585]: Enhanced functionality of glb_pStringBase with global_get() and added a new return type to pev().
*Request am[http://forums.alliedmods.net/showthread.php?t=41295 41295]: Added CZ model types to the CsInternalModel enumeration.
*Request am[http://forums.alliedmods.net/showthread.php?t=42697 42697]: Added SQL_GetQueryString() to find the query string of a query handle.
*Request am[http://forums.alliedmods.net/showthread.php?t=42810 42810]: Added callfunc_push_array() to push an array through a callfunc.
*Added amxx_setpl_curweap() to the native exports table.

===Bug Fixes===
*Fixed am[http://forums.alliedmods.net/showthread.php?t=42916 42916]: get_user_aiming did not work on Linux.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=40963 40963]: GeoIP did not strip ports from IP addresses.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41483 41483]: xs.inc did not have double-include prevention.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=43313 43313]: plugin_log() did not actually block log messages on returning PLUGIN_HANDLED.

==Plugin Changes==
===Additions===
*Request am[http://forums.alliedmods.net/showthread.php?t=41367 41367]: stats_logging.sma now logs extra weapons from CSX.

===Bug Fixes===
*Fixed am[http://forums.alliedmods.net/showthread.php?t=42013 42013]: TFC team menu did allow for changing from blue team. Also, all plmenu plugins showed team change messages in the language of the admin.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41768 41768]: statssounds.sma for TS had the wrong plugin name.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41563 41563]: TFC plmenu.sma had the wrong team names.
==Module Fixes==
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41961 41961]: Fakemeta hooks for GetPlayerAuthId, GetPlayerWONId, and IsMapValid were not being reset on mapchange.
*Fixed bug in Fakemeta where DLLFunc_RegisterEncoders would not actually make a call.

AMX Mod X 1.76 Changes

2006-08-18T17:32:53Z

Faluco: added new bug fix

AMX Mod X 1.76 will be a small feature release and contains mostly bug fixes.

=New Plugin File Features=
==Per-Map Plugin Files==
You can now have per-map plugin configuration files. AMX Mod X will automatically load any plugins listed in files having the following name: <tt>configs/maps/plugins-<map>.ini</tt>. Thus, <tt>de_dust</tt> specific plugins will be loaded from <tt>configs/maps/plugins-de_dust.ini</tt>.

Map-specific plugin files are parsed after the main plugins.ini is parsed, and after all secondary plugins-*.ini files are parsed in the <tt>configs</tt> folder. This means that a map-specific plugin listing inherits all settings above itself.

==Disabling Plugins==
A second feature was introduced to let users disable plugins per map. In any plugins-*.ini file, you may now add a "disabled" flag to a plugin name. This works like the "debug" flag. Example:
<code>
gaben.amxx disabled
</code>

This will block the plugin from being loaded from any other configuration file. So if <tt>plugins-de_dust.ini</tt> has the example line above, <tt>gaben.amxx</tt> will not be loaded from any other plugins file.

=Full Changelog=
==Core Changes==
===New Features===
*The compiler has been heavily optimized and will now compile plugins much faster.
*Request am[http://forums.alliedmods.net/showthread.php?t=43012 43012]: You can now specify per-map plugins files. For example, you can list de_dust only plugins in configs/maps/plugins-de_dust.ini.
*You can now specify a new "disabled" option after plugin names in plugins.ini files. This will prevent the plugin from being loaded in any config file, and is useful for disabling plugins in map-specific plugin files.

===Bug Fixes===
*Fixed a bug where secondary plugin files would not autoload modules.
*Fixed a serious corruption bug in callfunc_push_intrf, callfunc_push_floatrf, and callfunc_push_str. Strings or data passed with these methods could be easily overwritten internally.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41317 41317]: ExecuteForward() string parameters would be trashed on future internal string calls.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41777 41777]: time.txt was not included in the installer.

==Scripting Changes==
===Additions===
*Request am[http://forums.alliedmods.net/showthread.php?t=41585 41585]: Enhanced functionality of glb_pStringBase with global_get() and added a new return type to pev().
*Request am[http://forums.alliedmods.net/showthread.php?t=41295 41295]: Added CZ model types to the CsInternalModel enumeration.
*Request am[http://forums.alliedmods.net/showthread.php?t=42697 42697]: Added SQL_GetQueryString() to find the query string of a query handle.
*Request am[http://forums.alliedmods.net/showthread.php?t=42810 42810]: Added callfunc_push_array() to push an array through a callfunc.
*Added amxx_setpl_curweap() to the native exports table.

===Bug Fixes===
*Fixed am[http://forums.alliedmods.net/showthread.php?t=42916 42916]: get_user_aiming did not work on Linux.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=40963 40963]: GeoIP did not strip ports from IP addresses.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41483 41483]: xs.inc did not have double-include prevention.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=43313 43313]: plugin_log() did not actually block log messages on returning PLUGIN_HANDLED.

==Plugin Changes==
===Additions===
*Request am[http://forums.alliedmods.net/showthread.php?t=41367 41367]: stats_logging.sma now logs extra weapons from CSX.

===Bug Fixes===
*Fixed am[http://forums.alliedmods.net/showthread.php?t=42013 42013]: TFC team menu did allow for changing from blue team. Also, all plmenu plugins showed team change messages in the language of the admin.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41768 41768]: statssounds.sma for TS had the wrong plugin name.
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41563 41563]: TFC plmenu.sma had the wrong team names.
==Module Fixes==
*Fixed am[http://forums.alliedmods.net/showthread.php?t=41961 41961]: Fakemeta hooks for GetPlayerAuthId, GetPlayerWONId, and IsMapValid were not being reset on mapchange.
Fixed bug in Fakemeta where DLLFunc_RegisterEncoders would not actually make a call.

AMX Mod X 1.75 Scripting Changes

2006-06-10T21:02:39Z

Faluco:

The AMX Mod X 1.75 release made important changes. While backwards compatibility was kept, intended functionality shifted in esoteric areas that will affect some plugins. Reading this article is highly recommended.

=Module Requirement System=
As part of the new Automatic Module Loading, the old <tt>#pragma library</tt> has been deprecated. You must now use:
<pawn>#pragma reqlib <library>
</pawn>
This means "require library". Plugins still compiled with <tt>#pragma library</tt> will still fail on load if the given module is not found. However, core will try to load each module given the rules below under "Automatic Module Loading".

=Auto Plugin Files=
With the introduction of callfunc and register_native, many people now distribute plugins in large sets. To make this easier on users, you can now distribute an "extended plugin file." For example, say you have five plugins in a set. Normally, you would have to ask the user to write each name into plugins.ini, like so:
<pre>
file1.amxx ;file1
file2.amxx ;file2
file3.amxx ;file3
file4.amxx ;file4
file5.amxx ;file5
</pre>

With AMX Mod X 1.75, any file in the configs folder which follows a certain name pattern will be auto-loaded as an additional plugins.ini file. The pattern is: plugins-*.ini.

For example, you could distribute <tt>plugins-carmod.ini</tt> as:
<pre>
;put a semi-colon to disable a plugin
cars_honda.amxx
cars_toyota.amxx
cars_ford.amxx
cars_bmw.amxx
cars_gaben.amxx
</pre>

This way, you can easily distribute an extractable install, rather than giving the user overcomplicated instructions. Furthermore, the file is easily disabled by simply modifying the name (for example, "disabled-carmod.ini").

=Automatic Module Loading=
==Overview==
As of AMX Mod X 1.75, there is a new, powerful automatic module loading system. That means that <tt>modules.ini</tt> is largely deprecated for general use. Instead, modules are loaded as plugins need them. This is done dynamically by core before plugins are even loaded, without the need to patch <tt>modules.ini</tt> and then change the map.

Modules can now define "Libraries" and "Library Classes". A library is a specific identifier that should match the filename of the module. For example, Engine's defined library is "engine". FakeMeta's library is "fakemeta", and so on.

A "library class" defines membership to a set of modules. For example, CSX has the library name "csx", but it is part of the library class "xstats". Library classes are also used for DBI and SQLX. This is very useful for being able to require one module type of any implementation.

==New API==
===Compiler Pragmas===
This is expanded with a number of new <tt>#pragma</tt> directives:
*<tt>#pragma reqlib <library></tt> - Requires that a given library must be loaded.
*<tt>#pragma reqclass <libclass></tt> - Requires that a given library class must be loaded.
*<tt>#pragma loadlib <library></tt> - Automatically attempts to load a given library (see more info below).
*<tt>#pragma expectlib <library1> <library2></tt> - If the first library is not loaded, the second one will be attempted to load (not very useful).
*<tt>#pragma expectclass <class> <library></tt> - If the expected class is not found, the given library will be attempted to load. This is useful for defining a default module to be loaded with a given class of modules.
*<tt>#pragma defclasslib <class> <library></tt> - Same as <tt>expectclass</tt>, however, <tt>defclasslib</tt> waits until all expectations are resolved. This lets plugins override defaults by adding their own expectations.

===Module Filtering===
The module_filter prototype now includes a second parameter, which tells you whether the requirement is a class or library.

Furthermore, module_exists has been deprecated for LibraryExists().

==How it Works==
The precise order of events is as follows:
*When the first entity is spawned, AMX Mod X loads all unloaded modules in <tt>modules.ini</tt>.
*After <tt>modules.ini</tt> is parsed, <tt>plugins.ini</tt> is read. Each file is mapped into a cache.
*The cache is previewed.
**First, the "library" table is read. This table is read for backwards compatibility with AMX Mod X 1.71 and prior. Each entry is read as a module file shortname, and the module is loaded if it exists.
**Next, the "pubtags" table is read. Each entry is decoded to one of the special #pragma commands.
***All loadlib commands are executed, and the modules loaded.
***All expect commands are executed.
***All defclasslib commands are executed.
*AMX Mod X then waits until ServerActivate is called.
*All plugins are loaded. If the plugin is in the cache, the cache is read instead. For each plugin...
**The library table is read. For each library that is both nonexistant and unhandled by a module filter, the plugin fails to load.
**The pubtags table is read. For each reqlib and reqclass entry that are both nonexistant and unhandled by a module filter, the plugin fails to load.
*The plugin cache is invalidated and the server is considered "loaded".

=SQLX=
==Introduction==
SQLX is a new Database API that supercedes DBI. Its main feature is that you can load two SQLX modules at once, whereas you cannot with DBI. It also supports threaded queries, which let you process data without interrupting gameplay from a bad network connection.

These additions come at a hefty price. The SQLX API is significantly more complex than DBI. Although some might find it easier to use due to its simpler error checking and iteration, it requires more manual memory management and has less simple abstraction. Furthermore, taking advantage of the new <tt>SQL_ThreadQuery</tt> native will require nothing short of a rewrite for most plugins, as it is ''asynchronous'' instead of ''synchronous''. Because of this, the new SQLX modules also implement the old DBI functionality, for both backwards compatibility and for plugin developers familiar with the old API. All three APIs - SQL-threaded, SQL-non-threaded, and DBI, are still fully supported.

==Usage==
Since SQLX is an expansive API, showing a single plugin of its usage would be difficult. It is highly recommended that users interested in the new API look at the [http://cvs.tcwonline.org/viewvc.cgi/amxmodx/plugins/testsuite/sqlxtest.sma?view=log SQLxTest] plugin, which compares two different DBI methods and both SQL methods of querying a database. It is highly useful for both regression testing and for getting an idea of how the API works.

The most important concept of SQLX is "Handles," which are a precursor to a system planned for SourceMod. Handles are datatypes that store internal information that you should not modify. Whenever you create a handle, you must also free it, with <tt>SQL_FreeHandle</tt>().

==Native Overview==
The basic natives of SQLX are:
*<tt>SQL_MakeDbTuple</tt> (or simple stock version, <tt>SQL_MakeStdTuple</tt>) - This creates a variable that holds information about a database. It does not connect to the database. This is so you don't have to keep retrieving cvar info on every connection. You do not have to free these handles, although it is a good idea if you create them dynamically.
*<tt>SQL_Connect</tt> - Connects to a database and returns a new Handle, or <tt>Empty_Handle</tt> on failure.
*<tt>SQL_PrepareQuery</tt> - Prepares a query for execution, and returns a new Handle to the query.
*<tt>SQL_Execute</tt> - Executes a prepared query, and returns 0 on failure (1 on success).
*<tt>SQL_MoreResults</tt> - Returns 1 if there are more results in the query result queue, 0 if none.
*<tt>SQL_ReadResult</tt> - Reads the current row result by the column's numerical index, similar to dbi_field/dbi_result.
*<tt>SQL_NextRow</tt> - Advances to the next result row. '''Compatibility Warning''': This does not need to be called first! Unlike <tt>dbi_nextrow</tt>, the query is automatically at the first row. If you call <tt>SQL_NextRow</tt> before <tt>SQL_ReadResult</tt>, your are actually skipping a row.
*<tt>SQL_FreeHandle</tt> - Frees a Handle. You must do this or else memory will leak.
*<tt>SQL_ThreadQuery</tt> - Places a query and connection info into a threaded queue. In another thread, the connection is established, the query is executed, and the connection is dropped. The query results are then posted back into the main thread and given to the plugin on the next server-frame.
**Note that while powerful, the mechanism is very simplistic. Similar to <tt>set_task</tt>, you must differentiate multiple queries having the same callback by packing binary data into an array. Furthermore, you can only make one query at a time, since the queue is "push one, resolve one, pop one." If you plan on making five queries in a row in order to get aggregate information about a player, you must make each of these five queries in separate stages, and you must also take into account asynchronous factors such as the player dropping during the middle of a query. (One way to do this is to pack the player's authid and client index into the callback data and verify it when the query finishes.)

=New Natives / Native Changes=
==Register Message==
The <tt>register_message</tt> set of natives, including <tt>get/set_msg_block</tt>, has been moved to Core. This is to facilitate users who prefer to use FakeMeta, and like the simplicity and speed of using Engine's message interception functions.
 
This change is backwards compatible.

==Argument Formatting==
The <tt>format_args</tt> function is now replaced with a much faster, more compatible <tt>vformat</tt> function. Its usage is slightly different (read the include file, <tt>string.inc</tt>), but it accepts %L, whereas format_args does not. A quick example:
<pawn>debugprint(const fmt[], ...)
{
static temp[2048]
vformat(temp, sizeof(temp)-1, fmt, 2)
log_message("[DEBUG] %s", temp)
}</pawn>

==Other Core Natives==
*<tt>register_plugin</tt> - Now returns a plugin id.
*<tt>get_amxx_verstring</tt> - Returns the AMX Mod X version string.
*<tt>get_weaponid</tt> - Gets a weapon id from a weapon name.

==FakeMeta==
===New Natives===
*<tt>get_orig_retval</tt> - Gets the original return value of an engine or game DLL function.
*<tt>copy_infokey_buffer</tt> - Copies the given infobuffer pointer into output buffer.
*<tt>get/set_cd</tt> - Gets or sets members of a clientdata data structure (used with UpdateClientData).
*<tt>get/set_es</tt> - Gets or sets members of an entity_state data structure (used with AddToFullPack).
*<tt>get/set_uc</tt> - Gets or sets members of a usecmd data structure (used with CmdStart).

===New Engine/GameDLL Functions===
The <tt>register_forward</tt> native now allows for hooking a number of new functions from the engine or game DLL including:
*<tt>UpdateClientData</tt>
*<tt>AddToFullPack</tt>
*<tt>CmdStart</tt>
*<tt>CmdEnd</tt>
*<tt>CreateInstBaselines</tt> - Game DLL function
*<tt>CreateInstBaseline</tt> - Engine function
*<tt>CreateBaseline</tt>
*<tt>GetInfoKeyBuffer</tt>
*<tt>AlertMessage</tt> - This now can be called via <tt>engfunc</tt>
*<tt>ClientPrintf</tt>

These functions can also be called via <tt>engfunc</tt> or <tt>dllfunc</tt>.

===Breaking Changes===
Using <tt>engfunc</tt> in order to call <tt>EngFunc_InfoKeyValue</tt>, <tt>EngFunc_SetKeyValue</tt>, or <tt>EngFunc_SetClientKeyValue</tt> now requires passing an infobuffer pointer. An infobuffer pointer can be obtained by calling <tt>EngFunc_GetInfoKeyBuffer</tt>. For example:
<pawn>some_function(id, name[])
{
new infokey = engfunc(EngFunc_GetInfoKeyBuffer, id)
engfunc(EngFunc_SetClientKeyValue, id, infokey, "model", name)
}</pawn>

If you hook ClientUserInfoChanged via Fakemeta, an infobuffer pointer is now also forwarded to your function in addition to the client id.

==Cstrike==
*<tt>cs_get_user_mapzones</tt> - Returns bitwise flags of where on the map a player is located such as buy zone, bomb site, hostage rescue zone, VIP safety zone, and escape zone.
*<tt>cs_set_user_vip</tt> - Now takes two additional (but optional) parameters for determining whether or not the player model and scoreboard get updated.
*<tt>cs_set_user_zoom</tt> - Sets a zooming type on a player for any weapon.
*<tt>cs_get_user_zoom</tt> - Returns the zooming type of a player.

==New Stocks==
===Engine===
*<tt>IsInWorld</tt> - Checks if an entity is within the bounds of the world (from HLSDK).

===FakeMeta===
*<tt>DF_UpdateClientData</tt> - Calls UpdateClientData game DLL function.
*<tt>DF_AddToFullPack</tt> - Calls AddToFullPack game DLL function.
*<tt>DF_CmdStart</tt> - Calls CmdStart game DLL function.
*<tt>DF_CmdEnd</tt> - Calls CmdEnd game DLL function.
*<tt>DF_CreateBaseline</tt> - Calls CreateBaseline game DLL function.
*<tt>DF_CreateInstBaselines</tt> - Calls CreateInstancedBaselines game DLL function.
*<tt>EF_CreateInstBaseline</tt> - Calls CreateInstancedBaseline engine function.
*<tt>EF_GetInfoKeyBuffer</tt> - Calls GetInfoKeyBuffer engine function.
*<tt>EF_ClientPrintf</tt> - Calls ClientPrintf engine function.

==New Constants==
Various sound constants (<tt>SND_SPAWNING</tt>, <tt>SND_STOP</tt>, <tt>SND_CHANGE_VOL</tt>, and <tt>SND_CHANGE_PITCH</tt>) from the HL SDK as well as a constant for pi were added to <tt>amxconst.inc</tt>. <tt>TE_*</tt> (temp entity) message constants have also been added which will automatically be included with <tt>#include <amxmodx></tt>. And finally, a new <tt>hlsdk_const.inc</tt> file has been added that contains many more constants from the SDK. This is automatically included with <tt>#include <engine></tt> or <tt>#include <fakemeta></tt>.

=Module API=
The AMX Mod X module API received a small overhaul for 1.75.

==Versioning/Interface Additions==
The internal module interface version is 4. However, modules from M/SDK 3 will still load.

M/SDK Version 4 modules have two new members of public information: the library string, and the library class string. These contain comma delimited names of whatever libraries or library classes the module would like to be registered.

For backwards compatibility, M/SDK Version 4 modules have an automatically empty library class string, and a library string equal to the logtag string.

==New Callbacks==
Modules can now be informed of when plugins are about to be unloaded, and when plugins have been fully unloaded. This means that modules don't have to hook ServerActivate and ServerActivate_Post (implementation dependent), don't need to be loaded by Metamod, and don't need to detach simply to release resources.

==New Functions==
*<tt>MF_GetLocalInfo</tt> - Intended for modules using LOCALINFO, which required a Metamod attachment. This is equal to AMX Mod X's core function <tt>get_localinfo</tt>.
*<tt>MF_OverrideNatives</tt> - Given a native list, this specifies that any other module already providing these natives will no longer provide them. This was added to force backwards compatibility between SQLITE and MySQLX. Usage is not recommended.
*<tt>MF_FindLibrary</tt> - Essentially the same function as LibraryExists() for plugins.
*<tt>MF_AddLibraries</tt> - Adds a comma delimited list of libraries or library classes. You must specify a "parent" pointer that identifies the module. This is easily accomplished by taking the address of any static variable.
*<tt>MF_RemoveLibraries</tt> - Removes all library entries with the given parent pointer. This is useful if your module adds custom entries not in its defined list.

==MSVC8 Compatibility==
M/SDK Version 4 now contains preprocessor definitions for compatibility with Microsoft's Visual Studio 2005/8.0 (provided by [[User:Damaged Soul|Damaged Soul]]). These macros can be turned off in the <tt>moduleconfig.h</tt> file by uncommenting the definition of <tt>NO_MSVC8_AUTO_COMPAT</tt>.

=Minor Changes=
==Compiler Defines==
Since <tt>__DATE__</tt> was fixed in 1.75, the macro <tt>__TIME__</tt> was also added.

=Full Changelog=
This changelog is tentative. Developers will be editing it as things are changed.

* Core Changes
** Modules are now automatically loaded by detecting plugin usage.
*** modules.ini is now primarily deprecated, except for SQL and unsupported libraries.
** Rewrote SQLX modules (again). You can now load multiple SQL modules and toggle them per-plugin.
*** Added new SQL API called SQLX. DBI was kept backwards-compatible.
*** Added new function to thread SQL queries (which prevents lag from a bad connection).
** Fixed some very small memory leaks.
** Fixed binary logging building wrong on Linux.
** Fixed some debugging crashes.
** Fixed serious bug when creating plugin_pause/plugin_unpause forwards.
** Fixed serious crash bug involving set_hudmessage and plugins using high hudchannels.
** Added natives:
*** fputs()
*** get_weaponid()
*** rename_file()
*** vformat()
** Any file starting with "plugins-" and ending in ".ini" will now be treated as an extended plugins file. This is useful for distributing sets of plugins separately, and easily disabling them with a name change.

* Fakemeta Changes
** Added new hookable/callable functions:
*** AddToFullPack
*** AlertMessage
*** ClientPrintf
*** ClientUserInfoChanged
*** CmdEnd
*** CmdStart
*** CreateBaseline
*** CreateInstancedBaseline
*** GetInfoKeyBuffer
*** InfoKeyValue
*** UpdateClientData
*** SetClientKeyValue
*** SetKeyValue
** Added new natives:
*** copy_infokey_buffer
*** get_orig_retval
** Fixed various trace bugs in FakeMeta with certain natives.
** Fixed some unhooking on server-deactivate problems in FakeMeta.

* Scripting Changes:
** Added __DATE__ and __TIME__ auto-macros to the compiler.
** Added many HLSDK constants and improved include organization.
** Added new compiler #pragma directives for using the module autoloading system.
** Added cs_get_user_mapzones (thanks VEN!).
** Added cs_set_user_zoom.
** Added cs_get_user_zoom.
** Added IsInWorld() stock (thanks Twilight Suzuka!).
** Added nvault_remove().
** Moved various natives from Engine and into Core:
*** register_message
*** get_msg_args
*** get/set_msg_arg_type
*** get/set_msg_arg_int
*** get/set_msg_arg_float
*** get/set_msg_arg_string
*** get_msg_origin
*** get/set_msg_block
*** velocity_by_aim
*** vector_to_angle
*** angle_vector
*** vector_length
*** vector_distance
*** precache_generic
** Dynamic natives that are paused now also pause parent plugins (with an error).
** register_plugin() now returns the plugin ID.
** Fixed a corruption bug in strip_user_weapons().
** Fixed a bug in set_view() (thanks jtp10181!).
** Fixed is_in_viewcone() always returning 0.
** Fixed is_visible causing a crash, improved accuracy.
** Fixed a crash bug in get_tr2() (thanks Orangutanz!).
** Fixed cs_get_user_buyzone() returning existence in other areas.
** Fixed a rare floatround() bug where values ending strictly in .5 were IEEE rounded.
** Fixed a bug where removing the current parent task could damage the task queue.
** Fixed a bug in get_entity_visibility (thanks VEN!).
** Removed non-existant take_damage() entry.
** Expanded XS Stock Library with addition of xs_vec_make2d.
** Expanded usage of cs_set_user_vip().
** Improved get_brush_entity_origin() and ViewContents (thanks Orangutanz!).

* Plugin Changes:
** Added amx_showrcon command to show rcon results in admincmd.sma.
** Added weapon restriction compatibility for bots in CS (KWo).
** Added admin identifier (asterisk which is red if colors are available) to all menus with a user list.
** Upgraded admin.sma to the new SQLX API.
** Fixed a bug in amx_reloadadmins not giving admins new access.
** Fixed a weapon restriction exploit in restmenu.sma.
** Fixed an HTML exploit in /top15 displaying player names.
** Fixed various and plentiful amx_addadmin bugs.
** Fixed telemenu.sma not letting you teleport yourself (thanks jtp10181!).
** Fixed a bug with adminslots.sma lowering the slots by 1.
** Fixed overlapping hud messages with miscstats.

* Module API Changes:
** Added and fixed module API for inter-module communication.
** Added native overriding and replacing to module API.
** Added plugin unloading/unloaded callbacks to module API.
** Added MSVC8 project files to most CVS projects.

* Configuration Changes:
** Added amx_sql_type cvar to sql.cfg.
** Re-organized and simplified modules.ini.
** Error logging can now be redirected to separate logs.
** Fixed modules.ini parsing bugs and simplified parsing.
** Fixed a double entry in cvars.ini.

* Other Changes:
** Added a Bulgarian translation (thanks lubb!).
** Added a leetspeak translation (thanks, I think, Twilight Suzuka!).
** Improved FTP option of the graphical installer.
** Updated the GeoIP library to June.
** Updated PCRE from v6.1 to v6.4.
** Updated sqLite from 3.3.4 to 3.3.5.
** Fixed a steam account path bug in the installer.

[[Category:AMX Mod X]]

AMX Mod X 1.75 Scripting Changes

2006-06-05T11:28:16Z

Faluco:

The AMX Mod X 1.75 release made important changes. While backwards compatibility was kept, intended functionality shifted in esoteric areas that will affect some plugins. Reading this article is highly recommended.

=Module Requirement System=
As part of the new Automatic Module Loading, the old <tt>#pragma library</tt> has been deprecated. You must now use:
<pawn>#pragma reqlib <library>
</pawn>
This means "require library". Plugins still compiled with <tt>#pragma library</tt> will still fail on load if the given module is not found. However, core will try to load each module given the rules below under "Automatic Module Loading".

=Automatic Module Loading=
==Overview==
As of AMX Mod X 1.75, there is a new, powerful automatic module loading system. That means that <tt>modules.ini</tt> is largely deprecated for general use. Instead, modules are loaded as plugins need them. This is done dynamically by core before plugins are even loaded, without the need to patch <tt>modules.ini</tt> and then change the map.

Modules can now define "Libraries" and "Library Classes". A library is a specific identifier that should match the filename of the module. For example, Engine's defined library is "engine". FakeMeta's library is "fakemeta", and so on.

A "library class" defines membership to a set of modules. For example, CSX has the library name "csx", but it is part of the library class "xstats". Library classes are also used for DBI and SQLX. This is very useful for being able to require one module type of any implementation.

==New API==
===Compiler Pragmas===
This is expanded with a number of new <tt>#pragma</tt> directives:
*<tt>#pragma reqlib <library></tt> - Requires that a given library must be loaded.
*<tt>#pragma reqclass <libclass></tt> - Requires that a given library class must be loaded.
*<tt>#pragma loadlib <library></tt> - Automatically attempts to load a given library (see more info below).
*<tt>#pragma expectlib <library1> <library2></tt> - If the first library is not loaded, the second one will be attempted to load (not very useful).
*<tt>#pragma expectclass <class> <library></tt> - If the expected class is not found, the given library will be attempted to load. This is useful for defining a default module to be loaded with a given class of modules.
*<tt>#pragma defclasslib <class> <library></tt> - Same as <tt>expectclass</tt>, however, <tt>defclasslib</tt> waits until all expectations are resolved. This lets plugins override defaults by adding their own expectations.

===Module Filtering===
The module_filter prototype now includes a second parameter, which tells you whether the requirement is a class or library.

Furthermore, module_exists has been deprecated for LibraryExists().

==How it Works==
The precise order of events is as follows:
*When the first entity is spawned, AMX Mod X loads all unloaded modules in <tt>modules.ini</tt>.
*After <tt>modules.ini</tt> is parsed, <tt>plugins.ini</tt> is read. Each file is mapped into a cache.
*The cache is previewed.
**First, the "library" table is read. This table is read for backwards compatibility with AMX Mod X 1.71 and prior. Each entry is read as a module file shortname, and the module is loaded if it exists.
**Next, the "pubtags" table is read. Each entry is decoded to one of the special #pragma commands.
***All loadlib commands are executed, and the modules loaded.
***All expect commands are executed.
***All defclasslib commands are executed.
*AMX Mod X then waits until ServerActivate is called.
*All plugins are loaded. If the plugin is in the cache, the cache is read instead. For each plugin...
**The library table is read. For each library that is both nonexistant and unhandled by a module filter, the plugin fails to load.
**The pubtags table is read. For each reqlib and reqclass entry that are both nonexistant and unhandled by a module filter, the plugin fails to load.
*The plugin cache is invalidated and the server is considered "loaded".

=SQLX=
==Introduction==
SQLX is a new Database API that supercedes DBI. Its main feature is that you can load two SQLX modules at once, whereas you cannot with DBI. It also supports threaded queries, which let you process data without interrupting gameplay from a bad network connection.

These additions come at a hefty price. The SQLX API is significantly more complex than DBI. Although some might find it easier to use due to its simpler error checking and iteration, it requires more manual memory management and has less simple abstraction. Furthermore, taking advantage of the new <tt>SQL_ThreadQuery</tt> native will require nothing short of a rewrite for most plugins, as it is ''asynchronous'' instead of ''synchronous''. Because of this, the new SQLX modules also implement the old DBI functionality, for both backwards compatibility and for plugin developers familiar with the old API. All three APIs - SQL-threaded, SQL-non-threaded, and DBI, are still fully supported.

==Usage==
Since SQLX is an expansive API, showing a single plugin of its usage would be difficult. It is highly recommended that users interested in the new API look at the [http://cvs.tcwonline.org/viewvc.cgi/amxmodx/plugins/testsuite/sqlxtest.sma?view=log SQLxTest] plugin, which compares two different DBI methods and both SQL methods of querying a database. It is highly useful for both regression testing and for getting an idea of how the API works.

The most important concept of SQLX is "Handles," which are a precursor to a system planned for SourceMod. Handles are datatypes that store internal information that you should not modify. Whenever you create a handle, you must also free it, with <tt>SQL_FreeHandle</tt>().

==Native Overview==
The basic natives of SQLX are:
*<tt>SQL_MakeDbTuple</tt> (or simple stock version, <tt>SQL_MakeStdTuple</tt>) - This creates a variable that holds information about a database. It does not connect to the database. This is so you don't have to keep retrieving cvar info on every connection. You do not have to free these handles, although it is a good idea if you create them dynamically.
*<tt>SQL_Connect</tt> - Connects to a database and returns a new Handle, or <tt>Empty_Handle</tt> on failure.
*<tt>SQL_PrepareQuery</tt> - Prepares a query for execution, and returns a new Handle to the query.
*<tt>SQL_Execute</tt> - Executes a prepared query, and returns 0 on failure (1 on success).
*<tt>SQL_MoreResults</tt> - Returns 1 if there are more results in the query result queue, 0 if none.</tt>
*<tt>SQL_ReadResult</tt> - Reads the current row result by the column's numerical index, similar to dbi_field/dbi_result.
*<tt>SQL_NextRow</tt> - Advances to the next result row. '''Compatibility Warning''': This does not need to be called first! Unlike <tt>dbi_nextrow</tt>, the query is automatically at the first row. If you call <tt>SQL_NextRow</tt> before <tt>SQL_ReadResult</tt>, your are actually skipping a row.
*<tt>SQL_FreeHandle</tt> - Frees a Handle. You must do this or else memory will leak.
*<tt>SQL_ThreadQuery</tt> - Places a query and connection info into a threaded queue. In another thread, the connection is established, the query is executed, and the connection is dropped. The query results are then posted back into the main thread and given to the plugin on the next server-frame.
**Note that while powerful, the mechanism is very simplistic. Similar to <tt>set_task</tt>, you must differentiate multiple queries having the same callback by packing binary data into an array. Furthermore, you can only make one query at a time, since the queue is "push one, resolve one, pop one." If you plan on making five queries in a row in order to get aggregate information about a player, you must make each of these five queries in separate stages, and you must also take into account asynchronous factors such as the player dropping during the middle of a query. (One way to do this is to pack the player's authid and client index into the callback data and verify it when the query finishes.)

=New Natives / Native Changes=
==Register Message==
The <tt>register_message</tt> set of natives, including <tt>get/set_msg_block</tt>, has been moved to Core. This is to facilitate users who prefer to use FakeMeta, and like the simplicity and speed of using Engine's message interception functions.
 
This change is backwards compatible.

==Argument Formatting==
The <tt>format_args</tt> function is now replaced with a much faster, more compatible <tt>vformat</tt> function. Its usage is slightly different (read the include file, <tt>string.inc</tt>), but it accepts %L, whereas format_args does not. A quick example:
<pawn>debugprint(const fmt[], ...)
{
static temp[2048]
vformat(temp, sizeof(temp)-1, fmt, 2)
log_message("[DEBUG] %s", temp)
}</pawn>

==Other Core Natives==
*<tt>register_plugin</tt> - Now returns a plugin id.
*<tt>get_amxx_verstring</tt> - Returns the AMX Mod X version string.
*<tt>get_weaponid</tt> - Gets a weapon id from a weapon name.

==FakeMeta==
===New Natives===
*<tt>get_orig_retval</tt> - Gets the original return value of an engine or game DLL function.
*<tt>copy_infokey_buffer</tt> - Copies the given infobuffer pointer into output buffer.
*<tt>get/set_cd</tt> - Gets or sets members of a clientdata data structure (used with UpdateClientData).
*<tt>get/set_es</tt> - Gets or sets members of an entity_state data structure (used with AddToFullPack).
*<tt>get/set_uc</tt> - Gets or sets members of a usecmd data structure (used with CmdStart).

===New Engine/GameDLL Functions===
The <tt>register_forward</tt> native now allows for hooking a number of new functions from the engine or game DLL including:
*<tt>UpdateClientData</tt>
*<tt>AddToFullPack</tt>
*<tt>CmdStart</tt>
*<tt>CmdEnd</tt>
*<tt>CreateInstBaselines</tt> - Game DLL function
*<tt>CreateInstBaseline</tt> - Engine function
*<tt>CreateBaseline</tt>
*<tt>GetInfoKeyBuffer</tt>
*<tt>AlertMessage</tt> - This now can be called via <tt>engfunc</tt>
*<tt>ClientPrinf</tt>

These functions can also be called via <tt>engfunc</tt> or <tt>dllfunc</tt>.

===Breaking Changes===
Using <tt>engfunc</tt> in order to call <tt>EngFunc_InfoKeyValue</tt>, <tt>EngFunc_SetKeyValue</tt>, or <tt>EngFunc_SetClientKeyValue</tt> now requires passing an infobuffer pointer. An infobuffer pointer can be obtained by calling <tt>EngFunc_GetInfoKeyBuffer</tt>. For example:
<pawn>some_function(id, name[])
{
new infokey = engfunc(EngFunc_GetInfoKeyBuffer, id)
engfunc(EngFunc_SetClientKeyValue, id, infokey, "model", name)
}</pawn>

If you hook ClientUserInfoChanged via Fakemeta, an infobuffer pointer is now also forwarded to your function in addition to the client id.

==Cstrike==
*<tt>cs_get_user_mapzones</tt> - Returns bitwise flags of where on the map a player is located such as buy zone, bomb site, hostage rescue zone, VIP safety zone, and escape zone.
*<tt>cs_set_user_vip</tt> - Now takes two additional (but optional) parameters for determining whether or not the player model and scoreboard get updated.

==New Stocks==
===Engine===
*<tt>IsInWorld</tt> - Checks if an entity is within the bounds of the world (from HLSDK).

===FakeMeta===
*<tt>DF_UpdateClientData</tt> - Calls UpdateClientData game DLL function.
*<tt>DF_AddToFullPack</tt> - Calls AddToFullPack game DLL function.
*<tt>DF_CmdStart</tt> - Calls CmdStart game DLL function.
*<tt>DF_CmdEnd</tt> - Calls CmdEnd game DLL function.
*<tt>DF_CreateBaseline</tt> - Calls CreateBaseline game DLL function.
*<tt>DF_CreateInstBaselines</tt> - Calls CreateInstancedBaselines game DLL function.
*<tt>EF_CreateInstBaseline</tt> - Calls CreateInstancedBaseline engine function.
*<tt>EF_GetInfoKeyBuffer</tt> - Calls GetInfoKeyBuffer engine function.
*<tt>EF_ClientPrintf</tt> - Calls ClientPrintf engine function.

==New Constants==
Various sound constants (<tt>SND_SPAWNING</tt>, <tt>SND_STOP</tt>, <tt>SND_CHANGE_VOL</tt>, and <tt>SND_CHANGE_PITCH</tt>) from the HL SDK as well as a constant for pi were added to <tt>amxconst.inc</tt>. <tt>TE_*</tt> (temp entity) message constants have also been added which will automatically be included with <tt>#include <amxmodx></tt>. And finally, a new <tt>hlsdk_const.inc</tt> file has been added that contains many more constants from the SDK. This is automatically included with <tt>#include <engine></tt> or <tt>#include <fakemeta></tt>.

=Module API=
The AMX Mod X module API received a small overhaul for 1.75.

==Versioning/Interface Additions==
The internal module interface version is 4. However, modules from M/SDK 3 will still load.

M/SDK Version 4 modules have two new members of public information: the library string, and the library class string. These contain comma delimited names of whatever libraries or library classes the module would like to be registered.

For backwards compatibility, M/SDK Version 4 modules have an automatically empty library class string, and a library string equal to the logtag string.

==New Callbacks==
Modules can now be informed of when plugins are about to be unloaded, and when plugins have been fully unloaded. This means that modules don't have to hook ServerActivate and ServerActivate_Post (implementation dependent), don't need to be loaded by Metamod, and don't need to detach simply to release resources.

==New Functions==
*<tt>MF_GetLocalInfo</tt> - Intended for modules using LOCALINFO, which required a Metamod attachment. This is equal to AMX Mod X's core function <tt>get_localinfo</tt>.
*<tt>MF_OverrideNatives</tt> - Given a native list, this specifies that any other module already providing these natives will no longer provide them. This was added to force backwards compatibility between SQLITE and MySQLX. Usage is not recommended.
*<tt>MF_FindLibrary</tt> - Essentially the same function as LibraryExists() for plugins.
*<tt>MF_AddLibraries</tt> - Adds a comma delimited list of libraries or library classes. You must specify a "parent" pointer that identifies the module. This is easily accomplished by taking the address of any static variable.
*<tt>MF_RemoveLibraries</tt> - Removes all library entries with the given parent pointer. This is useful if your module adds custom entries not in its defined list.

==MSVC8 Compatibility==
M/SDK Version 4 now contains preprocessor definitions for compatibility with Microsoft's Visual Studio 2005/8.0 (provided by [[User:Damaged Soul|Damaged Soul]]). These macros can be turned off in the <tt>moduleconfig.h</tt> file by uncommenting the definition of <tt>NO_MSVC8_AUTO_COMPAT</tt>.

=Minor Changes=
==Compiler Defines==
Since <tt>__DATE__</tt> was fixed in 1.75, the macro <tt>__TIME__</tt> was also added.

=Full Changelog=
This changelog is tentative. Developers will be editing it as things are changed.

* Core Changes
** Modules are now automatically loaded by detecting plugin usage.
*** modules.ini is now primarily deprecated, except for SQL and unsupported libraries.
** Added new SQLX modules. You can now load multiple SQL modules and toggle them per-plugin.
*** Added new SQL API called SQLX. DBI was kept backwards-compatible.
*** Added new function to thread SQL queries (which prevents lag from a bad connection).
** Fixed some very small memory leaks.
** Fixed binary logging building wrong on Linux.
** Fixed some debugging crashes.
** Fixed serious bug when creating plugin_pause/plugin_unpause forwards.
** Fixed serious crash bug involving set_hudmessage and plugins using high hudchannels.
** Added natives:
*** fputs()
*** get_weaponid()
*** rename_file()
*** vformat()

* Fakemeta Changes
** Added new hookable/callable functions:
*** AddToFullPack
*** AlertMessage
*** ClientPrintf
*** ClientUserInfoChanged
*** CmdEnd
*** CmdStart
*** CreateBaseline
*** CreateInstancedBaseline
*** GetInfoKeyBuffer
*** InfoKeyValue
*** UpdateClientData
*** SetClientKeyValue
*** SetKeyValue
** Added new natives:
*** copy_infokey_buffer
*** get_orig_retval
** Fixed various trace bugs in FakeMeta with certain natives.
** Fixed some unhooking on server-deactivate problems in FakeMeta.

* Scripting Changes:
** Added __DATE__ and __TIME__ auto-macros to the compiler.
** Added many HLSDK constants and improved include organization.
** Added new compiler #pragma directives for using the module autoloading system.
** Added cs_get_user_mapzones (thanks VEN!).
** Added IsInWorld() stock (thanks Twilight Suzuka!).
** Added nvault_remove().
** Moved various natives from Engine and into Core:
*** register_message
*** get_msg_args
*** get/set_msg_arg_type
*** get/set_msg_arg_int
*** get/set_msg_arg_float
*** get/set_msg_arg_string
*** get_msg_origin
*** get/set_msg_block
*** velocity_by_aim
*** vector_to_angle
*** angle_vector
*** vector_length
*** vector_distance
*** precache_generic
** Dynamic natives that are paused now also pause parent plugins (with an error).
** register_plugin() now returns the plugin ID.
** Fixed a corruption bug in strip_user_weapons().
** Fixed a bug in set_view() (thanks jtp10181!).
** Fixed is_in_viewcone() always returning 0.
** Fixed is_visible causing a crash, improved accuracy.
** Fixed a crash bug in get_tr2() (thanks Orangutanz!).
** Fixed cs_get_user_buyzone() returning existence in other areas.
** Fixed a rare floatround() bug where values ending strictly in .5 were IEEE rounded.
** Fixed a bug where removing the current parent task could damage the task queue.
** Fixed a bug in get_entity_visibility (thanks VEN!).
** Removed non-existant take_damage() entry.
** Expanded XS Stock Library with addition of xs_vec_make2d.
** Expanded usage of cs_set_user_vip().
** Improved get_brush_entity_origin() and ViewContents (thanks Orangutanz!).

* Plugin Changes:
** Added amx_showrcon command to show rcon results in admincmd.sma.
** Added weapon restriction compatibility for bots in CS (KWo).
** Upgraded admin.sma to the new SQLX API.
** Fixed a bug in amx_reloadadmins not giving admins new access.
** Fixed a weapon restriction exploit in restmenu.sma.
** Fixed an HTML exploit in /top15 displaying player names.
** Fixed various and plentiful amx_addadmin bugs.
** Fixed telemenu.sma not letting you teleport yourself (thanks jtp10181!).
** Fixed a bug with adminslots.sma lowering the slots by 1.
** Fixed overlapping hud messages with miscstats.

* Module API Changes:
** Added and fixed module API for inter-module communication.
** Added native overriding and replacing to module API.
** Added plugin unloading/unloaded callbacks to module API.
** Added MSVC8 project files to most CVS projects.

* Configuration Changes:
** Added amx_sql_type cvar to sql.cfg.
** Re-organized and simplified modules.ini.
** Error logging can now be redirected to separate logs.
** Fixed modules.ini parsing bugs and simplified parsing.
** Fixed a double entry in cvars.ini.

* Other Changes:
** Added a Bulgarian translation (thanks lubb!).
** Added a leetspeak translation (thanks, I think, Twilight Suzuka!).
** Updated the GeoIP library to June.
** Updated PCRE from v6.1 to v6.4.
** Updated sqLite from 3.3.4 to 3.3.5.
** Fixed a steam account path bug in the installer.

[[Category:AMX Mod X]]

AMX Mod X 1.75 Scripting Changes

2006-06-04T21:57:41Z

Faluco:

The AMX Mod X 1.75 release made important changes. While backwards compatibility was kept, intended functionality shifted in esoteric areas that will affect some plugins. Reading this article is highly recommended.

=Module Requirement System=
As part of the new Automatic Module Loading, the old <tt>#pragma library</tt> has been deprecated. You must now use:
<pawn>#pragma reqlib <library>
</pawn>
This means "require library". Plugins still compiled with <tt>#pragma library</tt> will still fail on load if the given module is not found. However, core will try to load each module given the rules below under "Automatic Module Loading".

=Automatic Module Loading=
==Overview==
As of AMX Mod X 1.75, there is a new, powerful automatic module loading system. That means that <tt>modules.ini</tt> is largely deprecated for general use. Instead, modules are loaded as plugins need them. This is done dynamically by core before plugins are even loaded, without the need to patch <tt>modules.ini</tt> and then change the map.

Modules can now define "Libraries" and "Library Classes". A library is a specific identifier that should match the filename of the module. For example, Engine's defined library is "engine". FakeMeta's library is "fakemeta", and so on.

A "library class" defines membership to a set of modules. For example, CSX has the library name "csx", but it is part of the library class "xstats". Library classes are also used for DBI and SQLX. This is very useful for being able to require one module type of any implementation.

==New API==
===Compiler Pragmas===
This is expanded with a number of new <tt>#pragma</tt> directives:
*<tt>#pragma reqlib <library></tt> - Requires that a given library must be loaded.
*<tt>#pragma reqclass <libclass></tt> - Requires that a given library class must be loaded.
*<tt>#pragma loadlib <library></tt> - Automatically attempts to load a given library (see more info below).
*<tt>#pragma expectlib <library1> <library2></tt> - If the first library is not loaded, the second one will be attempted to load (not very useful).
*<tt>#pragma expectclass <class> <library></tt> - If the expected class is not found, the given library will be attempted to load. This is useful for defining a default module to be loaded with a given class of modules.
*<tt>#pragma defclasslib <class> <library></tt> - Same as <tt>expectclass</tt>, however, <tt>defclasslib</tt> waits until all expectations are resolved. This lets plugins override defaults by adding their own expectations.

===Module Filtering===
The module_filter prototype now includes a second parameter, which tells you whether the requirement is a class or library.

Furthermore, module_exists has been deprecated for LibraryExists().

==How it Works==
The precise order of events is as follows:
*When the first entity is spawned, AMX Mod X loads all unloaded modules in <tt>modules.ini</tt>.
*After <tt>modules.ini</tt> is parsed, <tt>plugins.ini</tt> is read. Each file is mapped into a cache.
*The cache is previewed.
**First, the "library" table is read. This table is read for backwards compatibility with AMX Mod X 1.71 and prior. Each entry is read as a module file shortname, and the module is loaded if it exists.
**Next, the "pubtags" table is read. Each entry is decoded to one of the special #pragma commands.
***All loadlib commands are executed, and the modules loaded.
***All expect commands are executed.
***All defclasslib commands are executed.
*AMX Mod X then waits until ServerActivate is called.
*All plugins are loaded. If the plugin is in the cache, the cache is read instead. For each plugin...
**The library table is read. For each library that is both nonexistant and unhandled by a module filter, the plugin fails to load.
**The pubtags table is read. For each reqlib and reqclass entry that are both nonexistant and unhandled by a module filter, the plugin fails to load.
*The plugin cache is invalidated and the server is considered "loaded".

=SQLX=
==Introduction==
SQLX is a new Database API that supercedes DBI. Its main feature is that you can load two SQLX modules at once, whereas you cannot with DBI. It also supports threaded queries, which let you process data without interrupting gameplay from a bad network connection.

These additions come at a hefty price. The SQLX API is significantly more complex than DBI. Although some might find it easier to use due to its simpler error checking and iteration, it requires more manual memory management and has less simple abstraction. Furthermore, taking advantage of the new <tt>SQL_ThreadQuery</tt> native will require nothing short of a rewrite for most plugins, as it is ''asynchronous'' instead of ''synchronous''. Because of this, the new SQLX modules also implement the old DBI functionality, for both backwards compatibility and for plugin developers familiar with the old API. All three APIs - SQL-threaded, SQL-non-threaded, and DBI, are still fully supported.

==Usage==
Since SQLX is an expansive API, showing a single plugin of its usage would be difficult. It is highly recommended that users interested in the new API look at the [http://cvs.tcwonline.org/viewvc.cgi/amxmodx/plugins/testsuite/sqlxtest.sma?view=log SQLxTest] plugin, which compares two different DBI methods and both SQL methods of querying a database. It is highly useful for both regression testing and for getting an idea of how the API works.

The most important concept of SQLX is "Handles," which are a precursor to a system planned for SourceMod. Handles are datatypes that store internal information that you should not modify. Whenever you create a handle, you must also free it, with <tt>SQL_FreeHandle</tt>().

==Native Overview==
The basic natives of SQLX are:
*<tt>SQL_MakeDbTuple</tt> (or simple stock version, <tt>SQL_MakeStdTuple</tt>) - This creates a variable that holds information about a database. It does not connect to the database. This is so you don't have to keep retrieving cvar info on every connection. You do not have to free these handles, although it is a good idea if you create them dynamically.
*<tt>SQL_Connect</tt> - Connects to a database and returns a new Handle, or <tt>Empty_Handle</tt> on failure.
*<tt>SQL_PrepareQuery</tt> - Prepares a query for execution, and returns a new Handle to the query.
*<tt>SQL_Execute</tt> - Executes a prepared query, and returns 0 on failure (1 on success).
*<tt>SQL_MoreResults</tt> - Returns 1 if there are more results in the query result queue, 0 if none.</tt>
*<tt>SQL_ReadResult</tt> - Reads the current row result by the column's numerical index, similar to dbi_field/dbi_result.
*<tt>SQL_NextRow</tt> - Advances to the next result row. '''Compatibility Warning''': This does not need to be called first! Unlike <tt>dbi_nextrow</tt>, the query is automatically at the first row. If you call <tt>SQL_NextRow</tt> before <tt>SQL_ReadResult</tt>, your are actually skipping a row.
*<tt>SQL_FreeHandle</tt> - Frees a Handle. You must do this or else memory will leak.
*<tt>SQL_ThreadQuery</tt> - Places a query and connection info into a threaded queue. In another thread, the connection is established, the query is executed, and the connection is dropped. The query results are then posted back into the main thread and given to the plugin on the next server-frame.
**Note that while powerful, the mechanism is very simplistic. Similar to <tt>set_task</tt>, you must differentiate multiple queries having the same callback by packing binary data into an array. Furthermore, you can only make one query at a time, since the queue is "push one, resolve one, pop one." If you plan on making five queries in a row in order to get aggregate information about a player, you must make each of these five queries in separate stages, and you must also take into account asynchronous factors such as the player dropping during the middle of a query. (One way to do this is to pack the player's authid and client index into the callback data and verify it when the query finishes.)

=New Natives / Native Changes=
==Register Message==
The <tt>register_message</tt> set of natives, including <tt>get/set_msg_block</tt>, has been moved to Core. This is to facilitate users who prefer to use FakeMeta, and like the simplicity and speed of using Engine's message interception functions.
 
This change is backwards compatible.

==Argument Formatting==
The <tt>format_args</tt> function is now replaced with a much faster, more compatible <tt>vformat</tt> function. Its usage is slightly different (read the include file, <tt>string.inc</tt>), but it accepts %L, whereas format_args does not. A quick example:
<pawn>debugprint(const fmt[], ...)
{
static temp[2048]
vformat(temp, sizeof(temp)-1, fmt, 2)
log_message("[DEBUG] %s", temp)
}</pawn>

==Other Core Natives==
*<tt>register_plugin</tt> - Now returns a plugin id.
*<tt>get_amxx_verstring</tt> - Returns the AMX Mod X version string.
*<tt>get_weaponid</tt> - Gets a weapon id from a weapon name.

==FakeMeta==
===New Natives===
*<tt>get_orig_retval</tt> - Gets the original return value of an engine or game DLL function.
*<tt>copy_infokey_buffer</tt> - Copies the given infobuffer pointer into output buffer.
*<tt>get/set_cd</tt> - Gets or sets members of a clientdata data structure (used with UpdateClientData).
*<tt>get/set_es</tt> - Gets or sets members of an entity_state data structure (used with AddToFullPack).
*<tt>get/set_uc</tt> - Gets or sets members of a usecmd data structure (used with CmdStart).

===New Engine/GameDLL Functions===
The <tt>register_forward</tt> native now allows for hooking a number of new functions from the engine or game DLL including:
*<tt>UpdateClientData</tt>
*<tt>AddToFullPack</tt>
*<tt>CmdStart</tt>
*<tt>CmdEnd</tt>
*<tt>CreateInstBaselines</tt> - Game DLL function
*<tt>CreateInstBaseline</tt> - Engine function
*<tt>CreateBaseline</tt>
*<tt>GetInfoKeyBuffer</tt>
*<tt>AlertMessage</tt> - This now can be called via <tt>engfunc</tt>
*<tt>ClientPrinf</tt>

These functions can also be called via <tt>engfunc</tt> or <tt>dllfunc</tt>.

===Breaking Changes===
Using <tt>engfunc</tt> in order to call <tt>EngFunc_InfoKeyValue</tt>, <tt>EngFunc_SetKeyValue</tt>, or <tt>EngFunc_SetClientKeyValue</tt> now requires passing an infobuffer pointer. An infobuffer pointer can be obtained by calling <tt>EngFunc_GetInfoKeyBuffer</tt>. For example:
<pawn>some_function(id, name[])
{
new infokey = engfunc(EngFunc_GetInfoKeyBuffer, id)
engfunc(EngFunc_SetClientKeyValue, id, infokey, "model", name)
}</pawn>

If you hook ClientUserInfoChanged via Fakemeta, an infobuffer pointer is now also forwarded to your function in addition to the client id.

==Cstrike==
*<tt>cs_get_user_mapzones</tt> - Returns bitwise flags of where on the map a player is located such as buy zone, bomb site, hostage rescue zone, VIP safety zone, and escape zone.
*<tt>cs_set_user_vip</tt> - Now takes two additional (but optional) parameters for determining whether or not the player model and scoreboard get updated.

==New Stocks==
===Engine===
*<tt>IsInWorld</tt> - Checks if an entity is within the bounds of the world (from HLSDK).

===FakeMeta===
*<tt>DF_UpdateClientData</tt> - Calls UpdateClientData game DLL function.
*<tt>DF_AddToFullPack</tt> - Calls AddToFullPack game DLL function.
*<tt>DF_CmdStart</tt> - Calls CmdStart game DLL function.
*<tt>DF_CmdEnd</tt> - Calls CmdEnd game DLL function.
*<tt>DF_CreateBaseline</tt> - Calls CreateBaseline game DLL function.
*<tt>DF_CreateInstBaselines</tt> - Calls CreateInstancedBaselines game DLL function.
*<tt>EF_CreateInstBaseline</tt> - Calls CreateInstancedBaseline engine function.
*<tt>EF_GetInfoKeyBuffer</tt> - Calls GetInfoKeyBuffer engine function.
*<tt>EF_ClientPrintf</tt> - Calls ClientPrintf engine function.

==New Constants==
Various sound constants (<tt>SND_SPAWNING</tt>, <tt>SND_STOP</tt>, <tt>SND_CHANGE_VOL</tt>, and <tt>SND_CHANGE_PITCH</tt>) from the HL SDK as well as a constant for pi were added to <tt>amxconst.inc</tt>. <tt>TE_*</tt> (temp entity) message constants have also been added which will automatically be included with <tt>#include <amxmodx></tt>. And finally, a new <tt>hlsdk_const.inc</tt> file has been added that contains many more constants from the SDK. This is automatically included with <tt>#include <engine></tt> or <tt>#include <fakemeta></tt>.

=Module API=
The AMX Mod X module API received a small overhaul for 1.75.

==Versioning/Interface Additions==
The internal module interface version is 4. However, modules from M/SDK 3 will still load.

M/SDK Version 4 modules have two new members of public information: the library string, and the library class string. These contain comma delimited names of whatever libraries or library classes the module would like to be registered.

For backwards compatibility, M/SDK Version 4 modules have an automatically empty library class string, and a library string equal to the logtag string.

==New Callbacks==
Modules can now be informed of when plugins are about to be unloaded, and when plugins have been fully unloaded. This means that modules don't have to hook ServerActivate and ServerActivate_Post (implementation dependent), don't need to be loaded by Metamod, and don't need to detach simply to release resources.

==New Functions==
*<tt>MF_GetLocalInfo</tt> - Intended for modules using LOCALINFO, which required a Metamod attachment. This is equal to AMX Mod X's core function <tt>get_localinfo</tt>.
*<tt>MF_OverrideNatives</tt> - Given a native list, this specifies that any other module already providing these natives will no longer provide them. This was added to force backwards compatibility between SQLITE and MySQLX. Usage is not recommended.
*<tt>MF_FindLibrary</tt> - Essentially the same function as LibraryExists() for plugins.
*<tt>MF_AddLibraries</tt> - Adds a comma delimited list of libraries or library classes. You must specify a "parent" pointer that identifies the module. This is easily accomplished by taking the address of any static variable.
*<tt>MF_RemoveLibraries</tt> - Removes all library entries with the given parent pointer. This is useful if your module adds custom entries not in its defined list.

==MSVC8 Compatibility==
M/SDK Version 4 now contains preprocessor definitions for compatibility with Microsoft's Visual Studio 2005/8.0 (provided by [[User:Damaged Soul|Damaged Soul]]). These macros can be turned off in the <tt>moduleconfig.h</tt> file by uncommenting the definition of <tt>NO_MSVC8_AUTO_COMPAT</tt>.

=Minor Changes=
==Compiler Defines==
Since <tt>__DATE__</tt> was fixed in 1.75, the macro <tt>__TIME__</tt> was also added.

=Full Changelog=
This changelog is tentative. Developers will be editing it as things are changed.

* Core Changes
** Modules are now automatically loaded by detecting plugin usage.
*** modules.ini is now primarily deprecated, except for SQL and unsupported libraries.
** Added new SQLX modules. You can now load multiple SQL modules and toggle them per-plugin.
*** Added new SQL API called SQLX. DBI was kept backwards-compatible.
*** Added new function to thread SQL queries (which prevents lag from a bad connection).
** Fixed some very small memory leaks.
** Fixed binary logging building wrong on Linux.
** Fixed some debugging crashes.
** Fixed serious bug when creating plugin_pause/plugin_unpause forwards.
** Fixed serious crash bug involving set_hudmessage and plugins using high hudchannels.
** Added natives:
*** fputs()
*** get_weaponid()
*** rename_file()
*** vformat()

* Fakemeta Changes
** Added new hookable/callable functions:
*** AddToFullPack
*** AlertMessage
*** ClientPrintf
*** ClientUserInfoChanged
*** CmdEnd
*** CmdStart
*** CreateBaseline
*** CreateInstancedBaseline
*** GetInfoKeyBuffer
*** InfoKeyValue
*** UpdateClientData
*** SetClientKeyValue
*** SetKeyValue
** Added new natives:
*** copy_infokey_buffer
*** get_orig_retval
** Fixed various trace bugs in FakeMeta with certain natives.
** Fixed some unhooking on server-deactivate problems in FakeMeta.

* Scripting Changes:
** Added __DATE__ and __TIME__ auto-macros to the compiler.
** Added many HLSDK constants and improved include organization.
** Added new compiler #pragma directives for using the module autoloading system.
** Added cs_get_user_mapzones (thanks VEN!).
** Added IsInWorld() stock (thanks Twilight Suzuka!).
** Added nvault_remove().
** Moved register_message from Engine and into Core.
** Dynamic natives that are paused now also pause parent plugins (with an error).
** register_plugin() now returns the plugin ID.
** Fixed a corruption bug in strip_user_weapons().
** Fixed a bug in set_view() (thanks jtp10181!).
** Fixed is_in_viewcone() always returning 0.
** Fixed is_visible causing a crash, improved accuracy.
** Fixed a crash bug in get_tr2() (thanks Orangutanz!).
** Fixed cs_get_user_buyzone() returning existence in other areas.
** Fixed a rare floatround() bug where values ending strictly in .5 were IEEE rounded.
** Fixed a bug where removing the current parent task could damage the task queue.
** Fixed a bug in get_entity_visibility (thanks VEN!).
** Removed non-existant take_damage() entry.
** Expanded XS Stock Library with addition of xs_vec_make2d.
** Expanded usage of cs_set_user_vip().
** Improved get_brush_entity_origin() and ViewContents (thanks Orangutanz!).

* Plugin Changes:
** Added amx_showrcon command to show rcon results in admincmd.sma.
** Added weapon restriction compatibility for CS (KWo).
** Upgraded admin.sma to the new SQLX API.
** Fixed a bug in amx_reloadadmins not giving admins new access.
** Fixed a weapon restriction exploit in restmenu.sma.
** Fixed an HTML exploit in /top15 displaying player names.
** Fixed various and plentiful amx_addadmin bugs.
** Fixed telemenu.sma not letting you teleport yourself (thanks jtp10181!).
** Fixed a bug with adminslots.sma lowering the slots by 1.
** Fixed overlapping hud messages with miscstats.

* Module API Changes:
** Added and fixed module API for inter-module communication.
** Added native overriding and replacing to module API.
** Added plugin unloading/unloaded callbacks to module API.
** Added MSVC8 project files to most CVS projects.

* Configuration Changes:
** Added amx_sql_type cvar to sql.cfg.
** Re-organized and simplified modules.ini.
** Error logging can now be redirected to separate logs.
** Fixed modules.ini parsing bugs and simplified parsing.
** Fixed a double entry in cvars.ini.

* Other Changes:
** Added a Bulgarian translation (thanks lubb!).
** Added a leetspeak translation (thanks, I think, Twilight Suzuka!).
** Updated the GeoIP library to June.
** Updated PCRE from v6.1 to v6.4.
** Updated sqLite from 3.3.4 to 3.3.5.
** Fixed a steam account path bug in the installer.

[[Category:AMX Mod X]]