GgrTF is a framework of AND for triggers to ease playing of BatMUD with TinyFugue MUD-client. GgrTF is designed for modularity and easy development. Our primary development goals are good overall quality of code and maintainability. These are also some of the key elements, that differentiate GgrTF from most other publicly available scripts.

GgrTF is being developed for TF5 of TinyFugue MUD client under Linux and Solaris platforms. Users of GgrTF are mostly users of UNIX-like systems, but there are several who run TF under Microsoft Windows operating system. Version 0.6.9.15 was the last that supported TF4.

The current version (as of v0.7.4.1 release) has modules for following character classes:

In non-guild related sense, GgrTF has most of the basics expected from such triggerset. There is a prot-management and reporting system, skill- and spell-handling, way to easily run commands on each battle round (and more), plus following special modules:

And more ...

It is impossible to tell for certain, really. If you are averse of doing some digging of your own, or adjusting some trigger code, it may not be. GgrTF is meant to work as a "platform" and a base, not as a complete bells and whistles-type solution. In the end, you may have just to give it a try.

When I started working on GgrTF, I was just "scratching an itch", and that itch still continues, though few others have joined my efforts on scratching. During the two years I have been developing GgrTF, most of that time I've been scratching my own back, doing stuff mostly for myself. Thus, if you like the design decisions and features I like, play the same guilds as I (though some guilds which I haven't ever touched are supported through efforts of other developers) it is likely that you will like GgrTF.

Also GgrTF is not all that well documented (although that is one thing we are trying remedy) and requires basic knowledge of how TinyFugue and its macro language works. As such GgrTF is not a ready out-of-the-box experience for some users and never will be. However, if you are able to crank it up and working, and are content with what is readily offered, then it might be something for you.

All in all, GgrTF might be something for you, especially if you like things the way I like them. But on the other hand GgrTF might not be for you, and there are several alternatives out there for those who do not find it satisfactory. Below I have tried to list some pros and cons of using GgrTF.

Way back in march of 2004, I made one of the worst mistakes in my life - I created a character in BatMUD. I never thought of myself to be much of a gamer, I've always been more interested in more technical things, programming and a little bit of digital electronics and hardware, so mostly my gaming experience consisted of some c64 games, Nethack and some CRPGs like Fallout. I guess the RPG statmania was one reason that got me hooked in the first place, plus the multiplayer interaction and social aspects.

Started off playing with plain telnet for the first month or so, then installed TinyFugue, because it seemed to be the most popular of the clients available for UNIXish platforms. First I didn't use any triggers at all, TF was just there to work as better terminal and separating the input from output .. and the game was confusing enough to start with, triggers would have just complicated things. At least I felt so back then.

At some point, however, my playing style advanced and need for automating certain things became apparent. I researched some of the available scripts, but most of them were either badly designed, full of very apparent mistakes and bugs, or simply not maintained anymore. Some people (highbies mainly) seemed to have some good stuff, but as usual, they only shared inside small circles of their own.

Fancying myself as a programmer of some sort, off I went, developing my own piece of turf, starting out very simple, expanding and improving when needed. That continued for about a year or a bit over, then the situation got out of hand - I started "releasing" GgrTF periodically on my BatMUD related web-page.

The first ever released version of GgrTF was v0.3.0, which was extremely simple and hacky. It supported just channeller/mage stuff and had a broken prots management system. The 0.3.x-series continued up to 0.3.13 or so, after which some bigger changes were made and 0.4.0 was released.

At some point of 0.4.x-series development, more people started noticing GgrTF. I believe some even started using it, or at least used parts of it in their own code. v0.4.x was somewhat short-lived, soon major restructuring was done in the prot management system and it was time for 0.5.0. As the development progressed, it soon again became apparent that bigger changes were needed ... v0.5.5 was the last stable release in that series.

Development of the new features took somewhat longer time than originally expected, there were literally dozens of internal version landmarks (v0.5.6.x, v0.5.9.x, v0.5.10.x, v0.5.11.x and finally even v0.6.0-preX series), which preceeded the final v0.6.0-release in early august 2006. This new release marked a major improvement in code quality and number of features, and also this user's manual was included for the first time. It was also the first time when other people joined up and did some work on few features.

GgrTF is copyrighted (except where mentioned otherwise) by Matti Hämäläinen (aka Ggr Pupunen) and distributed under the GNU General Public License version 2.

Complete text of the GNU GPL v2 is included with the code in a file called COPYING.txt, and is also available here.

To get the latest stable version, head to the downloads-section of GgrTF's homepage and pick either the newest tarball (*.tar.gz) or zip-archive (*.zip):

Both package types also have equivalent PGP/GnuPG signature files (*.asc), which can be used to cryptographically verify the authenticity of files.

To "install" the package, you simply unpack it to appropriate directory, typically under your home directory. Under UNIX-style system:

After that, you should have directory $HOME/ggrtf/ with all the *.tf files in it. If so, you can continue to the configuration part.

Another way to get GgrTF is to go to the very source, the development source repository. This repository contains the latest bleeding edge features, but is also a fast moving target. Changes are directly committed by developers almost in real time, sometimes what you download may be severely broken. Also the documentation will not be updated for every little change, so you may have to figure out and work around possible backward incompatibilities yourself.

New features and bugfixes may sometimes be worth taking the risk. On the other hand, it is all up to what you want and whether you can manage to handle the possibly arising problems.

We utilize Mercurial (Hg) for GgrTF's version management. Mercurial is a freely available distributed version control system, for which there are clients available for most common platforms, including Windows, Linux and other flavours of UNIX.

GgrTF's Mercurial repository is hosted at tnsp.org, and is available from following location: https://tnsp.org/hg/batmud/ggrtf/. The same URL can be used with a web browser to browse version history.

Typical way to use GgrTF is to load the script modules at startup. This is accomplished via TinyFugue's configuration file, commonly referred as "tfrc", location of which depends on your operating system and environment.

As a basis for your TF configuration, you can use the example-tfrc.txt provided with GgrTF. You will need to edit it to suit your guilds and certain settings. However, the example-tfrc is only a suggested layout of configuration, mostly to show the order GgrTF requires modules and settings to be loaded. It does not contain everything you can possibly do with TF.

Take note of the order of how different parts of GgrTF are loaded and where certain variables are set. Important thing is to have the order right, certain modules depend on other modules, and while GgrTF will usually print warning message(s) if the depencies are not met, sometimes this is not possible and erratic behaviour will occur.

;; Turn logging off, while we set things up
/log off

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Personal settings
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Set player name before loading scripts
/eval /set set_plrname=Ggr

;; Savefiles should be stored under $HOME/.ggrtf/
/eval /set set_datapath=%{HOME}/.ggrtf/

;; We want savefiles to use filename prefix "bat-"
/eval /set set_saveprefix=bat-


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Character set / locale
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; You MAY need to set your character set encoding/locale to have
;; non-ASCII characters work properly in BatMUD. This is outside of
;; the scope of GgrTF, but it is discussed in more depth in the
;; user's manual.

;/setenv LANG=en_US.iso88591

;; You may also try following settings if ISO-8859-1 does not work:
; /setenv LANG=en_US.iso885915
; /setenv LANG=en_US.latin1


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Load GgrTF
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; We define a helper macro to load modules from
;; under user's home directory $HOME/ggrtf/
/def -i gloadmod = /eval /load %{HOME}/ggrtf/%{*}

;; Preloader module MUST be loaded first
/gloadmod ggrtf-pre.tf

;; And the main module after that ...
/gloadmod ggrtf.tf

;; Some useful modules: mangler, placer, spellname translator
/gloadmod gm-pssmangle.tf
/gloadmod gm-magical.tf
/gloadmod gm-tgtcast.tf
/gloadmod gm-pplacer.tf
/gloadmod gm-spellnames.tf
/gloadmod gm-tf5.tf

;; Load additional modules now
/gloadmod gm-rais.tf
/gloadmod gm-tarma.tf
/gloadmod gm-nun.tf


;; Load previously saved settings after all modules are initialized
/gload


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Load keyboard support files
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Bind some keys
/gloadmod kbd-xterm.tf
/gloadmod kbd-tf5def.tf

;; Some personal keybinds here ...
;/def -i -b'^[Om' = @smode
;/def -i -b'^[Ok' = @cmode


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Re-start logging (examples below, uncomment one)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Log to tiny.log in CWD (current working directory)
; /log on

;; Log to tiny.log in user's home directory
; /eval /log %{HOME}/tiny.log

;; Log to tiny-YYYY-MM-DD.log in user's home directory
; /eval /log %{HOME}/tiny-$[ftime("%Y-%m-%d")].log

#!/bin/sh
SAVE_LANG="$LANG"
export LANG="en_US.ISO-8859-1"
printf '\33]701;%s\007' $LANG

/usr/bin/tf5 $*

export LANG="$SAVE_LANG"
printf '\33]701;%s\007' $LANG

Next, log on in BatMUD and change following settings. It is probably best, if you use direct copy & paste to set these, as most of them are required to be set exactly as shown here for GgrTF to work correctly.

In case you do NOT want to change your settings to the way GgrTF needs them to be, your only option is to change the regex patterns in GgrTF's code to match your preferences (and redo the changes each time you upgrade GgrTF.)

This is the main module and core of GgrTF. It contains helper macro functions used by all the other modules and is thus always required to be loaded. It also provides much of the basic functionality, such as:

Probably one of the first things that you notice in GgrTF is the statusline (or "statusbar" as some prefer). In GgrTF the TinyFugue statusline is used to display information that we've considered to be important enough for nearly real-time view.

The basic one-row statusline of GgrTF is meant for compatibility, TF5 support module provides another version, enhanced to take advantage of newer TF5 beta features (TF 5.0 beta 7 or later required).

Statusline is updated synchronously at ticks, skill- and spell castings and certain other events. This depends on your BatMUD settings being correctly set up. If HP/SP/EP etc. information does not appear, most likely your 'sc' setting is "wrong", and thus does not get parsed by GgrTF.

Example of typical basic GgrTF statusline.

First three elements of the statusbar describe your character's current hit-, spell- and endurance-points. These values are color-coded for better visual clarity. One element shows current value and maximum value, as shown in screenshot below:

Example of how endurance points are shown. "E:" denotes Endurance, "134" is the current value (colorcoded) and "246" is the maximum endurance your character has.

In addition to basic prompt handling, GgrTF offers very flexible and extensible way of presenting the game prompt. Internal TF variables can be shown, even simple TF macro snippets executed to show the prompt as the user wishes. Also, in GgrTF v0.6.11.3 and later, it is possible to have custom BatMUD data in the prompt (see 'help prompt' in BatMUD).

To get started, you need to have a basic prompt setting in BatMUD, as it is required to have GgrTF handle it properly. The basic setting is presented below, and we'll get to the more complex ones later. prompt PROMPT:> After setting the BatMUD prompt, you can start configuring how GgrTF "mangles" your prompt. This is done by using "/gprompt" command macro (or alternatively editing the saved configuration files and "set_gprompt" setting.) There are myriad of ways of how and what things can be done, mostly limited by your imagination. Some examples are presented below:

As you can see, lots of things can be done, and only fraction of ideas are represented here. However, in addition to what GgrTF and TF offer, it is also possible to add BatMUD specific information into the prompt. As you remember, we set up the basic prompt above to "PROMPT:>". The user definable data can be put between the colon (":") and greater than (">") sign, and it gets parsed by GgrTF. Observe following example: prompt PROMPT:<hp>/<sp>/<ep>|<eqset>> Above prompt setting would make the BatMUD prompt show something like: PROMPT:663/636/333|spr> Where the numbers represent your hp, sp and ep, and 'spr' is the work eqset, as described by 'help prompt'. This string gets parsed into a TF variable called "status_prompt", which can be then used in GgrTF's prompt. Examples follow:

The prompt can contain any BatMUD data, as long as it is formatted as "PROMPT:your data here>".

State-saving is an awfully awkward name for GgrTF's functionality for saving your settings and other interesting data for later retrieval. Settings get saved and thus restored later, but this functionality is not automatic by default, you have to set it up so if you wish - GgrTF only provides you the functions for loading and saving, making it to happen automagically is up to you. How to do this is discussed further below.

;; Set directory path where savefiles will be stored
/eval /set set_datapath=%{HOME}/.ggrtf/

;; Set prefix string for savefile names
/eval /set set_saveprefix=bat-

;; Load the special pre-init module which loads pre-init
;; settings from the savefiles. This needs to be done
;; before loading any other GgrTF modules.
/gloadmod ggrtf-pre.tf

;; Load GgrTF core module
/gloadmod ggrtf.tf

;; Load other additional modules
/gloadmod gm-magical.tf
; etc etc.

;; Load and restore other previously saved settings.
;; This should be done after loading any GgrTF modules.
/gload

GgrTF's core provides few macros for defining "bindings", which are a way to create commands that look like normal MUD commands but are actually intercepted by TinyFugue and executed appropriately. These bindings can be used to easily define shorthands for casting spells, using skills, executing macros, etc. GgrTF bindings offer an easy way to define skill/spell commands with automatic party reporting (or without it). Simply put, bindings are similar to BatMUD "command" aliases, but client-side and with extra abilities (but also with some limitations.)

In GgrTF, there are optional pre-defined bindings, which can be enabled at your consideration. These pre-defined bindings are defined in the relevant modules, and can be enabled at load-time with a setting ("opt_bindings"). See below section for enabling bindings.

Now, you might be asking why would anyone need bindings? Indeed, you can already use BatMUD's command aliases for such things, but the number of command aliases in BatMUD is limited and if you run out of space, you have to remove some less used ones. Sometimes you have to redefine lots just because you are reincarnating... and you can not execute macros with command aliases.

There are many benefits to using bindings, but they do have some drawbacks:

/prdefgbind -s"cere"    -c"/ceremony" -n
/prdefcbind -s"nf"      -c"Neutralize Field" -n
/prdefsbind -s"fire"    -c"Fire Building" -n

,----------------.
| GgrTF Bindings |
+----------------+----------------------------------------------------.
| pprots         | G | /pprots                                  |   ? |
| rpouch         | G | /rpouch                                  |   ? |
| ad             | C | Aura Detection                           | Yes |
| invis          | C | Invisibility                             | Yes |
| float          | C | Floating                                 | Yes |
| ww             | C | Water Walking                            | Yes |
| seeinvis       | C | See Invisible                            | Yes |
| seemagic       | C | See Magic                                | Yes |
| cere           | G | /ceremony                                |   ? |
| curses         | G | /curses                                  |   ? |
| prots          | G | /prots                                   |   ? |
`---------------------------------------------------------------------'

GgrTF provides a mechanism for routing keyboard numpad bindings so that different functionality can be swapped in as needed. Core module offers three modes: walk (normal walking around); peer (walking around with automatic peering to adjacent directions, useful for merchants; ship (control ship movement). Certain other modules provide additional modes (see targetted cast module, utilized by tarmalen and mage modules, for example.)

One very important aspect of any script is the prot management. GgrTF contains a flexible and easy to extend prot management system, which supports basic, stacking and renewable prots. Special cases are also supported, like unstun and conjurer typeprots.

For actually displaying the active prots information, GgrTF offers various methods. The statusline shows the currently active prots in short form (without duration times). Macro command "/prots" can be invoked to locally echo the active prots in long form. Finally, a special BatMUD emote, 'tweak', can be used to trigger reporting of active prots to party report-channel (the 'tweak' emote was chosen for this purpose due to it being the de-facto standard for prot reporting triggers.)

Classes of prots supported by GgrTF are roughly the following:

The string describing active prots consists of entries with abbreviated name of the prot, current duration (from casting), possible number of stackings and optional stickiness-indicator for sticky conjuprots. The entries are separated with vertical line character (sometimes called the pipe). Some examples of prot entries with explanations are shown in table below.

Simple example session featuring some protting action in GgrTF:

tweak jeskko

You tweak Jeskko's nose mischievously.
Jeskko [report]: Unst[1h1m13s]

unp jeskko

Ggr [report]: Unpain -> jeskko
GgrTF:  ---- SPELL START ----  (393)
GgrTF: 'unpain' -> jeskko
Unpain: ##### [5]
You skillfully cast the spell with greater haste.
Unpain: ## [2]
Unpain: # [1]
GgrTF:  ---- SPELL DONE ----  in [3] rounds! [0m9s]
You utter the magic words (unpain)
You cast the spell successfully.
H:506/506 [] S:805/941 [-136] E:246/246 [] $:6499 [] exp:68202 []
Jeskko [report]: Unpain ON!

tweak jeskko

You tweak Jeskko's nose mischievously.
Jeskko [report]: Unst[1h4m25s] | Unp[2m35s]

Often an important aspect while bashing those nasty eq-monsters dead, is to keep track of any handicapping spells or skills cast against the said monster. GgrTF's curse handling is made just for that, it tracks most common handicaps cast at non-partymembers.

Notice! To work fully, this feature requires PSS-mangler module to be loaded and in use. While curse tracking does work without it, curses cast by other entities than party members will be counted also, which can be counterproductive.

Since version 0.6.14, GgrTF provides an experimental feature for predicting heartbeat duration and ticks. This can be useful if you wish to time your regen breaks nicely, or when to enter combat again (heartbeat factors in with the so-called initial battle round, or so called "zero round").

The usage of this feature is simple: There is one new field displayed on the statusline, the value labeled as "T" shows number of heartbeats from last tick, next tick usually occurs at 9 or 10. It should always be 10, but due to how we "force" simulated HBs and interaction with fast metabolism, they will not always match the real ones. First tick after leaving battle will not usually be predicted correctly, but the situation should normalize after it.

Base module for all things magical. This module is required for supporting spells/casting. It is not necessary for being the receiving end of prots or such. Several modules are dependant on this module, most importantly those guild-specific modules that use magic.

Even in the case your guild does not use magic spells (nomad guilds), having this module loaded is not harmful, so you can keep it in your configuration at all times.

This module provides support for filtering the output of pss (party status short) -command. It captures the status and prettyprints it out as a 3x3 table (as 9-man party formation) with player names and their status information in compact format.

The HP/SP/EP values are coloured in accordance to what percentage the player currently has of his maximum. Additionally varying colouring of player's name is used to indicate possible states of rest, unconsciousness, stun, formation, etc..

There is also an number indicator for number of rescuers when in stunned or unconscious state, but this is normally hidden. It appears on the left side of player's name, when available.

This module hooks to GgrTF's autopss-functionality (toggleable with /autopss option). A normally issued 'pss' command does not trigger the mangling functionality, but you can use /pss macro or bind that to 'pss'. (See Bindings-section for more information.)

Typical output of PSS-mangler in a party with first row filled. Toivo and Jeskko are near their maximum hp/sp/ep, but Ggr has taken some damage (yellow HP) and is almost out of endurance points (red EP).

In this screenshot example, Jeskko has become stunned (his name is coloured in bright red). Also, Jeskko has lost some hitpoints (dark green HP) and has only moderate amount of endurance left (light yellow EP). (No Jeskkos were actually harmed in producing this simulated situation.)

This screenshot shows how Toivo has taken some serious damage from a blast to the backrow, and has become unconscious. White on bright red background is used to highlight a unconscious player's name, hopefully catching your attention.

This module provides functionality for saving and restoring party formation (placement of members). Two simple to use macros can be issued to save the current formation and restore it as needed. Current flower BatMUD provides an in-game implementation via 'party store' and 'party restore' commands, which may be preferable over this module for some people.

However, the functionality of this module is somewhat better than the stock BatMUD commands, and will work under certain situations when the 'party restore' command does not, for example when some party members are missing from the room.

NOTICE! This module requires PSS-mangler module to be loaded!

Module for showing prots (and similar effects) affecting your party members. Tracking these effects can be done in two separate ways: 1) Old way (compatible with HCBat also) is keeping account of different prot up/down messages on the party and report channels. 2) New way is via 'show effects' command available in the normal BatMUD. The 'show effects' method is recommended, because of generally better accuracy. It should also be noted that there is a difference in the output between these two methods. "Manually" tracked prots show elapsed time of the effect, but with 'show effects' mode, the remaining time is shown.

.------------+-----+-----+-----+-----+-----+-----+-----+-----+
|            | Flex|WarEs|EMelo|  AoA|MFire|  AoH|  Uns|  Unp|
+------------+-----+-----+-----+-----+-----+-----+-----+-----+
|Blayke      | 0:07| 1:25| 0:49| 1:55| 1:43| 2:03|     |     |
|Yar         |     | 1:25|     | 1:40| 0:07|     |21:34|     |
|Kheldor     |     | 1:24| 0:48| 1:12| 0:41| 2:17|24:40|     |
|Alorn       |     | 1:25| 0:49|     |     |     |     | 6:49|
|Acentaja    |     | 1:25| 0:49|     |     | 1:31|     |     |
|Malcom      |     | 1:25| 0:49|     |     | 1:10|     |     |
|Jrj         |     |     |     |     |     | 6:22|     |     |
|Daria       |     |     |     |     |     |     |     |     |
|Ggr         |     | 1:25| 0:49|     |     |20:13|     |     |
`------------+-----+-----+-----+-----+-----+-----+-----+-----+

NOTICE! This module requires PSS-mangler module to be loaded! Also remember to issue at least one "/pss" command after the party is formed, to make the party members known to PSS-mangler and prot tracker.

This module adds in translating of spellwords to actual spell names. It is very much based on original work of Cutter and Dazzt, well known highbie BatMUD players. Their code is used and re-licensed under GPL with permission.

The translator works by printing the spell name in parentheses on the line where the spellwords are. The translated name can optionally replace the spellwords or it can be printed after them.

The spell name can be, if enabled, optionally printed in special colour formatting, which is based on the general class/type of the spell. This visual hinting can help you to notice if dangerous or otherwise interesting spells are cast.

Uncolorized examples of spellwords translator's output:

You utter the magic words (unstun)

You utter the magic words 'Paxus' (unstun)

Acolyte waves his index finger while uttering (flame arrow)

Murrough throws a pinch of magic dust in air and chants (lightning storm)

Due to the age of Hard Core BatMUD's current codebase and conceptual differences, several exceptions and workarounds are needed to improve GgrTF's compatibility with the HCBat environment. This module tries to provide the glue to make it happen.

Purpose of this module is dissimilar to others, as it is meant to contain almost everything related to peculiarities and differences of HCBat. We do not have separate guild-specific modules for HCBat, the code needed to catch the differences is either in this module or in some special cases in the guild-specific modules.

At the moment this module is rather simple, only replacing GgrTF's output macros to work around the lack of 'party report' -channel in HCBat. In future more functionality may be added, feel free to report bugs/incompatibilities to us.

This is a special enhancement module for those who use GgrTF with TinyFugue version 5.0 (beta 7 and LATER). Although GgrTF should work with TF5 without this module, you may wish to take benefit of the enhanced features designed for TF5 this module provides.

Example of typical basic GgrTF statusline in TF5.

This module contains utility functionality for everyone who casts different types of dead raising spells, including "raise dead", "resurrect", "new body", "reincarnation", etc.

Automatic list is kept of people who have accepted some such service from you, along with information what spell was requested. List can be viewed, and you can launch a cast at the latest accept or by specifying a player's name, cast his/her request.

You can either directly use the macros or use command bindings to have shorthand commands instead.

An example output of "/aclist" macro, listing the players who have accepted services from you and respective requested spells for each. The time field shows how much time has passed from the accept.

Provides triggers for automatic gathering of melee hit statistics. This functionality is not without limitations, in some cases hits may become erraneously counted (such as Templar guild 'holy strike' skill being counted as bludgeon strike) but it gives you a general impression about what kinds of hits you mostly deal out.

Only certain weapon/hit types are currently supported by the code. In order to get any hit counts, you need to define what weapon types you use. Currently following general hit/weapon classes are supported:

Example of /hstats output:

,----------------------.
| GgrTF Hit Statistics |
+-----------------------------------------------.
+-| Axes/Long blades     |----------------------|
|horribly shred      :        (  0):     2 ( 11)|
|shred               :        (  0):     7 ( 41)|
|incise              :        (  0):     8 ( 47)|
|tear                :     21 (  3):       (  0)|
|cut                 :    462 ( 72):       (  0)|
|lightly cut         :    157 ( 24):       (  0)|
|                                               |
+-----------------------------------------------'
+-| Totals |-------------------------------------------+
| Hits..: 640        ( 76%) | Crits: 17         (  2%) |
| Misses: 192        ( 23%) | Total hit types: 6       |
+----------------------------------------------+-------'
| Dodges..: 3          | Parries..:            |
| Tumbles.:            | Stuns....:            |
| Ripostes:            | Stun mano:            |
`----------------------------------------------'

Format of hits described above is: | Hit name : number of hits of this type (percentage): number of crits of this type (percentage) |

Provides a simpler and more readable view of 'identify' spell's output. Not all information can be caught gracefully, however, and thus you should refer to the raw output for details such as "tales" and other special information.

The module also supports merchant belt's 'weigh' command for catching the item's weight, if the belt is worn and /havebelt setting of the merchant module is enabled.

Example of output:

+-| General |----------------------------------------------------------------+
| Item....: a pair of stylish blue breeches                                  |
| Name....: blue breeches                                                    |
| Handles.: 'breeches', 'stylish blue breeches', 'silk breeches' and         |
|           'pants'                                                          |
| Names...: Molotov, Belse and Ekkivekki                                     |
| Slots...: leg and leg                                                      |
| Material: silk                                                             |
+----------------------------------------------------------------------------+
| In game.: 2y, 104d, 16h, 13min and 58s   | Condition: great                |
| Size....: somewhat small                 | Maxcond..: AWESOME              |
| Worth...: 8851                           | Quality..: superb               |
| Weight..: almost weightless              | Weight/kg: 0.050                |
+-| Stats |------------------------------------------------------------------+
| insignificantly improve your wis                                           |
+-| Misc |-------------------------------------------------------------------+
| Worn....: Ekkivekki for 48d, 17h, 13min and 9s, Prince charming for 2h,    |
|           5min and 44s and Slobber for 157d, 14h, 48min and 52s            |
| Wielded.:                                                                  |
+----------------------------------------------------------------------------+

This module provides utilities for reagent pouch handling, especially useful for mages and merchants. It also has a reagent pouch mangler/beautifier, which attempts to make the pouch contents more readable.

Example output (uncoloured) of looking at a reagent pouch:

This is a large pouch for the storing of reagents for spells. You can store
reagents over reboots in this. It cannot hold anything else.
Syntax: store <item> in <this>
        extract [amount] <item> from <this> take <power/standard/poor>
        set_default_reagent <this> to <power/standard/poor>
transfer <number> <reagent> from <here> to <there> [take <power level>]
Some commands allow the use of 'all' in places.
It is labeled as 'pussi'.
The label can be set with 'label' command.
  578 | Acid Blast                ( 578,   0,   0) (Olivine powder)
  477 | Acid Storm                ( 477,   0,   0) (Interlocked rings)
  436 | Blast Vacuum              ( 436,   0,   0) (Bronze marble)
  417 | Lightning Shield          ( 417,   0,   0) (Iron rod)
  397 | Armour of Aether          ( 397,   0,   0) (Highsteel disc)
  388 | Magic Eruption            ( 388,   0,   0) (Platinum hammer)
  341 | Lava Blast                ( 341,   0,   0) (Granite sphere)
  272 | Electrocution             ( 272,   0,   0) (Electrum wire)
  263 | Aura of Wind              ( 263,   0,   0) (Leather bag)
   91 | Golden Arrow              (  91,   0,   0) (Copper rod)
   71 | Shield of Detoxification  (  71,   0,   0) (Amethyst crystal)
It is surrounded by a yellow glow.
This item is in superb condition.
It looks very very heavy.

Game-elements specific to channellers guild are supported and enhanced by this module. At the moment, no special commands are provided, all things are automagic. This module requires the generic magical guilds support module.

Provides command bindings for all mage blast types (singles and areas) and optional key bindings for blasting and conjurer prot casting.

This module provides, in addition to basic skill/spell fail/fumble handling, several helper macros, which may ease your work as merchant. Many of the command macros support "autotargetting", which basically means that you can walk in outerworld and just type "/lj" for lumberjacking and "/mine" for mining and GgrTF usually knows what to do. Some macros require bit more specific arguments.

There is also support for merchant belt, which can be enabled if you have one available. In case your belt is not complete or is totally non-existent, the system has semi-automatic tool wielding functionality: if you use /lj and then /mine, the macros will automagically change to proper tools (saw -> hammer/pick). The system is not perfect and sometimes it may fail, however.

Hint: Another useful module for merchants is the reagent pouch handler. It provides several useful functions for handling reagents.

Notice that you probably MUST redefine some of these macros and default settings in your TF configuration file! (See Settings-section below.)

Alchemist module provides several macros that can be very helpful with potion making and other alchemist activities. Commands for easier handling of herb jars and organ cans, command macro that automates potion mixing to great degree and additional helper for potion research.

Potion research is a big part of alchemist guild activities, but also one of the more tedious ones. It requires juggling with organs, herbs and minerals, keeping book of findings, etc. GgrTF alchemist module will come to help, as it automates getting the herb and organ from your containers, submitting the finished potion concoction flask to authenticator and stores results in a text file.

Furthermore, the said text file is written in a specific format, that can be used with an external utility called AlchTool, developed by Jeskko and yours truly (Ggr). This PHP-based web utility can greatly increase your potion research efficiency. Currently (as of March 2011) AlchTool is in "beta"-phase of version 2, but the code can be retrieved from Pupunen Mercurial repository at https://tnsp.org/hg/batmud/alchtool/.

Default location of the results text file is user's home directory, in file called alch_results.txt, but this can be changed by altering galch_file TF variable, for example: /eval /set galch_file=%{HOME}/someotherfile.txt You should put this, if you wish to, in your tfrc file AFTER the loading of alchemist module.

Provides a translator for barbarian reputation bar, reputation difference calculator and handler for automated looting and burning.

Provides very basic management help for spider demons, plus lites for spider servants.

Reporting of succesful and failed 'tiger claw' hits, lites for claw and mak reputation gains.

Provides command bindings for most common tarmalen spells. Triggers for tracking latest heal alls cast (of course, only those that have 'hit' you are counted.) Optional keybindings for heals, party heals, etc.

Barebones module with default bindings for some druid spells and support for fails/fumbles. You will probably also want to use the raise module, which provides help for casting reincarnations (along with raises, resurrects, etc.)

Includes several useful functions for nuns, such as relic identification messages translator, useful command macros, prayer hour reminder (acts as a "prot"), simple task status keeper, counter+lite for accomplished tasks, turn message translator, etc.

Very barebones module with support for "blood" ripaction and fail/fumble handling.