Copyright © 2006-2009 Matti Hämäläinen (Ggr Pupunen)
This document is distributed under Creative Commons Attribution-ShareAlike 2.5 license, of which full version can be found from Creative Commons website.
THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.
BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS.
2009
Table of Contents
List of Tables
Table of Contents
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 and tested simultaneously on versions 4 and 5 of TinyFugue MUD client under Linux and Solaris platforms. There are some features that are only available to users of TinyFugue 5, though. Users of GgrTF are mostly users of UNIX-like systems, but there are several who run TF under Microsoft Windows operating system.
The current version (as of v0.6.9.x 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, spell- and skill-handling, way to easily run commands on each battle round (and more), pss-output mangling, spellwords to names translator and more.
It is impossible to tell, really. 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.
It must be admitted that GgrTF is somewhat programmer-oriented, at least in the sense that if you want something that is not already there, it probably is your own responsibility to create it.
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.
Some other scripts may offer more in the automation and pre-made hook department, GgrTF's aims are different, however. For example, one reason for this user's manual was created, was to help you to understand basics of GgrTF and give a head start in customizing it to suit your personal preferences.
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.
Pros:
Good general quality of code. As somebody put it, "you do not instantly get a headache from just looking at the code."
Modularity, easily extendable for most part.
Updated regularly, most bugs get fixed in upstream.
User-level documentation exists.
Cons:
Only small number of BatMUD's guilds are specifically supported.
Requires bit more programming knowledge than some other solutions.
Due to nature of the developer's reincs, is biased towards caster-type functionality than tanks. Thus the support for tank guilds is not very good, although some guilds are supported.
About three years ago, 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. Or at least I felt so back then.
At some point, however, my playing style advanced and need for automating some things became apparent. I googled for some available scripts, but most of the available ones 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 between small inner 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, people started noticing GgrTF. I believe some even started using it, or at least took and used parts of it. v0.4.x was somewhat short-lived, soon major restructuring was made into 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 beginning of 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.
Currently, it seems likely that v0.6.3 will be recorded as the last release of 0.6-series, while development towards v0.7.0 is slowly, but surely underway.
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.
Table of Contents
This chapter assumes that you have already succesfully installed TinyFugue in your system and you know how to use it (basic commands, loading of macros, etc.) It is also assumed that you know how to use your operating system of choice, be it some flavour of UNIX or Windows, although some parts of the instructions are given in step-by-step manner.
Throughout this manual, when GgrTF files are referenced in configuration examples etc., I have used "ggrtf/" -directory as path where the script files are located. You may need to substitute it with whatever you have installed your copy of GgrTF in.
There are basically two ways how to get GgrTF, release packages and the Subversion-repository. Releases are considered as stable snapshots, which should be relatively bug-free, but releases are done somewhat infrequently and at least in this phase we don't backport bugfixes to release versions.
If you are unsure which version to choose, use the latest packaged release.
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):
*.tar.gz packages are for UNIX-style systems, such as Linux, *BSD, etc. Please note that the ZIP-packages are meant for Windows only and WILL NOT WORK under UNIX or OS X version of TinyFugue!
*.zip packages are for Windows version of TinyFugue (the files have been converted to CRLF line endings.)
Both package types also have equivalent PGP/GnuPG signature files (*.asc), which can be used to cryptographically verify the authenticity of files.
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 "pushed" (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 new 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 Subversion (SVN) for GgrTF's version management. Subversion is a freely available Open Source version control system, for which there are clients available for most common platforms, including Windows, Linux and other flavours of UNIX.
GgrTF's Subversion repository is graciously hosted by Jarkko Vääräniemi (Jeskko) at Pupunen.net, and is available from following location:
Trunk-repository, all the latest stuff goes here:
You can browse the repository more easily via Pupunen.net's ViewCVS interface:
You can download ("checkout") the GgrTF repository with command line Subversion client with following command:
svn co http://svn.pupunen.net/public/ggrtf/trunk/ ggrtf
In which "co" stands for "checkout", after which comes URL of the repository and finally path to directory ("ggrtf") which the files will be checked out into.
You will most probably want to download the repository to some specific place, personally I prefer to use $HOME/ggrtf/ (aka "ggrtf/" subdirectory under user's homedir) under UNIX.
After you have checked out your own copy of GgrTF's code repository, you usually wish to periodically update it. This is done easily with Subversion's "update" command. First go to the repository directory and then issue "svn update" or the shorthand "svn up", as follows:
cd ggrtf svn up
If you have made changes to the files, Subversion tries to merge them with changes that have occured in the main repository. Sometimes the changes may be interfering with each other and this causes a merging error. You must fix these problems by hand, please refer to Subversion documentation for more information and tips.
After getting GgrTF and installing/copying the files to appropriate directory folder, you need to setup your configuration for TinyFugue and possibly change some of your settings in BatMUD.
If you are upgrading GgrTF from a previous version, it is probable that you do not have to change your configuration. But in case of odd problems you may wish to skim through this section, the ChangeLog and module-specific sections of this manual in case of any significant, backwards incompatible changes.
First, we have to set up TF's configuration. Location of the file containing the startup script for TF depends on your operating system environment.
UNIX- and compatibles and CygWin-based Win32 ports: ~/.tfrc (File named ".tfrc" in your user's home directory)
Next, log on in BatMUD and change following settings:
Line 'cutter' setting:
cutter 9999
Theoretically, 'cutter off' should be better, but in practice I have noticed that in certain things it simply does not work as expected.
Short score format for regular BatMUD:
sc set H:{colorhp}/<maxhp> [{diffhp}] S:{colorsp}/<maxsp> [{diffsp}] E:{colorep}/<maxep> [{diffep}] $:<cash> [{diffcash}] exp:<exp> [{diffexp}]
Short score format for HardCore BatMUD (HCBat):
sc set H:{colorhp}/<maxhp> S:{colorsp}/<maxsp> E:{colorep}/<maxep> $:<cash> exp:<exp>
Prompt:
prompt H:<hp>/<maxhp> S:<sp>/<maxsp> E:<ep>/<maxep> >
Listen to battle round flags:
battle rounds
This setting is a toggle, make sure that you set it ON ("Listening to round flags.") instead of off!
Battle listen-level:
battle listen all 2
Listen level should be 2 or 3, if you are using hitstats. Otherwise it can be 1 or 0, if you prefer silence.
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 regular expression patterns in GgrTF's code to match your preferences (and possibly redo the changes when/if you upgrade GgrTF.)
Table of Contents
This chapter describes the structure of GgrTF, what the different modules included in GgrTF are and what functionality they provide. There are basically three flavours of modules: generic modules that are either required or optional and provide functionality unrelated to specific guilds; then there are guild-related modules, containing guild-specialties.
Each module section has short introduction about what is provided and section with macro commands and variables available. Some modules also have additional information about usage and configuration with examples.
Following block-diagram represents the structure of GgrTF and how different components approximately relate to each other:
Internal structure and relations of GgrTF components represented as block-diagram.
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:
Statusline. Provides nice, realtimeish view of your character's current condition, applied prots and other such information.
Prot management. Keeps note of what prots have been cast at you, and provides this information in various ways.
Battle round handling. Enables commands to be executed each battle round and autopss functionality.
Functions for binding command strings to macros, or to cast spells and use skills, with or without reporting to party channel. See bindings section for more information.
Support for state-saving. Most GgrTF settings can be saved to files and reloaded later (for example at startup) with /gsave and /gload commands.
Prompt gagging. Optional skill/spell viewing in prompt, which shows the currently ongoing skill or spell in your prompt.
Spell round reporting. Enables you to optionally spam your fellow players with information how many rounds are left until your spell goes off.
Automatic "ripaction", which is performed when your opponent (monster) dies. This way you can automate small inconveniencies like looting and digging of graves.
Keyboard movement handling and mapping. Bind your numpad keys to move around, either by walking, walking with peering in adjacent rooms (useful for merchants) or guiding your ship. Additional modes may be provided by other optional modules.
Enemy shape string highlighting and reformatting. You can make GgrTF mangle 'scan' command's output into more readable and convenient form.
Keep and display statistics about skills, spells and whatnots. ("/stats" command)
<> = required argument, [] = optional argument
Each of these commands will print current setting/value and usage information if executed without arguments (or in some cases, with incorrect arguments).
Table 3.1. Macro commands
Command | Description |
---|---|
/opts | Lists all the run-time changeable settings of GgrTF, with short descriptions and current values. |
/stats | Display miscellaneous statistics about skills, spells, etc. |
/move <type> | Change the meaning of keyboard movement hooks. |
/ripaction <action> | Set the action performed at opponent RIP. Possible additional settings may be provided by other loaded modules. Functions provided by base GgrTF are: off (no special action performed), dig (dig grave for corpse), eat (get and eat corpse), get (get corpse) and cmd (execute mud command(s) specified with /ripcommand setting, see /ripcommand) |
/ripcommand <commands> | Sets the MUD command(s) to be executed if /ripaction is set to "cmd". This string is sent to the MUD at opponent R.I.P, if /ripaction is "cmd". |
/round <commands> | Sets the BatMUD command(s) to be executed on each battle round. The string of commands is sent to the MUD when battle round flag is received. |
/locaction <action> | Sets action taken after a Lord of Chaos performs "blood corpse". This is useful for automating corpse handling, if you are a LoC yourself, or are partying with one. |
/lichaction <action> | Sets action taken after a Lich performs "soul sucking". |
/prots | Show any currently active prots on you. The output is only echoed locally, use BatMUD 'tweak me' emote to list prots to party report-channel. |
/cprots | This command clears all prots on you. It is meant for those cases where GgrTF is either bugging and does not notice a prot dropping, or any other reason when you need to remove all prots at your discretion. |
/shape | Reports the last catched shape of a opponent (monster) in battle. This does not work too well if you were fighting more than one opponents. |
/gver | Prints (or returns, if called as function) a short version string of GgrTF. |
/gversion | Prints (or returns, if called as function) a long version string of GgrTF with copyright- and TinyFugue version information. |
/autopss | Toggle autopss-functionality on/off. If enabled, /pss macro is executed on each battle round flag. By default, /pss is 'party short status', but some modules (like PSS-mangler) override this to provide additional functionality. |
/binds | List all currently defined GgrTF command bindings. Refer to bindings section for more information and example output. |
/gsave | Save all GgrTF settings. Refer to state saving section for more information. |
/gload | Load GgrTF settings. Refer to state saving section for more information. |
/greset | Reset all skill/spell counters and statistics. Notice that issuing this command also requires executing of "/gsave" if you want to save the zeroed statistics, otherwise the old saved statistics will be loaded on next /gload. |
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 TF4 compatibility, though it works with TF5 too. TF5 support module provides another version, enhanced to take advantage of TinyFugue 5's new features.
Statusline is updated synchronously at ticks, skill- and spell castings and certain other events.
Example of typical basic GgrTF statusline in TF4.
Current hit points / hit points maximum.
Current spell points / spell points maximum.
Current endurance points / endurance points maximum.
[2 light green characters] Last moved direction.
["C"] Ceremony status. (Dark blue = inactive/no ceremony; White = ceremony active)
["S"] Spell status. (Dark blue = no spell going; White = spellcasting)
["K"] Skill status. (Dark blue = no skill going; White = using a skill)
["c"] Camping status. (Light green = ready to camp; Red = camping active/skill ongoing; Yellow = camping not available, or recovering from previous camping.)
Currently active prots in short format.
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.
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 can be loaded, 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.)
Almost all settings (hidden or visible) get saved, but there are certain global settings that you have to set yourself in your TF configuration. These settings are discussed in sub-section below.
It should also be noted, that there are actually two different types of data (or variables) that is saved into two different files. In GgrTF, these two types of data are called pre- and post-init settings, and the two savefiles are named accordingly. Pre-init settings are variables that need to be defined before the main modules of GgrTF are loaded in TF's startup configuration (certain functionality depends on this). Post-init variables can (and sometimes must) be set after loading of all modules.
There are currently three special GgrTF variables, which you have to set yourself in your TF's startup configuration (".tfrc"-file). These variables MUST be set before loading of ANY GgrTF modules, otherwise things start breaking and the state-saving system does not work correctly.
Table 3.2. Variables
Variable | Description | Example |
---|---|---|
set_plrname | Your character's name, written in correct case. | /set set_plrname=Ggr |
set_datapath | Path to the directory where you want your savefiles to reside. If left empty, current working directory is used (the directory you started TF from.) | /set set_datapath= |
set_saveprefix | This string is used as prefix of the two savefiles, so the actual savefiles are "<prefix>pre.tf" and "<prefix>post.tf". This is useful, if you play regular BatMUD and HCBat, so you can use different values for either. | /set set_saveprefix=bat- |
Getting GgrTF's state-saving to work requires some changes to your TF configuration, namely the ".tfrc"-file. First of all, you need to set the special variables, so that the loading and initialization work correctly. Secondly, a special module ggrtf-pre.tf must be set to load before any other GgrTF components are to be loaded (this special module loads the pre-init settings). Third, after all GgrTF modules have been loaded, /gload macro must be issued so that previously saved settings will be restored.
A simplified example configuration layout is presented below, please refer to setup-section of this manual for a more detailed example. Pay close attention to the order how things are done, it is very important!
;; Set special variables before loading scripts ;; Player character name (notice the case, "Ggr" instead of "ggr" or "GGR") /set set_plrname=Ggr ;; Path of directory where savefiles will be stored, empty is CWD /eval /set set_datapath=%{HOME}/ggrtf/ /def -i gloadmod = /eval /load %{HOME}/ggrtf/%{*} ;; Prefix string for savefile names /set set_saveprefix=bat- ;; Load the special pre-init module /gloadmod ggrtf-pre.tf ;; Load GgrTF core /gloadmod ggrtf.tf ;; Load other additional modules /gloadmod ggrtf-misc.tf /gloadmod ggrtf-magical.tf /gloadmod ggrtf-rais.tf /gloadmod ggrtf-tarma.tf /gloadmod ggrtf-druid.tf /gloadmod ggrtf-pssmangle.tf /gloadmod ggrtf-pplacer.tf /gloadmod ggrtf-spellnames.tf /gloadmod ggrtf-tf5.tf ;; Perhaps load some key bindings /gloadmod kbd-xterm.tf ;; Restore previously saved settings /gload
When you have edited your TF configuration, you need to (re-)start it, change settings the way you want them to be and finally issue "/gsave" command to get settings saved. After saving, you may also want to examine the pre-init -savefile, because it contains certain settings that cannot be changed run-time . So, here are the steps in short again:
Edit TF configuration: Add required settings, "ggrtf-pre.tf"-module and /gload directive.
Re-start TF: In order to save initial settings, you need to (re-)start TF, so that the save-state system is enabled.
Change settings: Change GgrTF settings (listed via /opts etc.) to accommodate your desires.
Save initial settings: Issue "/gsave" to get settings saved.
Optionally edit pre-init settings: Certain settings are saved into the pre-init savefile (actual filename is dependant on what you set "set_saveprefix" to). GgrTF does not offer any special interface to change these settings, you have to edit this file by hand, if you wish to change the defaults.
In previous example, I only described how settings get restored (as TF loads and initializes GgrTF), but how to get settings saved automatically too?
The answer lies in TinyFugue's event hooks. It is possible to define a hook, which is executed when TF disconnects from a world. By setting this hook to perform "/gsave", we can automatize the process of saving settings. Add following line to your TF configuration:
/def -hDISCONNECT mydisconnect = /gsave
There is one gotcha: if you don't want to keep saving the statistical values, but only the settings, you may want to add a "/greset" in the soup:
/def -hDISCONNECT mydisconnect = /greset%;/gsave
<> = required argument, [] = optional argument
Table 3.3. Macro commands
Command | Description |
---|---|
/gsave | Save all GgrTF settings and other certain variables. |
/gload | Load GgrTF settings. |
/greset | Reset all skill/spell counters and statistics. Notice that issuing this command also requires executing of "/gsave" if you want to save the zeroed statistics, otherwise the currently saved statistics will be loaded on next /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).
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:
Limitations of TF's parsing: Because of the nature how bindings are defined and parsed, you can only use one binded command per line. For example, let's assume "aoa" is binding to cast Armour of Aether and "clair" is a binding to use clairvoyance. Thus, someone might want to command:
aoa ggr%;clair
Unfortunately, this does not work as might be expected. Because TF does not evaluate binding as an expression, the "ggr%;clair"-part is used as a literal argument to "aoa" binding. In effect the command would try to cast Armour of Aether at player "ggr%;clair".
BatMUD commands and GgrTF bindings cannot be mixed: Because the bindings are actually intercepted by TF before the line gets passed to BatMUD's parser, you can't combine multiple bindings or BatMUD commands on the line. For example, assuming "aoa" is again a binding and "hop" is an emote:
hop jeskko;aoa ggr
One might easily assume, that the result would be to first hop around player or thing named Jeskko, and then cast Armour of Aether at Ggr. Unfortunately the latter would just produce an error, as it would be instead passed to BatMUD's interpreter and not handled as a binding by TF!
Limitations of GgrTF's binding system: There are certain limitations what kind of bindings you can define with the current functionality provided by GgrTF. Bindings that require complex parameters (more than one optional argument), are not possible - you are better off using BatMUD's command aliases for those.
Now we know the limitations of this system - let's see how to define some basic command bindings!
/prdefgbind -s"cere" -c"/ceremony" -n /prdefcbind -s"nf" -c"Neutralize Field" -n /prdefsbind -s"fire" -c"Fire Building" -n
Above we have have listed all three (3) classes of binding defination macros supported by GgrTF. First defines a generic command binding to execute "/ceremony" macro when user commands "cere". Second binding defines a spell casting command to cast "Neutralize Field" when user commands "nf". And the third binding defines a skill usage command to use "Fire Building". So basically we have three types of bindings:
/prdefgbind: Defines a generic binding, in which the action ("-c" parameter) can be almost anything, like a TF macro, or BatMUD command.
/prdefcbind: Defines a casting binding, the action is the name of the spell to be casted.
/prdefsbind: Defines a skill usage binding, action argument being name of the skill to be executed.
Each of these defination macros require at least two arguments: the name for the binding command ("-s" option) and the action ("-c" option). There are other optional arguments, which affect aspects of the command binding to be defined. The argument options and their meanings are listed below:
Table 3.4. Arguments common to all binding defination macros
Option | Description |
---|---|
-s"name" | Specifies the name of the command binding. This is basically the string you type to use the command, after which come the optional arguments. |
-n | Tells GgrTF that the binding does NOT accept arguments. Anything following the command binding invocation is ignored. This also affects the possible reporting output of the binding. |
Table 3.5. Arguments specific to generic bindings (/prdefgbind)
Option | Description |
---|---|
-c"action" | Specifies the action, aka what the binding does. For generic bindings, the action is a literal, so it can be a TF macro or BatMUD command. |
Table 3.6. Arguments specific to spell casting and skill usage bindings (/prdefcbind and /prdefsbind)
Option | Description |
---|---|
-c"action" | Specifies name of the spell to be cast or skill to be used. |
-d"message" | This option overrides the default message string used for reporting (see also option "-q" below). |
-q | Makes the binding "quiet", suppresses any reporting. By default, spell casting binding reports the action on party report-channel, but specifying this option disables it. |
More examples, now with short explanations:
Table 3.7. Binding defination examples
Definition | Description |
---|---|
/prdefgbind -s"repu" -c"/showrep" -n | Generic binding, which executes /showrep macro and takes no arguments. |
/prdefsbind -s"er" -c"Enrage" -n | Skill binding for barbarian "Enrage" skill. Also takes no arguments. |
/prdefcbind -s"shelter" -c"Shelter" -n -d"Sheltering ..." | Spell casting binding, for casting conjurer spell "Shelter". Takes no arguments and uses specific reporting string (default would be "Shelter ...", but since it sounds bit stupid we want to use "Sheltering ..." instead.) |
/prdefcbind -s"dmp" -c"Dispel Magical Protection" | Another spell casting binding for a conjurer spell, which takes (and requires) a player's name as argument. |
/prdefcbind -s"sl" -c"Star Light" -q | Yet another spell casting bind, this time for druid spell "Star Light". Since this is a blasting spell, it is not really useful to report that we are casting it, so we suppress any reporting. Argument is accepted. |
As of now, you should be able to define bindings of your own. You can define them in your .tfrc or make another file for them.
A special variable called "opt_bindings" controls whether the various /prdef*bind macros will actually define any binding at all. If this variable is set to value "on", bindings will be defined, otherwise not.
This is also the way how pre-defined GgrTF bindings are made optional. By defining "opt_bindings" before loading GgrTF modules, user can choose to enable or disable the default bindings, even "per-module" by changing the value of opt_bindings before each module loading in tfrc.
It should be noted, that "opt_bindings" is a saveable setting, that gets stored by /gsave and restored by ggrtf-pre.tf Please refer to setup- and state saving- sections for more information.
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, useful for merchants; ship (control ship's movement). Certain other modules provide additional modes (see tarmalen module for example.)
<> = required argument, [] = optional argument
Table 3.8. Macro commands
Command | Description |
---|---|
/move [setting] | Set the mode used for numpad bindings. Valid values are shown if command is given without arguments. Core GgrTF module provides following three modes: move, peer and ship |
/peer [regexp] | Set the regular expression used for grepping the output of 'peer' command used in "/move peer" mode. |
/cruise | Toggle ship cruising speed on/off (off = sail) |
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:
Harmful effects/curses/handicaps
Basic utility prots (infravision, water walking, floating, invisibility, etc.)
Conjurer prots (minor- and major typeprots, stickyness)
Evil priest (protection from good, paranoia)
Tarmalen (unpain, blessing of tarmalen, lifelink, enhanced vitality)
Nun (protection from evil, soul shield, heavenly protection, mana shield)
Templar (shield of faith, blessing of faerwon)
Psionicist (levitation, force shield)
Druid (flex shield, earth power, earth skin, earth blood, vine mantle, regeneration)
etc...
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.
Table 3.9. Prot entries
Entry | Description |
---|---|
Unst[1m9s] | Unstun with duration of 1 minutes, 9 seconds. |
+AoA[7m19s] | Sticky Armour of Aether. |
Infra(2)[0m2s] | Infravision stacked at 2 levels. |
Unst<2>[7m19s] | Unstun that has been weakened 2 times. |
-Forget[3m5s] | 'Forget' curse that has been active for 3 minutes and 5 seconds. |
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]
<> = required argument, [] = optional argument
Table 3.10. Commands
Command | Description |
---|---|
/prots | Show any currently active prots on you. The output is only echoed locally, use BatMUD 'tweak me' emote to list prots to party report-channel. |
/cprots | This command clears all prots on you. It is meant for those cases where GgrTF is either bugging and does not notice a prot dropping, or any other reason when you need to remove all prots at your discretion. |
tweak <target> | BatMUD's 'tweak' emote is used to report prots either to party report-channel, or in case if the tweaker is not in same room, via emote. |
In the beginning of GgrTF's development, many features now residing in misc-module were originally part of the core system. But as the code grew, some features were deemed to be useful, but not to be part of the basic core functionality nor part of any guild-specific module either - thus the misc-module was created.
Consider-skill reporting: Takes output of 'consider' skill and compresses the information into one prettyprinted line, which is reported. Output is name of the target, estimated experience worth and final estimation of target's toughness.
Combat Damage Analysis reporting: Triggers for reporting results of CDA-skill to party report-channel.
Purse contents prettyprinting: Highlites and colorizes the output of 'look at purse', and calculates total sum of money (in gold) contained in the purse.
Camping status handling and reporting: Keeps note of whether you can use 'camping' skill. Reports the hp/sp/ep gained from resting.
Ceremony status: Tracks status of ceremony, and provides macro "/ceremony", which executes ceremony skill only if ceremony is not active currently.
Path compression for map.tf: TinyFugue distribution comes with map.tf, which enables easy creation of walkpaths (See "/help map" in TF). GgrTF adds an special purpose RLE compressor function, which reduces the length of the paths. Additional command to output the paths in format that is compatible with BatMUD's "command"-aliases is also provided.
Plus numerous miscellaneous reporting- and helper-triggers.
<> = required argument, [] = optional argument
Table 3.11. Commands
Command | Description |
---|---|
/rmisc | Toggle general reporting features of this module. This setting affects the level of spam produced by features of misc-module. |
use consider at <monster> | Whatever method you employ to use 'consider' skill, the output will be caught by consider-reporting trigger. |
/rcda | Toggle reporting of Combat Damage Analysis. If set 'off', CDA reports are only displayed locally to you, if set 'on', reporting is done to party report channel. |
/ceremony | Perform skill 'ceremony', but only if ceremony is not already "active". |
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 and formation.
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.
List of possible indicator colours and their meanings. Colours described here may deviate from what you actually see due to differences in terminal emulation programs.
Table 3.12.
Colour | Background | Explanation |
---|---|---|
Bright White | Bright Red | Negative value (x < 0) |
Bright Red | - | Less than 16% of max |
Red (dark) | - | Less than 33% of max |
Yellow (dark) | - | Less than 49% of max |
Bright Yellow | - | Less than 66% of max |
Green (dark) | - | Less than 85% of max |
Bright Green | - | More than 85% of max |
List of possible name colours and their meanings. Colours described here may deviate from what you actually see due to differences in terminal emulation programs.
Table 3.13.
Colour | Background | State description |
---|---|---|
Bright White | - | Normal |
Bright White | Bright Red | Unconscious (unc) |
Bright Red | - | Stunned (stun) |
Magenta | - | In form (form), member (mbr) or resting (rest) |
<> = required argument, [] = optional argument
Table 3.14. Macro commands
Command | Description |
---|---|
/prettypss | Toggle 'pss' output mangling/prettifying. If set off, normal plain 'pss' output is passed through unfiltered. |
/pss | Show party status. |
/autopss | Toggle automatic party status reporting. (Defined elsewhere) |
/fullparty | If enabled, mangled output always shows full 3x3 party formation, even if all rows aren't filled. When disabled, only the first used rows are shown. |
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.
NOTICE! This module requires PSS-mangler module to be loaded!
<> = required argument, [] = optional argument
Table 3.15. Macro commands
Command | Description |
---|---|
/ppsave | Save current party formation. Positions of party members in current formation are stored. |
/ppreset | Resets or restores the party formation to the one saved previously. Restoring occurs fully automatically. |
Module for 'tracking' prots casted in your party. Tracking is done by keeping account of different prot up/down messages on the party and report channels.
Please note, that due to the way the tracking works, it depends on your party members to use working, non-broken triggers which use up/down messages that are recognizable to the ptracker module!
.------------+-----+-----+-----+-----+-----+-----+-----+-----+ | | 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!
<> = required argument, [] = optional argument
Table 3.16. Macro commands
Command | Description |
---|---|
/pprots [command] | Shows currently tracked prots in the party. Optional macro or MUD command argument can be given, to feed the output through it. For example "/pprots emote" would use BatMUD emote to show the data people present in the same room. |
/cpprots | Clears ALL the currently trackred prots and all other related data. Using this may be useful if some prots erraneously "linger". |
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)
<> = required argument, [] = optional argument
Variables and user-replaceable macros definedby this module are described in a table below. They have specific defaults, which you can override in your configuration if you re-set/re-define them after loading the module. Please refer to Setup-section of this manual or see the example configuration for this module.
Table 3.17. Macro commands
Command | Description | Variable | Values |
---|---|---|---|
/spwords | Toggles showing of actual spell words on/off. | opt_spwords | on, off |
/spcolorize | Toggles colorization of spell name on/off. | opt_spcolorize | on, off |
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.
NOTICE! The code in this module uses features available on TF 5.0 beta 7 and later, it will NOT work correctly in older betas!
Example of typical basic GgrTF statusline in TF5.
Enhanced 2-row statusline: First line contains HP/SP/EP- and skill/spell/etc- information as usual. Prot status has been moved to the second line.
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.
<> = required argument, [] = optional argument
Table 3.18. Macro commands
Command | Default binding | Description |
---|---|---|
/aclist | acc | View list of people who have accepted something from you. |
/accast [name] | clast [name] | Cast Last-type functionality. Without arguments casts the LATEST requested spell. Optionally you can specify a name of the player and the spell requested by him/her is cast. |
/acclear | cclear | Clears the list. Useful, if the automatic removal malfunctions for some reason. (For example, if target uses 'pray' to become alive again, there is no message provided to the caster.) |
Provides triggers for automatic gathering of melee hit statistics. This functionality is not perfect, in some cases hits may be erraneously counted (such as Templar guild 'holy strike' skill being counted as bludgeon strike) but it gives you some impression about what kinds of hits you mostly deal out. Only some weapon types are currently supported.
.. TODO FIXME place a 'screenshot' here ..
NOTICE! Hit stats REQUIRES the TF terminal window width to be 95 columns or more! If you are using TF in smaller smaller window and can't make it wider, then you are out of luck.
<> = required argument, [] = optional argument
Table 3.19. Macro commands
Command | Description |
---|---|
/hstats | Print out hit statistics in a pretty table (see the warning above, though.) |
/weapon1 <type> and /weapon2 <type> | Set the weapon types you are using. Currently only two are supported. Notice, that if you are using several weapons of SAME type, you only need to set one (separate weapons of same type are counted as one.) Use plain "/weapon1" command to see supported types. |
/mhits <off|short|gag> | Change hit message mangling: off = no mangling, pass hit message through unaltered; short = use short messages, collecting ALL your hit messages into one line like "You jab, dodge, parry, CRUELLY TATTER."; gag = gag messages completely. |
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.
Channeller aura: Keeps note of your aura status and duration. If aura is up, it is notified in GgrTF's statusline. If your aura is weakening, that also is noted, reminding you to recharge.
Blast resistance reporting: Adds support for channeller blasts into blast resistance reporting feature of miscellaneous module.
And other miscellaneous lesser features, such as fail and fumble handling, mana transfer cap reporting, etc.
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.
Notice that you probably MUST redefine some of these macros and default settings in your TF configuration file! (See Settings-section below.)
<> = required argument, [] = optional argument, (*) = autotargets, (!) = moves items to item target
Table 3.20. Macro commands
Command | Description |
---|---|
/havebelt | Toggle support for merchant belt functionality on/off. |
/mdisc | Change item move target to your floating disc. |
/mbox | Change item move target to box (labeled as 'collect') |
/mdrop | Change item move target to drop item. |
/lj [target] | Use lumberjacking (at optional target, if no target given, autotargetting or previous specified target is used.) (*) (!) |
/mine [target] | Use mining (at optional target, if no target given, autotargetting or previous specified target is used.) (*) (!) |
/mr <material> | Make reagent from material. |
/gcut <material> | Use gem cutting at material. (!) |
/amal <material> | Amalgamate material. |
/refine <material> | Refine material. |
/mcut <material> [size] | Mineral cut material. Optional size can be give in grams. If no size is specified, material is cut in half. |
Table 3.21. Unfinished / buggy macros
Command | Description |
---|---|
/id <item> [target] | Cast 'identify' spell at specified item and optionally send output to target player. Example: /id ring jeskko |
/alloy <materials> | Alloy given materials. Example: /alloy illumium,nullium |
Variables and user-replaceable macros definedby this module are described in a table below. They have specific defaults, which you can override in your configuration if you re-set/re-define them after loading the module. Please refer to Setup-section of this manual or see the example configuration for this module.
Table 3.22.
Variable / macro name | Description |
---|---|
opt_havebelt | Enables merchant belt support. Valid values: on, off |
mtool_mine | Tool(s) for mining. Example: /set mtool_mine=pick 1,pick 2 |
mtool_lj | Tool(s) for lumberjacking. Example: /set mtool_lj=saw |
mtool_bs | Tool(s) for blacksmithing. |
mtool_cp | Tool(s) for carpentry. |
mtool_gc | Tool(s) for gem cutting. |
mtool_gb | Tool(s) for glassblowing. |
mtool_ma | Tool(s) for masonry. |
mtool_sw | Tool(s) for sewing. |
mtool_sc | Tool(s) for sculpture skill. |
mforge_* | Forges/workbenches for skills (similar to mtool_* variables) |
Provides a translator for barbarian reputation bar, reputation difference calculator and handler for automated looting and burning.
<> = required argument, [] = optional argument
Table 3.23. Macro commands
Binding | Macro | Description |
---|---|---|
repu | /showrep | Prints your current reputation and reputation difference from previous invoking of the command. |
lb | /lootburn | Starts looting and burning skill, lights a torch, waits for couple of seconds and drops corpses from inventory. After burning the torch is extinguished and current reputation printed out. Then action determined by "/burnaction"-setting (see below) is executed. If a skillbreak is detected, corpse dropping will be cancelled immediately. |
/burnaction <action> | Sets the action done after finished burning. Available options are: none, cash (drop small coins) and noeq (drop low coins and noeq). |
Provides very basic managing for spider demon, plus lites for spider servants.
Barebones module with default bindings for some druid spells and support for fails/fumbles.
Very barebones module with support for "blood" ripaction and fail/fumble handling.
<> = required argument, [] = optional argument
Table 3.25. Macro commands
Command | Description |
---|---|
/ripaction <action> | LoC module adds option "blood" to /ripaction, which automagically runs "lord_chaos blood corpse" on monster RIP. |
/locaction <action> | This setting is related to LoCs, but defined in main GgrTF module as also other than LoCs have use for this, if partying with a LoC. |
|
||
--The Matrix (parody of) |
Report bugs and feature-requests via our bugtracker. A checklist for reporting bugs:
Before reporting a problem, use the search and browsing functionality of our bugtracker to check if your issue is already reported.
Take your time to think while writing, and before submitting your report. Good rule of thumb is to include all information that you think might be relevant, but no more than that!
Remember to include information about your system and environment, (*NIX/Linux/Windows), version of TinyFugue ("/ver" command in TF), and of course the version of GgrTF ("/gver" command).
We do not provide support for usage, please refer to the user's manual and only in case the issue is not documented, you might be eligible to ask about it.
Neither we provide technical support for extending GgrTF, nor documentation of the internals. You'll have to figure out the workings yourself.
Be ready to be contacted by developers, in case help and/or more information is required with debugging your issue(s).
Remember not to bother the developers via tells too much, we want to play the game too, instead of just answering your questions and resolving problems.
B.1. |
Is "Grizzt" included in the documentation? |
Unfortunately no. Grizzt may be included in some future version, though. |
|
B.2. |
When will next version of GgrTF be released? |
"When it's done." |
|
B.3. |
How to get rid of the battle round flag/marker? |
The round marker (long line of asterisks "*") is required for GgrTF's internal functionality, but you can gag it with following piece of code (add it to your .tfrc or similar): /test prlist_insert("event_battle_round", "myroundgag") /def -i myroundgag = /substitute -ag The first line adds macro "myroundgag" to be executed on each round marker, the second line defines that macro and sets it to gag the round marker. |
|
B.4. |
My statusline is not updating, why? |
Maybe you haven't properly set up your 'short score' or 'prompt' in BatMUD. See setup-section for how to do that. |
|
B.5. |
How can I get my settings saved automatically? Or can I? |
Automatic saving and loading is possible, please refer to state-saving and setup -sections of this manual for more information. |
|
B.6. |
A spell/prot cast by others at me registers in prot-reporting, but does not work when I cast it on myself! |
This is most likely a bug, please report the issue on GgrTF's bugtracker. Remember to include the lines you get when you cast the spell on yourself (aka the "prot goes up"-line). Also see the next question below. |
|
B.7. |
Sometimes the spellword translator does not work, what gives? |
Your 'cutter'-setting might be too small, the default in BatMUD is 80, which adds hard linefeeds too early on a line, thus breaking many triggers of GgrTF, including GgrTF::Spellnames module. 'cutter 9999' or 'cutter off' should fix this problem. Please refer to BatMUD settings -section of this manual for correct in-game settings. |
|
B.8. |
The TF5 module does not work! I am using TF 5.0 beta 6 or older. |
The functionality used by the TF5 module was introduced in TF 5.0 beta 7, so you need to have that or a later version. |
If you wish, you may verify the tarball package signatures with GnuPG, in case you want to be sure that you are getting unmodified files directly from the upstream. To do that, use the following commands:
Retrieve Matti Hämäläinen's public key from a keyserver:
gpg --keyserver wwwkeys.pgp.net --recv-keys 0x1374C112
Verify the package signature (assuming you have downloaded both the file and signature):
gpg --verify ggrtf-0.6.9.x.tar.gz.asc
If the data is untampered, you should get a result like 'gpg: Good signature from "Matti Hamalainen (ccr) <ccr@tnsp.org>"'
Please refer to GnuPG or PGP documentation for more information about their usage. A great introduction to PKI, cryptography and public key signing, the GNU Privacy Handbook is available from GnuPG project. (Versions in other languages and formats, including PDF, are available from http://www.gnupg.org/documentation/guides.en.html.)