AlliedModders Wiki - User contributions [en]

AMX Mod X 1.76 Changes

2007-03-10T01:16:31Z

UserError: Removed duplicated change

AMX Mod X 1.76 is a small feature release and contains mostly bug fixes.
AMX Mod X 1.76a through 1.76d are small bug-fix releases to patch up problems with 1.76.
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.

=1.76d Changelog=
1.76d is a pending bug-fix release to the 1.76 branch.
==Core Changes==
*Core will now refuse to load plugins which violate the AMX Mod X license by not giving users the right to copy and modify source code under the GPL.
*Fixed a bug where '%c' did not correctly count toward string lengths. This resulted in problems with certain format(), vformat(), and vdformat() uses.
*Fixed {{Bug|41}}: Disabled items could sometimes be selected on menus when drawn with the newmenu system.
*Fixed {{Bug|35}}: Plugins could be loaded twice if they were duplicated in or across plugins files.
*Fixed {{AMBug|49892}}: Load failures went to normal logs instead of error logs.
*Fixed {{AMBug|51050}}: amxx pause/unpause could display misleading output.

==Scripting Changes==
*Fixed the compiler parsing #error directives in ignored #if blocks.
*Fixed {{AMBug|50089}}: The unary negation operator did not work on Floats.
*Fixed {{AMBug|49469}}: get_user_origin with mode <tt>4</tt> returned wildly inaccurate results.
*Fixed {{AMBug|49982}}: Many trace functions in FakeMeta did not pass a valid trace handle to plugins.
*Fixed {{AMBug|50501}}: unregister_forward() caused global problems with forwards.
*Fixed {{AMBug|49981}}: TR_InOpen was not a valid parameter for get/set_tr().
*Fixed {{AMBug|50680}}: ES_Body was not a valid parameter for get/set_es().
*Fixed {{AMBug|50731}}: The compiler crashed when including amxmisc before amxmodx.
*Fixed {{AMBug|51051}}: unpause() returned true on stopped plugins.
*Fixed {{AMBug|51276}}: fixed the cosh() stock not working.
*Fixed fwrite() accidentally writing two byte blocks when four-byte blocks are requested.
*Fixed a bug in forward_return() not handling non-string values correctly.
*Fixed a multitude of instances where the <tt>const</tt> keyword was not present on certain natives.

==Plugin Changes==
*Added {{AMBug|49977}}: idlekick.sma now uses faster cvars and fixes a potential bug with NS 3.2.
*Fixed a bug in statsx.sma where stats did not display on awkward mp_roundtime settings.
*Fixed a bug in amxmod_compat.sma where get_num_ents() did not work.
*Fixed a bug in admincmd.sma where amx_plugins did not count debug plugins as running.
*Fixed {{AMBug|50907}}: Names and tags for admins were case sensitive.
*Fixed {{AMBug|49214}}: admincmd.sma did not count debug plugins as "running."
*Fixed {{AMBug|49627}}: amx_addban now requires ADMIN_RCON access.

==Module Changes==
*The Natural Selection module has been updated for NS v3.2.

==Installer Changes==
*Fixed bug where the start directory wasn't listed correctly.
*Fixed no files being detected in some cases.
*Directory changes no longer crash on failure.
*Fixed bug where directories in / couldn't be found (unless user's root directory was /).
*Fixed installer failing if '.exe' files couldn't be uploaded.

=1.76c Changelog=
AMX Mod X 1.76c was released on December 24, 2006. Merry Christmas!

==Core Changes==
*Fixed {{AMBug|45370}}: Certain functions (such as kill_task and menu_destroy) could cause fatal plugin corruption. In safer instances, this resulted in a "HEAPLOW" error.
*Fixed a bug where calling menu_destroy() in a menu handler without returning PLUGIN_HANDLED caused a server crash.
*Fixed {{AMBug|48234}}: New menus with 10 items had the tenth item displayed as "10." As there is no such key, it is now "0" for consistency.

==Scripting Changes==
*Added {{AMBug|47144}}: Console-command registration functions (concmd, srvcmd, and clcmd) now return the id of the command instead of the value 1.
*Fixed {{AMBug|46924}}: arrayset() with non-zero values had unexpected results.
*Fixed {{AMBug|48294}}: SQL_MakeStdTuple() had a typo in a buffer size.

==Plugin Changes==
*Fixed {{AMBug|47617}}: restmenu.amxx weapon restrictions could be easily exploited by aliases which abused features of non-VGUI menus.
*Fixed {{AMBug|46960}}: pausecfg.amxx no longer leads users to unreachable states. As a side effect, plugins must now be hard-stopped through the console, rather than through the menu.
*Fixed {{AMBug|47134}}: admin_sql.amxx did not stop reading admins from the database once it had reached the maximum number of admins.
*Fixed {{AMBug|47842}}: telemenu.amxx had a permissions inconsistency.
*Fixed {{AMBug|48202}}: nscommands.amxx is now compatible with Natural Selection 3.2 beta.
*Fixed {{AMBug|48018}}: mapchooser.amxx would ignore "None" votes if "Extended" was the second highest choice.
*Fixed {{AMBug|48308}}: stats.amxx for DoD could throw a runtime error on certain erroneous double kills.
*Fixed {{AMBug|48522}}: map vote commands were not conforming to the vote access level flag.

==Module Changes==
*Fixed {{AMBug|47194}}: nVault could crash on Linux when reading back journals with long strings.
*Fixed {{AMBug|47988}}: nVault would crash if a full prune was done on a vault that had persistent keys.
*Fixed {{AMBug|27152}}: CSX would ignore the cvar value of csstats_rank_bots. This cvar now defaults to 0, and bots will no longer rank by default.

=1.76b Changelog=
AMX Mod X 1.76b was released on October 31st, 2006. Happy Halloween!
==Core Changes==
*Fixed {{AMBug|46213}}: New-style menus that had numbered blanks would cause Core to guess the item numbers wrong.
*Fixed {{AMBug|46266}}: Team name detection did not work for TFC.
*Fixed a bug where get_func_id() would crash on an invalid plugin.

==Scripting Changes==
*Added an optional timeout parameter to SQL_MkDbTuple().
*Added a "queuetime" parameter to threaded query handlers, to get the amount of time passed.
*Extended CreateMultiForward() with CreateMultiForwardEx() for filtering old/new plugins from forwards.
*Fixed {{AMBug|45337}}: SQLX_GetQueryString() did not work with threaded queries.
*Fixed {{AMBug|46350}}: geoip.inc having faulty a double-inclusion barrier.
*Fixed {{AMBug|46378}}: unregister_forward() attempted to remove from the wrong hook table.
*Fixed {{AMBug|46336}}: Vexd_Utilities.inc did not include VexdUM for AMX Mod Compat compiling.
*Fixed {{AMBug|46630}}: rename_file() could not use relative paths.

==Plugin Changes==
*Fixed {{AMBug|45990}}: amxmod_compat.amxx could conflict and crash hand-ported AMX Mod plugins.
*Fixed {{AMBug|46340}}: miscstats.amxx could throw an RTE finding the enemy team.
*Fixed {{AMBug|46335}}: adminchat.amxx color 'tsay' messages were not space aligned. Additionally, the leading space can now be omitted.
*Fixed {{AMBug|46699}}: stats.amxx for DoD did not display working multi-lingual menus.
*Fixed {{AMBug|46559}}: miscstats.amxx could throw an RTE if a player got more than 6 kills in a row.

==Module Changes==
*Fixed {{AMBug|45492}}: DoDX would overwrite the stats database on load.
==Other Changes==
*Fixed {{AMBug|46112}}: WinCSX.exe would not load properly on some versions of Windows.
*Fixed {{AMBug|45362}}: AMXX Studio did not indent correctly.

=1.76a Changelog=
AMX Mod X 1.76a was released on September 25, 2006.

==Core Changes==
*Fixed {{AMBug|44694}}: is_user_alive() on TFC returned false information when players joined.
*Fixed {{AMBug|45015}}: The translation string for ambiguous name matches was incorrect for English, Spanish, and German.
*Fixed {{AMBug|44956}}: The "extra plugin files" feature could break with more than two files after upgrading to 1.76.
*Fixed minor bugs in the installer, such as not detecting CHMOD properly.

==Plugin Changes==
*Fixed {{AMBug|45020}}: HE Grenade kill messages could interrupt each other in miscstats.sma.
*Fixed {{AMBug|45017}}: mapsmenu.sma contained an untranslated phrase.
*Fixed {{AMBug|40911}}: statsx.sma displayed last known attacker/victim stats to spectators.

==Module Changes==
*Fixed {{AMBug|44973}}: The CSX module incorrectly reported many knife kills as headshots.
*Fixed {{AMBug|44964}}: SQLX Threaded Queries could crash if passed an invalid database name.

=1.76 Changelog=
AMX Mod X 1.76 was released on September 17, 2006.

==Core Changes==
===New Features===
*The compiler has been heavily optimized and will now compile plugins much faster.
*Request {{AMBug|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.
*Added an experimental compatibility layer for AMX Mod. See [[AMX Mod Compatibility Layer (AMX Mod X)]] for more information.
*Request {{AMBug|42871}}: Source file name is shown in the binary logs when the plugin is in the debug mode.
*Request {{AMBug|44299}}: Error logs now show the mapname and current log file.
*The developer test suite is now packaged with Core in the scripting folder.

===Bug Fixes===
*Improved stability and eliminated weird bugs on Linux. These were caused by code generation bugs in GCC and appear to exist primarily in versions higher than 1.60.
*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 the JIT not being able to compute heaplow bounds problems.
*Fixed {{AMBug|41317}}: ExecuteForward() string parameters would be trashed on future internal string calls.
*Fixed {{AMBug|41777}}: time.txt was not included in the installer.
*Fixed {{AMBug|42213}}: "amx_logs" was incorrectly listed as "amx_logsdir" in core.ini.
*Request {{AMBug|41036}}: Improved bot detection.
*Fixed a rare bug where passing (1<<31) into a %d format-code would print garbage characters.

==Scripting Changes==
===Additions===
*Request {{AMBug|23838}}: Added natives to sort integers, floats, strings. Also added natives to sort custom 1D and 2D arrays using user comparison functions.
*Added vdformat() for formatting variable argument strings in dynamic natives.
*Added CreateLangKey() and AddTranslation() for manipulating the multilingual translator.
*Added SQL_GetInsertId() to MySQL and sqLite modules.
*For callfunc_push_str() and callfunc_push_array(), you can now specify an optional parameter to stop write-back on change.
*Request {{AMBug|42810}}: Added callfunc_push_array() to push an array through a callfunc.
*Request {{AMBug|42697}}: Added SQL_GetQueryString() to find the query string of a query handle.
*Request {{AMBug|29544}}: Added nvault_touch() native for updating key timestamps.
*Request {{AMBug|28110}}: Added tfc_get_user_goalitem() to determine if player is carrying a goal item (such as a flag or keycard)
*Request {{AMBug|41295}}: Added CZ model types to the CsInternalModel enumeration.
*Request {{AMBug|41635}}: All string formatting routines can now use '%u' to print integers as unsigned. Note that Pawn only supports signed arithmetic.
*Request {{AMBug|41585}}: Enhanced functionality of glb_pStringBase with global_get() and added a new return type to pev().
*Request {{AMBug|40967}}: set_fail_state() now logs that the plugin is failed.
*Request {{AMBug|41375}}: cs_set_weapon_silen() now has an additional parameter to toggle whether silencer animation is shown.
*Request {{AMBug|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.
*Added tfc_get/setweaponammo for ammo that is not in player's backpack.
*Engine's entity_get and entity_set routines no longer verify that players are fully ingame. This check was deemed too restrictive.
*Added hyperbolic trigonomic natives: floatsinh(), floatcosh(), and floattanh().

===Bug Fixes===
*Fixed {{AMBug|42916}}: get_user_aiming() did not work on Linux.
*Fixed {{AMBug|40963}}: GeoIP did not strip ports from IP addresses.
*Fixed {{AMBug|41483}}: xs.inc did not have double-include prevention.
*Fixed {{AMBug|43313}}: plugin_log() did not actually block log messages on returning PLUGIN_HANDLED.
*Fixed {{AMBug|42097}}: Hooking FM_ServerDeactivate did not work.
*Fixed {{AMBug|42307}}: nvault_open() did not return -1 on failure.
*Fixed {{AMBug|42383}}: SQL_ThreadQuery() was not working when called from plugin_end().
*Fixed {{AMBug|42321}}: TFC's Get/Set ammo natives did not work on Linux servers (thanks jRaven).
*Fixed {{AMBug|44776}}: user_silentkill() did not save the previous message block state.
*Fixed bug in get_user_aiming() where id and body would always be set to 0.
*Fixed bug in dllfunc() where DLLFunc_RegisterEncoders would not actually make a call.
*Fixed bug with floatatan() returning wrong values when trying to get angle in degrees or grades.
*Improved accuracy of is_user_bot().
*Rewrote replace_all() to address many serious bugs, including infinite replacements, improper re-indexing, and missed replacements.

==Plugin Changes==
===Additions===
*Request {{AMBug|41367}}: stats_logging.sma now logs extra weapons from CSX.
*Request {{AMBug|44517}}: Added "Spectator" to TFC plmenu.sma's team switch list (thanks jRaven).

===Bug Fixes===
*Fixed a potential memory corruption bug in StatsX.
*Fixed {{AMBug|42013}}: TFC team menu didn't allow for changing from blue team. Also, all plmenu plugins showed team change messages in the language of the admin.
*Fixed {{AMBug|41768}}: statssounds.sma for TS had the wrong plugin name.
*Fixed {{AMBug|41563}}: TFC plmenu.sma had the wrong team names.
*Fixed {{AMBug|41259}}: amx_addadmin was messing users.ini upon new entries.
*Fixed {{AMBug|43881}}: adminslots did not work until a mapchange was issued.

==Module Fixes==
*Fixed MySQLX threader on Linux locking up on mapchange if there were queries in the queue.
*Fixed {{AMBug|41030}}: All stats modules could generate files that would break the file parser.
*Fixed {{AMBug|41961}}: Fakemeta hooks for GetPlayerAuthId, GetPlayerWONId, and IsMapValid were not being reset on mapchange.
*Fixed {{AMBug|44428}}: GeoIP country codes were out of date.
*Updated the GeoIP library to September.

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

Optimizing Plugins (AMX Mod X Scripting)

2006-09-10T14:35:57Z

UserError: /* Always Save Results */

==Introduction==
[[Admin-Mod]] and [[AMX Mod X]] became very popular because of their easy to use scripting language. However, the words "scripting language" come with a lot of loaded preconceptions. Most people assume that because it's scripted:
*You can't possibly make it any faster
*It's pre-compiled, so it's already quite fast
*Details don't matter, as it's only "scripting" anyway

Especially, with [[Pawn]] (formerly Small), none of these are true. The compiler, in fact, is very poor at optimizing, and you can '''greatly''' increase the speed and efficiency of your plugins by keeping a few rules in mind. Remember - it's more important to minimize instructions than it is to minimize lines of code.

===Terms===
To read this document, you will need to understand a few concepts beforehand:
*<tt>BRANCHING</tt> - When the processor takes a different path of code. For example, to call a function or to use an if statement, the processor will "branch". Modern processors attempt to predict pathways with "branch prediction", but it's best to avoid branching a lot if possible.
*<tt>STACK ALLOCATION</tt> - In Pawn, all local data is stored on the stack, a big chunk of continuous memory. Whenever you create a variable on the stack, it is automatically written with zeroes.
*<tt>HEAP ALLOCATION</tt> - In Pawn, temporary data that needs to be referenced by a native is stored on the heap, another area of contiguous, but less restrictive memory.
*<tt>DATA SECTION</tt> - This is an area of memory built into your .amxx file. In fact, it "becomes" the heap at load time. All your strings and arrays are hardcoded into this area.
*<tt>EXPENSIVENESS</tt> - To be "expensive" in computer science means an operation requires a lot of CPU processing. It usually does not refer to memory size, only to processing cycles and time. Addition is inexpensive, floating power operations are expensive. However, both are inexpensive in comparison to writing a file. An inexpensive operation can also be called "cheap".
*<tt>BIG-OH NOTATION</tt> - O(*) notation refers to the expensiveness of an algorithm. If something is O(n), it occurs in linear time -- meaning that for N items, it will complete relative to N. O(N^2) means with N items, it will complete relative to N^2. O(1) means "constant time" - no matter what N is, it will run in the same amount of time.

==Compiler Optimizations==
These optimizations have to do with changing how your code is compiled. While the syntax may remain the same, you are not only increasing compile time, but increasing your plugin's efficiency and speed at run time.

===Always Save Results===
Observe the example code snippet below:
<pawn>if (get_user_team(player) == TEAM_T)
{
//...code
} else if (get_user_team(player) == TEAM_CT) {
//...code
} else if (get_user_team(player) == TEAM_SPECTATOR) {
//...code
}</pawn>
This is a mild example of "cache your results". When the compiler generates assembly for this code, it will (in pseudo code) generate:
<pre>
CALL get_user_team
COMPARE+BRANCH
CALL get_user_team
COMPARE+BRANCH
CALL get_user_team
COMPARE+BRANCH
</pre>
Notice the problem? We have called <tt>get_user_team</tt> an extra two times than necessary. The result doesn't change, so we can save it. Observe:
<pawn>new team = get_user_team(player)
if (team == TEAM_T)
{
//...code
} else if (team == TEAM_CT) {
//...code
} else if (team == TEAM_SPECTATOR) {
//...code
}</pawn>
Now, the compiler will only generate this:
<pre>
CALL get_user_team
COMPARE+BRANCH
COMPARE+BRANCH
COMPARE+BRANCH
</pre>
If <tt>get_user_team</tt> were an expensive operation (it's relatively cheap), we would have recalculated the entire result each branch of the <tt>if</tt> case.

===Switch instead of If===
If you can, you should use <tt>switch</tt> cases instead of <tt>if</tt>. This is because for an if statement, the compiler must branch to each consecutive <tt>if</tt> case. Using the example from above, observe the switch version:
<pawn>new team = get_user_team(player)
switch (team)
{
case TEAM_T:
//code...
case TEAM_CT:
//code...
case TEAM_SPECTATOR:
//code...
}</pawn>
This will generate what's called a "case table". Rather than worm through displaced <tt>if</tt> tests, the compiler generates a table of possible values, which the virtual machine knows to browse through:
<pre>
CALL get_user_team
COMPARE
COMPARE
COMPARE
</pre>

===Don't Re-index Arrays===
A common practice in Small is to "save space" by re-indexing arrays. There are a few myths behind this, such as saving memory, assuming the compiler does it for you, or readability. Fact: none of these are true. Observe the code below:
<pawn>new players[32], num, team
get_players(players, num)
for (new i=0; i<num; i++)
{
if (!is_user_connected(players[i]))
continue;
team = get_user_team(players[i])
set_user_frags(players[i], 0)
}</pawn>
For this, the compiler generates code similar to:
<pre>
:LOOP_BEGIN
LOAD i
LOAD players
CALC
LOAD players[i]
CALL is_user_connected
LOAD i
LOAD players
CALC
LOAD players[i]
CALL get_user_team
LOAD i
LOAD players
CALC
LOAD players[i]
CALL set_user_frags
</pre>
See what happened? The compiler does not cache array indexing. Because we've used <tt>players[i]</tt> each time, every instance generates 4-6 (or more) instructions which load <tt>i</tt>, the address of <tt>players</tt>, computes the final location, and then grabs the data out of memory. It is much faster to do:
<pawn>new player
for (new i=0; i<num; i++)
{
player = players[i]
if (!is_user_connected(player))
continue;
team = get_user_team(player)
}</pawn>
Not only is this more readable, but look at how much cruft we've shaved off the compiler's generated code:
<pre>
:LOOP_BEGIN
LOAD i
LOAD players
CALC
LOAD players[i]
STORE player
CALL is_user_connected
LOAD player
CALL get_user_team
LOAD player
CALL set_user_frags
</pre>
In a large loop you can drastically reduce codesize in this manner.

===Global vs Local and Variables in Loops===
It is important to realize that every variable in [[Pawn]] is automatically zeroed. For global variables, they are static and permanent, thus they are zeroed when your plugin is loaded. Variables in functions, however, must be zeroed dynamically. This is a slow and tedious operation, and you should not only avoid relying on it when necessary, but you should keep that fact in mind when using arrays.

[[Arrays]] in [[Pawn]] are "cells" of data. Each cell is four or eight bytes, depending on whether your processor is 32bit or 64bit. To create an array of 4096 cells, for example:
<pawn>new array[4096]</pawn>
The compiler generates code to manually zero every single one of the 16,384 bytes in that location. Normally, this isn't too bad -- but it can be absolutely deadly in a function which is called quite often. For example, <tt>server_frame</tt> is called on every [[server tick]] in [[AMX Mod X]]. To declare an array of that size in <tt>server_frame</tt> is highly unnecessary. Instead, you can take advantage of the fact that not only are globals free of charge, but <tt>server_frame</tt> does not need to be re-entrant. That is, you will never call <tt>server_frame</tt> inside of <tt>server_frame</tt>, so making the variable global will not bring up the problem of one instance of the function overwriting data from another instance of the same function. Observe:
<pawn>new g_serverframe_array[4096]
public server_frame()
{
//...code that uses g_serverframe_array
}</pawn>
This will execute conseridably faster. You can do this with smaller arrays too.

Likewise, it is equally important to avoid declaring arrays inside of loops. Consider the following block of code:
<pawn>for (new i=0; i<num; i++)
{
new message[255], name[32], player
player = players[i]
get_user_name(player, name, 31)
format(message, 254, "Hello, %s", name)
}</pawn>
If there are 32 players, this loop will actually resize and zero out over 1K of memory thirty two times in a row. Not good! However, on the other hand, it's nice that the message is zeroed out for us each time. <tt>Tip:</tt> you often only need to zero out the first character of a string. This will make the entire string empty. The code below is much more efficient:
<pawn>new message[255], name[32], player
for (new i=0; i<num; i++)
{
player = players[i]
name[0] = '^0'
message[0] = '^0'
get_user_name(player, name, 31)
format(message, 254, "Hello, %s", name)
}</pawn>
This has the effect of safely making the string empty beforehand, as well as largely reducing a lot of run-time overhead.

===Static vs Global===
An alternative to global variables is static variables, which are internally the same but easier to work with for programming.

A variable declared with the keyword "static" instead of "new" operates in the same way a global does (it is created only once) but the variable is local to the function; this means the code is much easier to read, while drastically improving speed just like a global variable. Example:
<pawn>stock SomeBigFunction()
{
static gaben[255];
format(gaben, "%L", LANG_SERVER, "STUFF");
}</pawn>

This has the same effect as declaring <tt>gaben</tt> as global, except only <tt>SomeBigFunction</tt> can use it.

{{qnotice|Be careful of re-entrancy!}}
When a variable is static, it has the same re-entrancy problems of a global variable. That means, if your function might be called recursively, or twice in the same stack frame, you should not use static variables. This is most often the case for API provided to other plugins or helper functions. Triggered events are usually never called twice on the same execution chain.

===Constant variables===
You can declare a variable "constant" by adding the "const" keyword before the variable name:

<pawn>new const AMX_GABEN[] = "amx_gaben"</pawn>

What this does is prevents the variable from being changed; essentially, you've locked the variable to a certain value. In this way, a constant can offer a type safe method of simplifying code, unlike a define, which is not type safe.

In addition, constant variables are often optimized out, resulting in quicker and smaller code.

===For Loop Comparisons===
A common mistake is to write code like this:
<pawn>new string[256] = "something long"
for (new i=0; i<strlen(string); i++)
//...code</pawn>
This plays off a similar principle from before: cache results. The compiler will actually recompute your string length on each iteration of the loop. This will have even worse effects if your string changes mid-loop. A more sensible method is:
<pawn>new string[256] = "something long"
new len = strlen(string)
for (new i=0; i<len; i++)
//...code</pawn>

==Tips and Tricks==
===Lookup Tables===
Precompute what can be precomputed. For example, say you have a mapping of weapon indices to names:
<pawn>if (weapon == CSW_AK47)
copy(name, len, "weapon_ak47")</pawn>
Ignoring the fact that we have <tt>get_weapon_name</tt> in [[AMX Mod X]], this is inefficient. We could precompute this result in a table:
<pawn>new g_WeaponNamesTable[TOTAL_WEAPONS][] = {
//..0 to CSW_AK47-1
"weapon_ak47",
//..CSW_AK47+1 to TOTAL_WEAPONS-1
};</pawn>

===Perfect Hashing===
:TODO: explain this

===Local Strings===
The [[Pawn]] compiler does not optimize the DATA section, which stores all hardcoded strings and global arrays. If you reference the same hardcoded string 500 times in your plugin, it will appear 500 different times. If this seems bad enough, it actually does this with all strings. For example, the empty string ("") appears everywhere in the include files, usually used as a default parameter to many natives. This too is copied into the data section for each unique reference.

For example:
<pawn>set_cvar_string("amx_gaben", get_cvar_string("amx_gaben") + 1)</pawn>
This will create two copies of "amx_gaben" in the DATA section. While this doesn't really hurt, it does increase the size of your plugin.

Similarly, this has the same problem:
<pawn>#define AMX_GABEN "amx_gaben"
set_cvar_string(AMX_GABEN, get_cvar_string(AMX_GABEN) + 1)</pawn>
The only way to avoid this mess is to use global variables. As stated earlier, they're basically free storage.
<pawn>new AMX_GABEN[] = "amx_gaben"
set_cvar_string(AMX_GABEN, get_cvar_string(AMX_GABEN) + 1)</pawn>

Again, while not necessary, this will reduce your plugin's size in memory and on disk. If you're already using defines, you can make this switch easily.

In order to prevent this from changing, you may want to declare it constant:

<pawn>new const AMX_GABEN[] = "amx_gaben"
set_cvar_string(AMX_GABEN, get_cvar_string(AMX_GABEN) + 1)</pawn>

Now it is a perfectly safe method of storage.

==Faster Natives==
AMX Mod X replaces many of the old AMX Mod natives with faster versions. Read below to discover them.

===Cvar Pointers===
As of AMX Mod X 1.70, you can cache "cvar pointers". These are direct accesses to cvars, rather than named access. This is a critical optimization which is dozens of times faster. For example:
<pawn>new g_enabled = register_cvar("csdm_enabled", "1")
//OR
new g_enabled = get_cvar_pointer("csdm_enabled")

stock SetCSDM(num)
set_pcvar_num(g_enabled, num)

stock GetCSDM()
return get_pcvar_num(g_enabled)
</pawn>
All of the cvar* functions (except for set_cvar_string) are mapped to [get|set]_pcvar_*. You can get a cached cvar pointer with get_cvar_pointer() or register_cvar().

===FormatEX===
As of AMX Mod X 1.70, there is an ultra high-speed version of format() called formatex(). It skips copy-back checking, unlike format(). formatex() cannot be used if a source input is the same as the output buffer. For example, these are invalid:
<pawn>new buffer[255]
formatex(buffer, 254, "%s", buffer);
formatex(buffer, 254, buffer);
formatex(buffer, 254, "%d %s", buffer[2]);</pawn>

It should be noted that format() will behave the same as formatex() if it detects that there will be no copy-back needed. However, formatex() does not check this, and thus is slightly faster for situations where the coder is sure of its usage.

===File Writing===
As of AMX Mod X 1.70, there are new natives for file writing. Read_file and write_file are O(n^2) functions for consecutive read/writes. fopen(), fgets(), fputs(), and fclose() are O(n) (or better) depending on how you use them.

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

Half-Life 1 Game Events

2006-09-05T10:09:37Z

UserError:

[[Category:Half-Life 1]]
[[Category:Scripting (AMX Mod X)]]
= Half-Life Events =
In [[Pawn]] you are able to hook in-game events with [http://www.amxmodx.org/funcwiki.php?go=func&id=26 register_event]. Here are the list of the standard Half-Life 1 and Counter-Strike events and their parameters which can be read with [http://www.amxmodx.org/funcwiki.php?go=func&id=132 read_data]

See the [[Advanced Scripting (AMX Mod X)#Events.2FMessages|Advanced Scripting]] article for more on events and messages.

== ADStop ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|ADStop}}
{{end-hl1msg}}

== AllowSpec ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|AllowSpec|byte}}
{{hl1msg|byte|unknown}}
{{end-hl1msg}}

== AmmoPickup ==
Temporarily draws [[HUD]] the ammo amount and ammo type [[HUD]] icon in the middle of the right side of the screen. 
{{qnotice|Draw time is dependent on the ''hud_drawhistory_time'' client CVAR value}}
{{begin-hl1msg|AmmoPickup|byte, byte}}
{{hl1msg|byte|AmmoID}}
{{hl1msg|byte|Ammount}}
{{end-hl1msg}}

== AmmoX ==
Updates green bar indicator in the [[HUD]] weapons-list. Also updates [[HUD]] backpack ammo number in the lower right corner of the screen in case the given ammo type are compatible with the current weapon.
{{begin-hl1msg|AmmoX|byte, byte}}
{{hl1msg|byte|AmmoID}}
{{hl1msg|byte|Ammount}}
{{end-hl1msg}}

== BarTime ==
Draws a [[HUD]] progress bar which is filled from 0% to 100% for the time Duration seconds and then disappeared. 
{{qnotice|Set Duration to 0 to hide the bar.}}
{{begin-hl1msg|BarTime|short}}
{{hl1msg|short|Duration}}
{{end-hl1msg}}

== BarTime2 ==
The same as BarTime but StartPC is specify how many per cents of the bar are (already) filled. 
{{qnotice|Display time can be calculated with this formula: ''(1 - StartPC/100) / Duration''}}
{{begin-hl1msg|BarTime2|short, short}}
{{hl1msg|short|Duration}}
{{hl1msg|short|StartPC}}
{{end-hl1msg}}

== Battery ==
Updates the icon and number of the armor on the [[HUD]].
{{begin-hl1msg|Battery|short}}
{{hl1msg|short|Armor}}
{{end-hl1msg}}

== BlinkAcct ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|BlinkAcct}}
{{end-hl1msg}}

== BombDrop ==
The first three arguments are the origin of the dropped bomb. The last argument is set to 1 if the bomb has been planted. It is 0 if the bomb was dropped due to voluntary dropping or death/disconnect. Setting the last argument 1, will also trigger the round timer to hide. It also will show the dropped bomb on the Terrorist team's radar in the location specified by the first three arguments.
{{begin-hl1msg|BombDrop|coord, coord, coord, byte}}
{{hl1msg|coord|X}}
{{hl1msg|coord|Y}}
{{hl1msg|coord|Z}}
{{hl1msg|byte|Flag}}
{{end-hl1msg}}

== BombPickup ==
This message just tells the game that the bomb has been picked up. It will cause the dropped/planted bomb to disappear from the Terrorist team's radar.
{{begin-hl1msg|BombPickup}}
{{end-hl1msg}}

== BotProgress ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|BotProgress}}
{{end-hl1msg}}

== BotVoice ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|BotVoice|byte, byte}}
{{hl1msg|byte|unknown}}
{{hl1msg|byte|unknown}}
{{end-hl1msg}}

== Brass ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|Brass}}
{{end-hl1msg}}

== BuyClose ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|BuyClose}}
{{end-hl1msg}}

== ClCorpse ==
Spawns a player's corpse. Model is the player's model, for example: "leet". Delay is the delay before animation plaback, can be negative value. 
{{qnotice|The Origin and Delay is in non-standard format.}}
{{begin-hl1msg|ClCorpse|string, long, long, long, coord, coord, coord, long, byte, byte, byte, byte}}
{{hl1msg|string|Model}}
{{hl1msg|long|OriginX}}
{{hl1msg|long|OriginY}}
{{hl1msg|long|OriginZ}}
{{hl1msg|coord|AngleX}}
{{hl1msg|coord|AngleY}}
{{hl1msg|coord|AngleZ}}
{{hl1msg|long|Delay}}
{{hl1msg|byte|Sequence}}
{{hl1msg|byte|unknown}}
{{hl1msg|byte|TeamID}}
{{hl1msg|byte|PlayerID}}
{{end-hl1msg}}

== Crosshair ==
Draws/removes the crosshair. If Flag is set to 1 the crosshair will be drawn.
{{begin-hl1msg|Crosshair|byte}}
{{hl1msg|byte|Flag}}
{{end-hl1msg}}

== CurWeapon ==
Updates the clip ammo number and weapon's corresponding ammo type icon on the [[HUD]].
{{begin-hl1msg|CurWeapon|byte, byte, byte}}
{{hl1msg|byte|isActive}}
{{hl1msg|byte|WeaponID}}
{{hl1msg|byte|ClipAmmo}}
{{end-hl1msg}}

== CZCareer ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|CZCareer}}
{{end-hl1msg}}

== CZCareerHUD ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|CZCareerHUD}}
{{end-hl1msg}}

== Damage ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|Damage|byte, byte, long, coord, coord, coord}}
{{hl1msg|byte|Damage save (armor)}}
{{hl1msg|byte|Damage take (health)}}
{{hl1msg|long|Damage type}}
{{hl1msg|coord|X}}
{{hl1msg|coord|Y}}
{{hl1msg|coord|Z}}
{{end-hl1msg}}

== DeathMsg ==
Fired to all players (MSG_ALL or MSG_BROADCAST) to notify them of a death. This generates the [[HUD]] message the client sees in the upper right corner of their screen. 
Also prints the console text message "KillerName killed VictimName with WeaponName" or "*** KillerName killed VictimName with a headshot from WeaponName ***"
{{begin-hl1msg|DeathMsg|byte, byte, byte, string}}
{{hl1msg|byte|KillerID}}
{{hl1msg|byte|VictimID}}
{{hl1msg|byte|isHeadshot}}
{{hl1msg|string|WeaponName}}
{{end-hl1msg}}

== FlashBat ==
Updates the flashlight battery charge on the [[HUD]]. ChargePC is in per cents.
{{begin-hl1msg|FlashBat|byte}}
{{hl1msg|byte|ChargePC}}
{{end-hl1msg}}

== Flashlight ==
Updates the flashlight state and battery charge on the [[HUD]]. If Flag is set to 1 the flashlight [[HUD]] icon will be shown as active.
{{begin-hl1msg|Flashlight|byte, byte}}
{{hl1msg|byte|Flag}}
{{hl1msg|byte|ChargePC}}
{{end-hl1msg}}

== Fog ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|Fog}}
{{end-hl1msg}}

== ForceCam ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|ForceCam}}
{{end-hl1msg}}

== HostageK ==
Temporary draws a blinking red dot on the CT players' radar when hostage is killed.
{{begin-hl1msg|HostageK|byte}}
{{hl1msg|byte|HostageID}}
{{end-hl1msg}}

== HostagePos ==
Draws/updates the blue mark on the CT players' radar which represents the corresponding hostage's position.
{{begin-hl1msg|HostagePos|byte, byte, coord, coord, coord}}
{{hl1msg|byte|unknown}}
{{hl1msg|byte|HostageID}}
{{hl1msg|coord|X}}
{{hl1msg|coord|Y}}
{{hl1msg|coord|Z}}
{{end-hl1msg}}

== Money ==
Updates the Amount of money on the [[HUD]]. If the Flag is 1, the additional new-old [[HUD]] money amount difference will be also displayed.
{{begin-hl1msg|Money|long, byte}}
{{hl1msg|long|Amount}}
{{hl1msg|byte|Flag}}
{{end-hl1msg}}

== NVGToggle ==
Toggles night vision mode. For Flag: 1 is on, 0 is off.
{{begin-hl1msg|NVGToggle|byte}}
{{hl1msg|byte|Flag}}
{{end-hl1msg}}

== ResetHUD ==
Resets the [[HUD]].
{{begin-hl1msg|ResetHUD}}
{{end-hl1msg}}

== RoundTime ==
Updates the round timer on the [[HUD]]. Time is in seconds.
{{begin-hl1msg|RoundTime|short}}
{{hl1msg|short|Time}}
{{end-hl1msg}}

== SayText ==
Prints say [[HUD]] text. Second parameter can be a predefined string or a custom one. In the last case the last two parameters isn't required. 
Some values of the predifined string: #Cstrike_Chat_AllDead, #Cstrike_Chat_All
{{begin-hl1msg|SayText|byte, string, string, string}}
{{hl1msg|byte|SenderID}}
{{hl1msg|string|String}}
{{hl1msg|string|unknown}}
{{hl1msg|string|Text}}
{{end-hl1msg}}

== Scenario ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|Scenario|byte}}
{{hl1msg|byte|unknown}}
{{end-hl1msg}}

== ScoreAttrib ==
Updates the scoreboard's attribute for the specified player. For the 2nd argument, 0 is nothing, 1 is dead, 2 is bomb, 4 is VIP. 
{{qnotice|Flag is a bitwise value so if VIP player dying with the bomb the Flag will be 7}}
{{begin-hl1msg|ScoreAttrib|byte, byte}}
{{hl1msg|byte|PlayerID}}
{{hl1msg|byte|Flag}}
{{end-hl1msg}}

== StatusIcon ==
Draws/removes the specified status [[HUD]] icon. For Status, 0 is Hide Icon, 1 is Show Icon, 2 is Flash Icon. Red, Green and Blue arguments is optional and is specified only when Status are not 0.
{{begin-hl1msg|StatusIcon|byte, string, byte, byte, byte}}
{{hl1msg|byte|Status}}
{{hl1msg|string|SpriteName}}
{{hl1msg|byte|Red}}
{{hl1msg|byte|Green}}
{{hl1msg|byte|Blue}}
{{end-hl1msg}}

== StatusText ==
Specifies the status text format.
{{begin-hl1msg|StatusText|byte, string}}
{{hl1msg|byte|unknown}}
{{hl1msg|string|Text}}
{{end-hl1msg}}

== StatusValue ==
Sends/updates the status values. For the Flag 1 the Value is TeamRelation, for 2 is PlayerID, for 3 is Health. For TeamRelation, 1 is Teammate player, 2 is Non-Teammate player, 3 is Hostage. If TeamRelation is the Hostage, PlayerID will be always 0. 
{{qnotice|Usually is fired as a triple message, for example: 
(1, 2) - non-teammate player 
(2, 7) - player index is 7 
(3, 59) - health is 59}}
{{begin-hl1msg|StatusValue|byte, short}}
{{hl1msg|byte|Flag}}
{{hl1msg|short|Value}}
{{end-hl1msg}}

== TaskTime ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|TaskTime}}
{{end-hl1msg}}

== TeamInfo ==
TeamName is either "UNASSIGNED", "TERRORIST" or "CT".
{{begin-hl1msg|TeamInfo|byte, string}}
{{hl1msg|byte|ID}}
{{hl1msg|string|TeamName}}
{{end-hl1msg}}

== TeamScore ==
Updates the team score on the score board. TeamName is either "TERRORIST" or "CT".
{{begin-hl1msg|TeamScore|string, short}}
{{hl1msg|string|TeamName}}
{{hl1msg|short|Score}}
{{end-hl1msg}}

== TextMsg ==
{{qnotice|There does not necessarily have to be a total of 6 arguments, there could be as little as 2. For example you can send a message with the following: 
Arg1: 1 
Arg2: #Game_join_ct 
Arg3: 4HM | Pimp Daddy }}
{{begin-hl1msg|TextMsg|byte, string, string, string, string, string}}
{{hl1msg|byte|ID}}
{{hl1msg|string|Message}}
{{hl1msg|string|Submsg}}
{{hl1msg|string|Submsg}}
{{hl1msg|string|Submsg}}
{{hl1msg|string|Submsg}}
{{end-hl1msg}}

== Train ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|Train}}
{{hl1msg|byte|unknown}}
{{end-hl1msg}}

== TutorClose ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|TutorClose}}
{{end-hl1msg}}

== TutorLine ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|TutorLine}}
{{end-hl1msg}}

== TutorState ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|TutorState}}
{{end-hl1msg}}

== TutorText ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|TutorText}}
{{end-hl1msg}}

== VGUIMenu ==
Displays a predefined VGUI menu. Keys is a keys bit sum.
{{begin-hl1msg|VGUIMenu|byte, short, char, byte, string}}
{{hl1msg|byte|unknown}}
{{hl1msg|short|Keys}}
{{hl1msg|char|unknown}}
{{hl1msg|byte|unknown}}
{{hl1msg|string|unknown}}
{{end-hl1msg}}

== ViewMode ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|ViewMode}}
{{end-hl1msg}}

== VoiceMask ==
{{qnotice|No Information available for this event}}
{{begin-hl1msg|VoiceMask|long, long}}
{{hl1msg|long|PlayersIndexBitSum}}
{{hl1msg|long|unknown}}
{{end-hl1msg}}

== WeapPickup ==
Fired right before weapon is picked up. 
{{qnotice|Notice: "right before".}}
{{begin-hl1msg|WeapPickup|byte}}
{{hl1msg|byte|WeaponID}}
{{end-hl1msg}}

FakeMeta General Usage (AMX Mod X)

2006-09-05T10:02:41Z

UserError: /* Return Values */

==Current FakeMeta and Old==
FakeMeta used to be an internal mini-metamod inside [[AMX Mod X]]. This was removed in 1.50, and now only the module remains. The module is an entirely different concept, which extends [[Metamod]] HL1 programming powers to scripts.

==About==
FakeMeta is an extremely powerful module for AMX Mod X that effectively allows you to write Metamod plugins in [[Pawn]].

Unlike Engine, FakeMeta uses no CPU if it is not told to do anything (other than to exist). For this reason, it is recommended to use FakeMeta over Engine. There is nothing in Engine that is not in FakeMeta -- while some functionality might be less [[Abstraction|abstracted]], it is still achievable, and usually with more flexibility.

==Engine vs. FakeMeta==

Comparison between Engine and FakeMeta:

FakeMeta:
<pawn>#include <amxmodx>
#include <fakemeta>

public plugin_init()
{
register_plugin("FakeMeta Test","1.0","Hawk552");

register_forward(FM_PlayerPreThink,"PreThink");
}

public PreThink(id)
{
// here you would insert some code

return FMRES_IGNORED;
}</pawn>

Engine:
<pawn>#include <amxmodx>
#include <engine>

public plugin_init()
{
register_plugin("Engine Test","1.0","Hawk552");
}

public client_PreThink(id)
{
// here you would insert some code

return;
}</pawn>

The "return FMRES_IGNORED" section will be covered later on this page.

==General Functionality==

FakeMeta also allows you to do other things, such as retrieve private data (using pev, set_pev / get_pdata_int, get_pdata_float, get_pdata_string, set_pdata_int, set_pdata_float, set_pdata_string), forcing DLL functions to be executed, as well as call Engine (not the module) functions.

==Entvars==
It is easy to read [[Entvars (Half-Life 1)|entvars]] in FakeMeta, however it can sometimes cause problems if not done correctly (which is why Engine is more commonly used). Entvars are variables in a player's [[Edicts (Half-Life 1)|edict]] structure (an edict is the basis for an entity).

Here is an example of how to retrieve the armor entvar from an entity in FakeMeta:
<pawn>#include <amxmodx>
#include <fakemeta>

public plugin_init()
{
register_plugin("FakeMeta Test","1.0","Hawk552");

register_forward(FM_PlayerPreThink, "PreThink");
}

public PreThink(id)
{
new value = pev(id,pev_armorvalue); // gets armor from client/entity

client_print(id,print_chat,"%i",value); // prints armor value to client

return FMRES_IGNORED;
}</pawn>

==DLL / Engine Function Usage==
In DLLs and the Engine, there are functions that are called when certain events happen. These can be forced to be called through FakeMeta. Here is a general example:

<pawn>#include <amxmodx>
#include <fakemeta>

public plugin_init()
{
register_plugin("FakeMeta Test","1.0","Hawk552");

register_forward(FM_PlayerPreThink,"PreThink");
}

public PreThink(id)
{
dllfunc(DLLFunc_RegisterEncoders);

return FMRES_IGNORED;
}</pawn>

Refer to the end of the line while viewing the DLLFunc and EngFunc sections, as there is usually some description of paramaters, such as ''edict_t *p_Entity'' or ''void''. ''void'' generally refers to no parameters, while ''edict_t *p_Entity'' means the entity id, so the first parameter in the function would be the entity to call the function onto.

==Return Values==
There are 4 return values in FakeMeta:

*FMRES_HANDLED --> Something was done in this function, but call the one in the DLL / Engine anyways.
*FMRES_SUPERCEDE --> Prevent function in DLL / Engine from being called.
*FMRES_IGNORED --> Call original function.
*FMRES_OVERRIDE --> Call original function, but change return value.

==Constants / General==
A list of general constants and usage can be found on this page:
http://www.amxmodx.org/funcwiki.php?go=module&id=16

[[Category : Scripting_(AMX_Mod_X)]]

FakeMeta General Usage (AMX Mod X)

2006-09-05T09:58:19Z

UserError: /* Engine vs. FakeMeta */

==Current FakeMeta and Old==
FakeMeta used to be an internal mini-metamod inside [[AMX Mod X]]. This was removed in 1.50, and now only the module remains. The module is an entirely different concept, which extends [[Metamod]] HL1 programming powers to scripts.

==About==
FakeMeta is an extremely powerful module for AMX Mod X that effectively allows you to write Metamod plugins in [[Pawn]].

Unlike Engine, FakeMeta uses no CPU if it is not told to do anything (other than to exist). For this reason, it is recommended to use FakeMeta over Engine. There is nothing in Engine that is not in FakeMeta -- while some functionality might be less [[Abstraction|abstracted]], it is still achievable, and usually with more flexibility.

==Engine vs. FakeMeta==

Comparison between Engine and FakeMeta:

FakeMeta:
<pawn>#include <amxmodx>
#include <fakemeta>

public plugin_init()
{
register_plugin("FakeMeta Test","1.0","Hawk552");

register_forward(FM_PlayerPreThink,"PreThink");
}

public PreThink(id)
{
// here you would insert some code

return FMRES_IGNORED;
}</pawn>

Engine:
<pawn>#include <amxmodx>
#include <engine>

public plugin_init()
{
register_plugin("Engine Test","1.0","Hawk552");
}

public client_PreThink(id)
{
// here you would insert some code

return;
}</pawn>

The "return FMRES_IGNORED" section will be covered later on this page.

==General Functionality==

FakeMeta also allows you to do other things, such as retrieve private data (using pev, set_pev / get_pdata_int, get_pdata_float, get_pdata_string, set_pdata_int, set_pdata_float, set_pdata_string), forcing DLL functions to be executed, as well as call Engine (not the module) functions.

==Entvars==
It is easy to read [[Entvars (Half-Life 1)|entvars]] in FakeMeta, however it can sometimes cause problems if not done correctly (which is why Engine is more commonly used). Entvars are variables in a player's [[Edicts (Half-Life 1)|edict]] structure (an edict is the basis for an entity).

Here is an example of how to retrieve the armor entvar from an entity in FakeMeta:
<pawn>#include <amxmodx>
#include <fakemeta>

public plugin_init()
{
register_plugin("FakeMeta Test","1.0","Hawk552");

register_forward(FM_PlayerPreThink, "PreThink");
}

public PreThink(id)
{
new value = pev(id,pev_armorvalue); // gets armor from client/entity

client_print(id,print_chat,"%i",value); // prints armor value to client

return FMRES_IGNORED;
}</pawn>

==DLL / Engine Function Usage==
In DLLs and the Engine, there are functions that are called when certain events happen. These can be forced to be called through FakeMeta. Here is a general example:

<pawn>#include <amxmodx>
#include <fakemeta>

public plugin_init()
{
register_plugin("FakeMeta Test","1.0","Hawk552");

register_forward(FM_PlayerPreThink,"PreThink");
}

public PreThink(id)
{
dllfunc(DLLFunc_RegisterEncoders);

return FMRES_IGNORED;
}</pawn>

Refer to the end of the line while viewing the DLLFunc and EngFunc sections, as there is usually some description of paramaters, such as ''edict_t *p_Entity'' or ''void''. ''void'' generally refers to no parameters, while ''edict_t *p_Entity'' means the entity id, so the first parameter in the function would be the entity to call the function onto.

==Return Values==
There are 4 return values in FakeMeta:
# FMRES_HANDLED
# FMRES_SUPERCEDE
# FMRES_IGNORED
# FMRES_OVERRIDE

*FMRES_HANDLED --> Something was done in this function, but call the one in the DLL / Engine anyways.
*FMRES_SUPERCEDE --> Prevent function in DLL / Engine from being called.
*FMRES_IGNORED --> Call original function.
*FMRES_OVERRIDE --> Call original function, but change return value.

==Constants / General==
A list of general constants and usage can be found on this page:
http://www.amxmodx.org/funcwiki.php?go=module&id=16

[[Category : Scripting_(AMX_Mod_X)]]

FakeMeta General Usage (AMX Mod X)

2006-09-05T09:57:28Z

UserError: /* Engine vs. FakeMeta */

==Current FakeMeta and Old==
FakeMeta used to be an internal mini-metamod inside [[AMX Mod X]]. This was removed in 1.50, and now only the module remains. The module is an entirely different concept, which extends [[Metamod]] HL1 programming powers to scripts.

==About==
FakeMeta is an extremely powerful module for AMX Mod X that effectively allows you to write Metamod plugins in [[Pawn]].

Unlike Engine, FakeMeta uses no CPU if it is not told to do anything (other than to exist). For this reason, it is recommended to use FakeMeta over Engine. There is nothing in Engine that is not in FakeMeta -- while some functionality might be less [[Abstraction|abstracted]], it is still achievable, and usually with more flexibility.

==Engine vs. FakeMeta==

Comparison between Engine and FakeMeta:

FakeMeta:
<pawn>#include <amxmodx>
#include <fakemeta>

public plugin_init()
{
register_plugin("FakeMeta Test","1.0","Author");

register_forward(FM_PlayerPreThink,"PreThink");
}

public PreThink(id)
{
// here you would insert some code

return FMRES_IGNORED;
}</pawn>

Engine:
<pawn>#include <amxmodx>
#include <engine>

public plugin_init()
{
register_plugin("Engine Test","1.0","Author");
}

public client_PreThink(id)
{
// here you would insert some code

return;
}</pawn>

The "return FMRES_IGNORED" section will be covered later on this page.

==General Functionality==

FakeMeta also allows you to do other things, such as retrieve private data (using pev, set_pev / get_pdata_int, get_pdata_float, get_pdata_string, set_pdata_int, set_pdata_float, set_pdata_string), forcing DLL functions to be executed, as well as call Engine (not the module) functions.

==Entvars==
It is easy to read [[Entvars (Half-Life 1)|entvars]] in FakeMeta, however it can sometimes cause problems if not done correctly (which is why Engine is more commonly used). Entvars are variables in a player's [[Edicts (Half-Life 1)|edict]] structure (an edict is the basis for an entity).

Here is an example of how to retrieve the armor entvar from an entity in FakeMeta:
<pawn>#include <amxmodx>
#include <fakemeta>

public plugin_init()
{
register_plugin("FakeMeta Test","1.0","Hawk552");

register_forward(FM_PlayerPreThink, "PreThink");
}

public PreThink(id)
{
new value = pev(id,pev_armorvalue); // gets armor from client/entity

client_print(id,print_chat,"%i",value); // prints armor value to client

return FMRES_IGNORED;
}</pawn>

==DLL / Engine Function Usage==
In DLLs and the Engine, there are functions that are called when certain events happen. These can be forced to be called through FakeMeta. Here is a general example:

<pawn>#include <amxmodx>
#include <fakemeta>

public plugin_init()
{
register_plugin("FakeMeta Test","1.0","Hawk552");

register_forward(FM_PlayerPreThink,"PreThink");
}

public PreThink(id)
{
dllfunc(DLLFunc_RegisterEncoders);

return FMRES_IGNORED;
}</pawn>

Refer to the end of the line while viewing the DLLFunc and EngFunc sections, as there is usually some description of paramaters, such as ''edict_t *p_Entity'' or ''void''. ''void'' generally refers to no parameters, while ''edict_t *p_Entity'' means the entity id, so the first parameter in the function would be the entity to call the function onto.

==Return Values==
There are 4 return values in FakeMeta:
# FMRES_HANDLED
# FMRES_SUPERCEDE
# FMRES_IGNORED
# FMRES_OVERRIDE

*FMRES_HANDLED --> Something was done in this function, but call the one in the DLL / Engine anyways.
*FMRES_SUPERCEDE --> Prevent function in DLL / Engine from being called.
*FMRES_IGNORED --> Call original function.
*FMRES_OVERRIDE --> Call original function, but change return value.

==Constants / General==
A list of general constants and usage can be found on this page:
http://www.amxmodx.org/funcwiki.php?go=module&id=16

[[Category : Scripting_(AMX_Mod_X)]]

Cross Compiling Plugins (Metamod:Source)

2006-08-20T23:41:48Z

UserError: /* Compiling Plugins */

==Introduction==
The aim of this tutorial is to allow Windows Half-Life 2 plugin coders to compile their plugins on the same machine as the windows binaries.
The binaries are compatible with 99% of all linux servers and do not suffer from bulky file sizes.
One of the main benefits to using this method of compiling is that your code can be left wherever you currently have it so that compile time reluctance is removed and coders can concentrate on coding the plugins instead of "How on earth am I to compile this for linux ???".
All you need to get started are the base Cygwin installation, the CrossTool.tar.gz file and the makefile. Links to the latter two are included at the end of the tutorial.

This tutorial assumes the following.
<OL>
<LI>You currently have a plugin which you can compile on windows using MSVC.
<LI>You have a copy of the HL2SDK Source Code installed on your hard drive.
<LI>You have a copy of the [http://www.sourcemm.net Metamod:Source] source code on your hard drive.
</OL>

Although the cross compiler will allow for compiling of Valves standard plugins, I do not include a Makefile or instructions on how to successfully accomplish this.

==Installing Cygwin==
First, download CygWin from [http://www.cygwin.com www.CygWin.com] by clicking on "Install Now" located in the middle of the page.

Once the download finishes, run setup.exe
Click 'Next' on the introduction screen.

On the second page, select 'Install from Internet'. 
The following page is all user preferances, except the 'Default Text File Type' which is recommended you use 'Unix / binary'. 
After clicking next, you are prompted for a CygWin temporary folder, any folder will suffice, the default is usually the better option. 
The next screen's options are firewall/proxy settings, these are specific to the Computer/Network you are currently using. 
Once you click next on the previous screen, the installer will download a list of mirror sites containing the CygWin binaries. Select one which you think is closest to you for a faster installation time. 
Finaly, you are presented with a 'Select Packages' screen. 
I *think* it should work fine without all of the dev packages. 

If anyone has gotten this to work by selecting less packages, please let me know so I can remove them from this list. 
Items marked in bold are extremely important. 

*binutils
*bzip2
*cygutils
*gcc
*glib
*gzip

*libiconv
*make
*zlib
*grep

Click next and it should install the packages to the target path you specified.


==Installing CrossTool==
Download the CrossCompiler from one of the mirrors below to the root cygwin folder (c:\cygwin).
If it gets renamed to 'crosstool_gcc-3.4.1.tar.tar' please rename it to 'crosstool_gcc-3.4.1.tar.gz'.
Download Mirrors for 'crosstool_gcc.tar.gz'
*[http://files.filefront.com/crosstool_gcc_341targz/;4650645;;/fileinfo.html FileFront]
*[http://downloads.punkassfraggers.com/redirect.php?dlid=1224 PunkAssFraggers.com]

This is the most important part of the entire tutorial.

Do not try and extract 'crosstool_gcc-3.4.1.tar.gz' using any Windows Archiving utility !
They do not extract the files correctly and if you don't get errors during the extraction, you will while trying to compile !
Once the download is complete, run cygwin by navigating to the cygwin root folder, and double clicking on 'cygwin.bat'.
Type the following two commands in order into the cygwin bash shell followed by the enter key:

cd /
tar -xzf crosstool_gcc-3.4.1.tar.gz

This will start extracting the tar file to the '<cygroot>/opt' folder on your hard drive.
And thats it, now you have the pre-compiled GCC 3.4.1 [http://www.lduke.com (Thanks LDuke)] installed on your computer you can compile server plugins for both regular and SourceMM flavours with ease and compatibility with Valves GCC 3.4.1 requirements.


==Compiling Plugins==
Download the Makefile by clicking on [http://www.c0ld.net/Tutorials/CrossTool/Makefile this link.]

Save it to your project's root source folder and open it with a text editor like notepad. 
Inside the Makefile I have shown examples on how your paths are translated into unix/cygwin hybrid paths. 
So, before trying any compling just yet, you need to insert the paths for the following. 

HL2SDK: The path to where your HL2SDK files are located. 
SMM_ROOT: The path to where you extracted the contents of the [http://www.sourcemm.net/ SourceMM package] 
SRCDS: The path to the linux SRCDS binaries. 
PLUGIN: The plugin filename. 

For the convenience of those who don't have access to a Linux srcds installation, you can grab the files required at one of the mirrors below. 
Extract them to a new folder which will be your SRCDS path in the Makefile. 
Note:The bin folder must be inside the srcds folder for maximum compatibility. For example, your files end up being something like this 'C:\MyFiles\srcds_l\bin\vstdlib_i486.so'.

So, in your Makefile, SRCDS would be '/cygdrive/c/MyFiles/srcds_l'

Download Mirrors for 'srcds_l_binaries.zip'
*[http://files.filefront.com/srcds_l_binarieszip/;4651213;;/fileinfo.html FileFront Mirror]
*[http://rapidshare.de/files/11597264/srcds_l_binaries.zip.html RapidShare.de Mirror]
Now you're ready to try compiling.
Back to the cygwin bash window, and we're now going to have to navigate to your code's location.
An example path could be 'C:\MyCode\MyPlugin\' so in the bash shell we type the following:

cd /cygdrive/c/MyCode/MyPlugin/
make

If all your paths are set correctly, it should start compiling the plugin.
Ignore all the warnings in the HL2SDK, they are harmless.
What you should be looking out for are errors and warnings located inside your own code.
Unfortunately I cannot compile plugins for you, but there is a forum dedicated to helping you with hl2sdk coding problems.

[http://forums.alliedmods.net/forumdisplay.php?f=75 Click here to visit the forum]

==Credits==
*Tutorial by: Jason "c0ldfyr3" Croghan
*Cross Compiler compiled by: L. Duke
*Makefile originally written by: David "BAILOPAN" Anderson
*Converted to Wiki by: James "sslice" Gray

Original Location: http://www.c0ld.net/index.php?inc=CrossTool

[[Category:Documentation (SourceMM)]]

Cross Compiling Plugins (Metamod:Source)

2006-08-20T23:14:53Z

UserError: /* Introduction */

==Introduction==
The aim of this tutorial is to allow Windows Half-Life 2 plugin coders to compile their plugins on the same machine as the windows binaries.
The binaries are compatible with 99% of all linux servers and do not suffer from bulky file sizes.
One of the main benefits to using this method of compiling is that your code can be left wherever you currently have it so that compile time reluctance is removed and coders can concentrate on coding the plugins instead of "How on earth am I to compile this for linux ???".
All you need to get started are the base Cygwin installation, the CrossTool.tar.gz file and the makefile. Links to the latter two are included at the end of the tutorial.

This tutorial assumes the following.
<OL>
<LI>You currently have a plugin which you can compile on windows using MSVC.
<LI>You have a copy of the HL2SDK Source Code installed on your hard drive.
<LI>You have a copy of the [http://www.sourcemm.net Metamod:Source] source code on your hard drive.
</OL>

Although the cross compiler will allow for compiling of Valves standard plugins, I do not include a Makefile or instructions on how to successfully accomplish this.

==Installing Cygwin==
First, download CygWin from [http://www.cygwin.com www.CygWin.com] by clicking on "Install Now" located in the middle of the page.

Once the download finishes, run setup.exe
Click 'Next' on the introduction screen.

On the second page, select 'Install from Internet'. 
The following page is all user preferances, except the 'Default Text File Type' which is recommended you use 'Unix / binary'. 
After clicking next, you are prompted for a CygWin temporary folder, any folder will suffice, the default is usually the better option. 
The next screen's options are firewall/proxy settings, these are specific to the Computer/Network you are currently using. 
Once you click next on the previous screen, the installer will download a list of mirror sites containing the CygWin binaries. Select one which you think is closest to you for a faster installation time. 
Finaly, you are presented with a 'Select Packages' screen. 
I *think* it should work fine without all of the dev packages. 

If anyone has gotten this to work by selecting less packages, please let me know so I can remove them from this list. 
Items marked in bold are extremely important. 

*binutils
*bzip2
*cygutils
*gcc
*glib
*gzip

*libiconv
*make
*zlib
*grep

Click next and it should install the packages to the target path you specified.


==Installing CrossTool==
Download the CrossCompiler from one of the mirrors below to the root cygwin folder (c:\cygwin).
If it gets renamed to 'crosstool_gcc-3.4.1.tar.tar' please rename it to 'crosstool_gcc-3.4.1.tar.gz'.
Download Mirrors for 'crosstool_gcc.tar.gz'
*[http://files.filefront.com/crosstool_gcc_341targz/;4650645;;/fileinfo.html FileFront]
*[http://downloads.punkassfraggers.com/redirect.php?dlid=1224 PunkAssFraggers.com]

This is the most important part of the entire tutorial.

Do not try and extract 'crosstool_gcc-3.4.1.tar.gz' using any Windows Archiving utility !
They do not extract the files correctly and if you don't get errors during the extraction, you will while trying to compile !
Once the download is complete, run cygwin by navigating to the cygwin root folder, and double clicking on 'cygwin.bat'.
Type the following two commands in order into the cygwin bash shell followed by the enter key:

cd /
tar -xzf crosstool_gcc-3.4.1.tar.gz

This will start extracting the tar file to the '<cygroot>/opt' folder on your hard drive.
And thats it, now you have the pre-compiled GCC 3.4.1 [http://www.lduke.com (Thanks LDuke)] installed on your computer you can compile server plugins for both regular and SourceMM flavours with ease and compatibility with Valves GCC 3.4.1 requirements.


==Compiling Plugins==
Download the Makefile by clicking on [http://www.c0ld.net/Tutorials/CrossTool/Makefile this link.]

Save it to your project's root source folder and open it with a text editor like notepad. 
Inside the Makfile I have shown examples on how your paths are translated into unix/cygwin hybrid paths. 
So, before trying any compling just yet, you need to insert the paths for the following. 

HL2SDK: The path to where your HL2SDK files are located. 
SMM_ROOT: The path to where you extracted the contents of the [http://www.sourcemm.net/ SourceMM package] 
SRCDS: The path to the linux SRCDS binaries. 
PLUGIN: The plugin filename. 

For the convenience of those who dont have access to a linux srcds installation, you can grab the files required at one of the mirrors below. 
Extract them to a new folder which will be your SRCDS path in the Makefile. 
Note:The bin folder must be inside the srcds folder for maximum compatibility. For example, your files end up being something like this 'C:\MyFiles\srcds_l\bin\vstdlib_i486.so'.

So, in your Makefile, SRCDS would be '/cygdrive/c/MyFiles/srcds_l'

Download Mirrors for 'srcds_l_binaries.zip'
*[http://files.filefront.com/srcds_l_binarieszip/;4651213;;/fileinfo.html FileFront Mirror]
*[http://rapidshare.de/files/11597264/srcds_l_binaries.zip.html RapidShare.de Mirror]
Now you're ready to try compiling.
Back to the cygwin bash window, and we're now going to have to navigate to your code's location.
An exmaple path could be 'C:\MyCode\MyPlugin\' so in the bash shell we type the following:

cd /cygdrive/c/MyCode/MyPlugin/
make

If all your paths are set correctly, it should start compiling the plugin.
Ignore all the warnings in the HL2SDK, they are harmless.
What you should be looking out for are errors and warnings located inside your own code.
Unfortunately I cannot compile plugins for you, but there is a forum dedicated to helping you with hl2sdk coding problems.

[http://forums.alliedmods.net/forumdisplay.php?f=75 Click here to visit the forum]

==Credits==
*Tutorial by: Jason "c0ldfyr3" Croghan
*Cross Compiler compiled by: L. Duke
*Makefile originally written by: David "BAILOPAN" Anderson
*Converted to Wiki by: James "sslice" Gray

Original Location: http://www.c0ld.net/index.php?inc=CrossTool

[[Category:Documentation (SourceMM)]]

User:UserError

2006-06-26T07:38:51Z

UserError:

An empty page? --[[User:UserError|UserError]] 03:38, 26 June 2006 (EDT)

User talk:UserError

2006-06-26T07:38:24Z

UserError:

Speak to me! --[[User:UserError|UserError]] 03:38, 26 June 2006 (EDT)

User:UserError

2006-06-26T07:38:03Z

UserError:

--[[User:UserError|UserError]] 03:38, 26 June 2006 (EDT)