| 1 |
root |
1.1 |
Plugin Information: |
| 2 |
|
|
This plugin information is provided by Yann Chachkoff |
| 3 |
|
|
|
| 4 |
|
|
Administrative commands (only available in DM mode): |
| 5 |
|
|
---------------------------------------------------- |
| 6 |
|
|
pluglist |
| 7 |
|
|
|
| 8 |
|
|
Lists all loaded plugins. Each plugin is identified in Crossfire by a |
| 9 |
|
|
keyword; pluglist shows those keywords, as well as a short text describing |
| 10 |
|
|
each plugin (usually a version string). If no plugin is loaded, the list will |
| 11 |
|
|
simply appear empty. The keyword for the Python plugin is Python. |
| 12 |
|
|
|
| 13 |
|
|
plugout <keyword> |
| 14 |
|
|
|
| 15 |
|
|
Unloads a given plugin, identified by its _keyword_. So if you want to unload |
| 16 |
|
|
the Python plugin, you need to do 'plugout Python'. |
| 17 |
|
|
|
| 18 |
|
|
plugin <libname> |
| 19 |
|
|
|
| 20 |
|
|
Loads a given plugin, whose _filename_ is libname. So in the case of Python, |
| 21 |
|
|
you'd have to do a 'plugin plugin_python.so.0.1'. Note that all filenames are |
| 22 |
|
|
relative to the default plugin path (SHARE/plugins). |
| 23 |
|
|
|
| 24 |
|
|
Console messages. |
| 25 |
|
|
----------------- |
| 26 |
|
|
When Crossfire starts, it tries to load all available files in the |
| 27 |
|
|
SHARE/plugins directory as plugin libraries. It first displays the |
| 28 |
|
|
'Initializing plugins:' message. Whenever a plugin has been loaded, the plugin |
| 29 |
|
|
has the opportunity to signal itself by a message on the console. Then the |
| 30 |
|
|
server displays an informative message containing both the plugin content and |
| 31 |
|
|
its keyword. For the Python plugin, the standard load process thus gives: |
| 32 |
|
|
|
| 33 |
|
|
Initializing plugins : |
| 34 |
|
|
-> Loading plugin : plugin_python.so |
| 35 |
|
|
Plugin CFPython Plugin 0.7 (Koursk) loaded under the name of Python |
| 36 |
|
|
Done |
| 37 |
|
|
|
| 38 |
|
|
When a plugin has been loaded, it can request to be warned whenever a global |
| 39 |
|
|
event occurs (global events are 'shout', 'login', 'death', and so on). When a |
| 40 |
|
|
plugin makes such a request, a message is displayed in the console log: |
| 41 |
|
|
|
| 42 |
|
|
Plugin Python (0) registered the event 13 |
| 43 |
|
|
|
| 44 |
|
|
It simply tells that the plugin associated with the keyword 'Python' asked to |
| 45 |
|
|
be warned whenever the global event Nr. 13 ('New player born') occurs. A |
| 46 |
|
|
complete list of events is available in the include/plugin.h file. |
| 47 |
|
|
|
| 48 |
|
|
Specific notes related to the Python plugin. |
| 49 |
|
|
-------------------------------------------- |
| 50 |
|
|
The Python plugin supports all global events. The constant PYTHON_DEBUG |
| 51 |
|
|
defined at the start of the plugin_python.c file increases the verbosity of |
| 52 |
|
|
the plugin. |
| 53 |
|
|
|
| 54 |
|
|
Global event scripts go into SHARE/maps/python/events, and are named |
| 55 |
|
|
python_xxx.py, where xxx is the name of the global event to intercept. If the |
| 56 |
|
|
file doesn't exist, nothing will happen. |
| 57 |
|
|
|
| 58 |
|
|
Some problems have already been reported about the autodetection of the Python |
| 59 |
|
|
libraries. Don't forget that you need the development files of Python (it |
| 60 |
|
|
means the 'libpython2.x.a' and some header files, including 'Python.h'). If |
| 61 |
|
|
configure fails whatever you try, you can still try to edit the plugin |
| 62 |
|
|
Makefile by hand. You need to: |
| 63 |
|
|
- Add your Python headers path to the INCLUDES= line. (for example: |
| 64 |
|
|
-I/usr/include/python2.2); |
| 65 |
|
|
- Add your Python library path to the PYTHON_LIB= line. (for example: |
| 66 |
|
|
/usr/lib/python2.2/config/libpython2.2.a) |
| 67 |
|
|
And then build the plugin after the server. Although I do not recommend this |
| 68 |
|
|
technique, it may help sometimes. |
| 69 |
|
|
|
| 70 |
|
|
Status of the logger and animator plugins isn't known. |
