The armagetronad-ct branch comes from an attempt to build armagetronad trunk with scripting enabled. As I faced issues compiling or running it with ruby, and the underlying wrapper, swig, support most of the common scripting language, I started this branch to add an abstraction layer, and eventually, introduce other scripting language support.

−

==Sample Scripts==

+

At this time, we were switching our script from php to python, and I was unable to compile with ruby, so I'd give Python a try ...

+

+

Armagetronad-ct is nothing but an experimental branch, as were armahacktron and sty+ct, based on armagetron trunk, currently being 0.3.x serie. Therefore, there are two major differences with sty+ct:

+

* sty is not (yet) fully ported to 0.3.x serie and has not been included to this branch. So no flags, no balls, no zombies, no shooting...

+

* although you can compile (still true?) trunk with zones v1 or v2, this branch has scripting support for zones v2 only...

−

<pre>

+

There's also a few extra features that comes from sty+ct or has been added to provide scripting support:

−

print("Start scripting initialization.")

+

* DELAY_COMMAND comes from sty+ct.

+

* INGAME_PARSING, INGAME_PARSING_DTD_VALIDATION and INGAME_PARSING_DTD allow to parse additional data during a round. It's meant to be use for zones. Any other parsing might be confusing and might lead to undefine behavior.

+

+

Although this branch main target is dedicated server, it might be extended to some client side features. For example, you can define new chat command from scripting on server side. This might be extended to client side soon as it allows to build dynamic instant messages (ex: /hi [<playername>] to salute last entered or specified player(s).

−

import sys, os

+

Eventually, if some servers start using it and this branch becomes somehow useful, we might extend it to other languages as ruby, lua or php, or polish it enough to deserve to be merged in its right place: armagetron mainline.

−

print os.getcwd()

+

−

sys.path.append('./src/swig/ext/')

+

−

import armagetronad

+

−

ci = armagetronad.tConfItemBase.FindConfigItem("CYCLE_SPEED")

+

==Install==

+

We are working on linux only and there's no support for any other plateform. So here is a raw install procedure for debian/ubuntu users :

The server expects to find scripting related files in a specific place: a subdirectory of armagetron data directory called "scripts".

+

More precisely, it expects to find a file called initialize.py. File extension vary depending on scripting language. So far, as only python support exists, we'll assume we are working with python as during install part.

+

+

The first step will be to set up out server specific directory tree. Personaly, I like to keep all config, var, and scripts directory in one place for a specific server. So let's start by setting up our directory tree:

+

/home/username/tron/servers/hello_scripting

+

./config

+

./var

+

./scripts

+

+

I'll assume you have include into the config subdir your config files.

+

+

So far, you'll have to copy the armagetronad.py file generated by swig during compilation into the scripts directory. This file is located into the src/swig/ext subdir in you source file directory (the armagetronad-ct directory from install step). Eventually, this file must be copied with other required files into the installation data scripts subdirectory. In this case, this directory should be append in initialize.py below.

+

Warning, don't forget to update this file each time you reinstall/update your armagetronad-dedicated binary.

+

+

You'll have to create the scripts/initialize.py file and include a few lines in it:

Any script procedure binded to a ladder log message must take a single argument (here named args). This argument is a list of 0 to n value of any type, depending on the value returned by corresponding ladder log message.

LadderLogWriter now allows multiple bindings, and unbinding too. This is particulary convinient to organize you script code and also to change bindings according to maps. There's no change in the binding logic. Unbinding is straighforward, too.

+

Please note that bindings are managed as a queue: they are run in the very same order they are bound to an event. There's no way to reorganize bindings other then remove and requeue them.

+

+

===Create new Commands\Settings===

+

You might be able to define new command from scripting. The new command will be available from console within the game, from other console commands like DELAY_COMMAND.