AMX Mod X 1.75 Scripting Changes - Revision history

Slogic: /* Module Requirement Syusstem */

2006-12-22T19:13:40Z

‎Module Requirement Syusstem

MaximusBrood: Fixed dead link.

2006-11-11T22:48:08Z

Fixed dead link.

MaximusBrood at 22:41, 11 November 2006

2006-11-11T22:41:15Z

BAILOPAN: /* Native Overview */

2006-07-01T05:55:58Z

‎Native Overview

BAILOPAN: /* Native Overview */

2006-07-01T05:55:30Z

‎Native Overview

BAILOPAN at 10:03, 28 June 2006

2006-06-28T10:03:52Z

BAILOPAN: /* Full Changelog */ - added dod stuff

2006-06-11T22:46:17Z

‎Full Changelog: - added dod stuff

Zor: /* Stocks */

2006-06-11T21:44:39Z

‎Stocks

Zor: /* Stocks */

2006-06-11T21:42:47Z

‎Stocks

Zor at 21:41, 11 June 2006

2006-06-11T21:41:34Z

@@ Line 1: / Line 1: @@
 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 Syusstem=
+=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=

@@ Line 1: / Line 1: @@
 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=
+=Module Requirement Syusstem=
 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>
@@ Line 80: / Line 80: @@
 ==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.
+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://svn.tcwonline.org/viewvc.cgi/trunk/plugins/testsuite/sqlxtest.sma?root=amxmodx 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>().

← Older revision		Revision as of 22:41, 11 November 2006
Line 348:		Line 348:


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

@@ Line 96: / Line 96: @@
 *<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.)
-**Note that you should currently not call this native during plugin_end().  The backend threader freezes the query queue at this time and flushes all remaining queries back to the main thread.  It is likely your plugin will simply deadlock (freeze idly).  Even if this is corrected, there is no reason to use threaded queries in plugin_end() anyway, because all remaining threaded queries are executed as non-threaded before the mapchanges.
+**Note that you should currently not call this native during <tt>plugin_end</tt>().  The backend threader freezes the query queue at this time and flushes all remaining queries back to the main thread.  It is likely your plugin will simply deadlock (freeze idly).  Even if this is corrected, there is no reason to use threaded queries in <tt>plugin_end</tt>() anyway, because all remaining threaded queries are executed as non-threaded before the mapchanges.
 =New Natives / Native Changes=

@@ Line 96: / Line 96: @@
 *<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=

@@ Line 261: / Line 261: @@
 ** Added IsInWorld() stock (thanks Twilight Suzuka!).
 ** Added nvault_remove().
 ** Moved various natives from Engine and into Core:
 *** register_message

@@ Line 287: / Line 287: @@
 ** 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!).
-** Fixed some menu item calculation bugs on single paged menus.
+** Added core natives:
 *** fputs()
 *** get_weaponid()
 *** rename_file()
 *** vformat()
 * Plugin Changes:

@@ Line 163: / Line 163: @@
 ===Stocks===
-*<tt>dod_set_model(id, model[])</tt> - Sets the model for a player, good for if you want to have special models.  The models used MUST be located in the following directory:
+*<tt>dod_set_model(id, model[])</tt> - Sets the model for a player, good for if you want to have special models.  The models used MUST be located in the following directory: dod/models/player/ And should look something like this: dod/models/player/models-name/model-name.mdl dod/models/player/models-name/model-nameT.mdl
 *<tt>dod_set_body_number(id, bodynumber)</tt> - Sets the model number for a players model
 *<tt>dod_clear_model(id)</tt> - Turns off the special model for a player

@@ Line 155: / Line 155: @@
 *<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==