Hnefatafl
=========



Name
----
Hnefatafl - the Norse board game



Synopsis
--------
`hnefatafl [-ChiLsv] [-c <path>] [-d <path>] [-e <path>]
[-l <filename>] [-n <variable>] [-r <filename>] [-x <theme>]`



Description
-----------
> Played at draughts in the garth: right glad they were,  
> Nor aught lacked they of lustrous gold —  
> Till maidens three from the thurses came,  
> Awful in might from etin-home.
>
> ― Prophecy of the Seeress, ca. 400-1100 AD



Options
-------

`-c <path>`
:	RC file. Note that you have to give the full path.

`-C`
:	Suppresses reading of RC files, even if `-c` is specified and
	`$HNEFATAFL_RC` is defined.

`-d <path>`
:	Specifies the program's preferred path to data files.

`-e <path>`
:	Loads the saved game from the file indicated by the path
	argument. Note that you have to give the full path.

`-h`
:	Prints help about invocation parameters.

`-i`
:	Prints information about copyright and warranty.

`-l <filename>`
:	Language file. Note that you should only specify the filename,
	not the full path.

`-L`
:	Prints all language keys to `stdout`, one per line.

`-n <variable>`
:	Prints the value of an environment variable. If no variable is
	specified, then the values of all environment variables used by
	the program are printed.

`-r <filename>`
:	Ruleset file. Note that you should only specify the filename,
	not the full path.

`-s`
:	Suppresses `setlocale()`. This is practically equivalent to
	setting `$LC_ALL` to `"C"`.

`-v`
:	Prints version of all components. `uicx` means that the
	interface supports X; `uic` means that it doesn't support X.

`-x <theme>`
:	Starts the X interface instead of the CLI, and quits the program
	when the window closes (unless X can't be started at all, in
	which case the CLI runs instead). `<theme>` is an optional
	argument which works like when you start the X interface by a
	CLI command, except that `<theme>` may not begin with `-` here.



Environment variables
---------------------

`DISPLAY`
:	Used by XLib.

`HOME`
:	Home directory. Used by the program when guessing data
	directory.

`LANG`
:	Used to set `LC_ALL` or `LC_CTYPE` if none of them are defined.

`LC_ALL`
:	Primary choice for setting `locale`.

`LC_CTYPE`
:	Secondary choice for setting `locale`.

`HNEFATAFL_FONT`
:	Used by the X interface to set FontSet; a default font will be
	used if this is undefined.

`HNEFATAFL_LANG`
:	The name of a language file that the program should use, unless
	another one is specified. Note that this is only the filename,
	not the full path.

`HNEFATAFL_PATH`
:	Path to data directory. This should be a directory and must be
	the full path.

`HNEFATAFL_RC`
:	Path to RC file. This should be the full path (not just the
	filename).

`HNEFATAFL_RULES`
:	The name of a ruleset file that the program should use, unless
	another one is given as an invocation parameter. Note that this
	is only the filename, not the full path.



Files
-----

`<data>/lang/`
:	Language files. When you type in, for example, `l <file>`, the
	program looks in this directory.

`<data>/rules/`
:	Ruleset files. When you type in, for example, `r <file>`, the
	program looks in this directory.

`<data>/xlib/`
:	Data files for the X interface.

`<data>/xlib/<theme>/`
:	The filename of every `<theme>` directory must exactly match
	the lines in the `themes` file.

`<data>/xlib/themes`
:	A file that contains all the themes in the X interface, one per
	line. The first theme in the file is the default, if the ruleset
	file doesn't specify `ui_theme` and if the user didn't specify
	any theme.

`<data>/hnefataflrc`
:	RC file.

`<data>` is the directory that the program attempts to guess, or the
directory indicated by `d` command, the `-d` invocation parameter or the
`$HNEFATAFL_PATH` environment variable.

### RC file ###
You can specify an RC file in the following ways:

1.	`-c` invocation.
2.	`$HNEFATAFL_RC` environment variable.
3.	The program tries to guess which directory `hnefataflrc` is in.

The `-c` argument takes precedence over `$HNEFATAFL_RC` and the
`hnefataflrc` file. These require the full path to the RC file — it's
not enough to just type in the filename (the program does not guess in
which directory it is because it could be dangerous to run the wrong
file).

The program searches for a file named `hnefataflrc` upon startup,
guessing which directory it's in.

The `-C` invocation parameter suppresses `-c` and `HNEFATAFL_RC`.

### Language files ###
Language files can be loaded in the following ways:

1.	`-l` invocation.
2.	`$HNEFATAFL_LANG` environment variable.
3.	`l <file>` in the CLI or X console.

`-l` takes precedence over `$HNEFATAFL_LANG`. If one of them is
specified, and indicates a valid language file, then it takes precedence
over any language files specified in the RC file.

Note that you never have to type in the full path to a language file —
the program attempts to guess which directory it's in.

### Ruleset files ###
Ruleset files can be loaded in the following ways:

1.	`-r` invocation.
2.	`$HNEFATAFL_RULES` environment variable.
3.	`r <file>` in the CLI or X console.

`-r` takes precedence over `$HNEFATAFL_RULES`. If one of them is
specified, and indicates a valid ruleset file, then it takes precedence
over any ruleset files specified in the RC file.

Note that you never have to type in the full path to a ruleset file —
the program attempts to guess which directory it's in.

### How the program guesses directories ###
The program sometimes attempts to guess which directory a specified file
is in. This is only attempted when a file is opened for reading, it's
never done when a file is opened for writing. Directories are guessed in
the following order:

1.	The specified filename is tried.
2.	The directory specified by the `d` command entered by the user.
3.	The directory specified by the `-d` invocation.
4.	`$HNEFATAFL_PATH/`
5.	The directory specified by the `d` command in an RC file.
6.	`$HOME/hnefatafl/`
7.	`$HOME/.hnefatafl/`
8.	`/usr/share/hnefatafl/`
9.	`/usr/share/games/hnefatafl/`
10.	`/usr/local/share/hnefatafl/`
11.	`/usr/local/share/games/hnefatafl/`

*1* (the filename itself) is only tried if you type in the filename as
an invocation parameter, in the command-line interface or in the X
console. *1* is not tried if the filename is in an environment variable
(such as `$HNEFATAFL_LANG`) or in an RC file since it could be
unpredictable.

*3* is only tried if the `-d` invocation is given.

Paths that depend on environment variables (*4*, *6* and *7*) are not
tried if the environmental variable is not defined.

*8* through *11* are always tried.

### How to stop automatic reading of files ###
If you don't define `$HNEFATAFL_LANG` or `$HNEFATAFL_RULES`, and if you
give `-C` as an invocation parameter, then the program does not read any
files automatically upon startup.



Exit status
-----------
`EXIT_SUCCESS` (usually 0) if everything went well or `EXIT_FAILURE` for
all errors. These are defined in `stdlib.h`(3).



Examples
--------

`hnefatafl`
:	Starts the program with the default RC file.

`hnefatafl -d /opt/hnefatafl -l eng`
:	Sets the data directory to `/opt/hnefatafl` and the language to
	English (`/opt/hnefatafl/lang/eng`).

`HNEFATAFL_PATH=/opt/hnefatafl hnefatafl -l swe -r petteia`
:	Sets the data directory to `/opt/hnefatafl`, the language to
	Swedish (`/opt/hnefatafl/lang/swe`) and the ruleset to petteia
	(`/opt/hnefatafl/rules/petteia`).



Quick start
-----------
1.	Try to simply run the binary without any invocation parameters.
	`hnefataflrc` is often found automatically (see *"How the
	program guesses directories"*).
2.	If that didn't work, set `$HNEFATAFL_PATH` to the directory with
	the program's data files, or start the program with `-d <path>`.

### Language files, ruleset files and RC files ###
The program looks for `hnefataflrc` when it starts, and runs all
commands in that file (you can also specify an absolute path to an RC
file by `-c <path>` or `$HNEFATAFL_RC`). "RC" stands for "run commands"
and that's precisely what it does: it runs commands in the command-line
interface as if you would have typed them in yourself, so that you don't
have to do it manually every time you use the program. You can set
language (with the `l` command) and ruleset (with the `r` command) from
the RC file. Language can also be set by `-l <filename>` or
`$HNEFATAFL_LANG`, and ruleset can be set by `-r <filename>` or
`$HNEFATAFL_RULES`.

### Starting and stopping the X interface ###
You start the X interface with the `x` command (see `h x` for help).

Once in the X interface, you can go back to the CLI by giving the `x`
command again, or you can quit the program with the `q` command.

### Required data files ###
The only data file that's really needed to play a game is a ruleset
file. Language files are optional, but the program's printed messages
are a bit more comprehensible if you load a language file. The X
interface can (optionally) use XPM files that are arranged in themes;
the X interface *can* run without themes or with incomplete themes, but
then it will paint very basic placeholder graphics.

### Where to install a local RC file ###
If an RC file has been installed in `/usr/share/games/hnefatafl/`, then
every user can have his own RC file in either `$HOME/hnefatafl/` or
`$HOME/.hnefatafl/`, and it will be preferred over the one in
`/usr/share/games/hnefatafl/`. The same goes for all other data files.
(Of course you can also specify an absolute path to the RC file by
invocation parameter or environment variable.)



Text file syntax
----------------
All text files are parsed using the same syntax. RC files, `stdin`,
language files and ruleset files are all parsed according to the
following rules:

You can only write one command per line.

White spaces and tabulators are condensed to a single space between
words, unless preceded by `"\"` or inside quotation marks.

`#`: comment; everything following the symbol, on the same line, is
ignored.

`\`: interprets the following symbol literally, or escapes a line break.
`\t` inserts a tabulator and `\n` inserts a newline.

Single (`'`) and double (`"`) quotation marks cause the text inside them
to not be broken up into different arguments and stops white space
condensation. All other characters are also made literal (however, `"\"`
can be used inside double quotes).



Ruleset files
-------------

### General rules ###
These general rules can not be changed:

*	A player who can not move when it's his turn loses the game.
	Note that it does not matter if a player can't make any moves
	when it's not his turn.

### General arguments ###

#### `id <id>` ####
A unique identifier for the ruleset. It is case sensitive and must
contain only ASCII characters.

#### `name <name>` ####
The name of the ruleset. This is displayed to the player but has no
other purpose. Therefore it doesn't matter what the name is as long as
it's at least 1 character long.

*	The encoding should preferably be ASCII.
*	If you don't want to use ASCII, then it should be UTF-8 since
	the data files are encoded in UTF-8.
*	It *must* be an 8 bit encoding (since the bytes are stored in
	the `char` data type).

An interface may optionally display this to the player, or ignore it.
The X interface supports a name in UTF-8 or Latin-1 while the CLI
doesn't display it at all.

#### `ui_theme <theme>` ####
An interface hint for a theme that the interface may optionally use.
This argument is optional and consists of a text string.

*	Assume that the string is case sensitive.
*	An interface must assume that invalid themes may be specified in
	ruleset files, and cope with it gracefully.

An interface may or may not ignore case when comparing `ui_theme`. An
interface may also ignore `ui_theme` altogether. It is case sensitive in
the official `uicx` X interface, and ignored in the `uicx` CLI.

#### `width x` ####
Board width. 1 <= `x` <= 31.

#### `height x` ####
Board height. 1 <= `x` <= 31.

#### `pieces x...` ####
The positions of the pieces on the board at the beginning of the game.
The board is internally represented as a one-dimensional array, exactly
like it's declared here. The argument shall be followed by `width ×
height` unsigned 8 bit integers, which must all be single bits (1, 2, 4,
..., 128) or 0 (for an empty square). Every piece in the array must be
declared with `piece bit x`.

`width` and `height` must be declared before `pieces`.

#### `squares x...` ####
The squares on the board. Like the pieces, it's represented as a
one-dimensional array of the same length. 0 means that the square is not
a part of the board and that no piece can ever occupy it. Every square
in the array must be declared with `square bit x`.

`width` and `height` must be declared before `squares`.

#### `forbid_repeat` ####
Forbids repetition of previous board positions.

### Arguments for pieces ###

#### `piece bit x` ####
Declares a piece with bit `x`. This piece must be in `pieces`. You can
refer to a piece with `piece x <argument>` after declaring it.

Pieces take the following arguments:

#### `capt_edge` ####
Specifies that the piece can be captured along the edge of the board.
Squares adjacent to 0-squares are considered to be edges.

If this argument is present, `capt_sides` is reduced to the amount of
squares surrounding the piece when determining if it's captured. If
there are only 3 squares adjacent to a piece with `capt_sides = 4`,
then it's temporarily lowered to 3 to allow the piece to be captured.

If it's impossible to surround a piece on both sides, considering the
`custodial` requirement, then that requirement is dropped.

This also has the effect that if a piece, which has to be captured
custodially, is surrounded on all sides, then it's captured regardless
if the moving (capturing) piece fulfilled the `custodial` requirement.

Example (S has `capt_edge`, `custodial` and `capt_sides 2`):

	| M .
	| . .
	| M .

	| M .
	| S .	# S is not captured, since S moved.
	| M .

	| M .	# S is captured here, being surrounded on all sides.
	| S m	# If !capt_edge, he would not have been captured since
	| M .	# m does not fulfill the custodial requirement.

#### `capt_loss` ####
If the player who owns the piece loses all pieces of this type, then he
loses the game.

#### `capt_sides x` ####
Specifies how many sides that the piece has to be surrounded on to be
captured. A valid value is 1 <= `x` <= 4, but note that only 2 and 4 are
used in tafl and its variants. Default: 2.

#### `captures x` ####
Specifies the other pieces that this piece can capture, as a bitmask.
All of the pieces must be owned by the opponent. Default: 0.

#### `custodial` ####
Specifies that the piece must be surrounded on both sides, by one of the
moving pieces, to be captured. This requires that `capt_sides` is at
least 2.

Example (S has `capt_sides 2` and `custodial`):

	. M .
	. . .
	. M .

	. M .
	. S .	# S is not captured, since S moved.
	. M .

	. M .
	. S m	# S is not captured, since m does not fulfill the
	. M .	# custodial requirement.

#### `dbl_trap` ####
Specifies that the piece can trigger double trap, id est that two pieces
(belonging to the same player), that are adjacent to each other, can
be captured if both are surrounded.

In a double trap, the `custodial` requirement may be present, but it is
never required that the moving piece must be the one who surrounds the
piece custodially.

#### `dbl_trap_capt` ####
Specifies that the piece is captured by double trap. Without this, the
piece can only trigger the trap, but is not captured by it. Requires
`dbl_trap` and that at least some piece owned by the same player has
this argument.

#### `dbl_trap_compl` ####
Double trap can not be triggered if both of the surrounded pieces have
`dbl_trap_compl`. At least one piece in the trap must not have this
argument. Requires `dbl_trap` and that at least some piece owned by the
same player does not have this argument.

#### `dbl_trap_edge` ####
When double trapping, `capt_edge` is ignored and this argument is used
instead. It works the same way. Requires `dbl_trap`.

#### `dbl_trap_encl` ####
If this is specified, then the piece has to be surrounded completely to
be double trapped. This works as if `capt_sides` had been 4, and
`custodial` is not present. Requires `dbl_trap`.

If this is not specified, then ordinary capturing rules apply (that is,
`capt_sides` and `custodial`) when determining if double trap is
triggered.

#### `dbl_trap_squares x` ####
The piece must stand on a square in `x` for double trap to trigger. This
must be specified if the piece has `dbl_trap`. Default: 0.

#### `escape` ####
Specifies that the piece can escape to squares with `escape` to win the
game.

#### `noreturn x` ####
Specifies the squares that the piece may occupy at the start of the
game, but never return to once he has left them. All squares in `x` are
treated as a unit, meaning that if `x = 3`, then the piece may move
between squares 1 and 2 without limitation, but never move back to 1 or
2 after moving to square 4. Requires that the piece may occupy the
square according to `occupies`. Default: 0.

#### `occupies x` ####
Specifies the squares that the piece is allowed to occupy. Default: 0.

#### `owner x` ####
Specifies the player who owns the piece (0 or 1). There is no default —
this argument is mandatory.

#### `ui_bit x` ####
This is an interface hint. The interface should (if possible) make the
piece look like the piece with bit `x`. If this is not possible, then
the interface is free to ignore this setting. `x` must be a single bit
or 0. 0 means disabled. Default: 0.

An interface must support `ui_bit` to the greatest possible extent. Both
the CLI and X interface in `uicx` support it.

### Arguments for squares ###

#### `square bit x` ####
Declares a square with bit `x`. This square must be in `squares`. You
can refer to a square with `square x <argument>` after declaring it.

Squares take the following arguments:

#### `captures x` ####
Specifies the pieces that the square can capture, as a bitmask. Default:
0.

When a piece (*a*)
moves to a square that is adjacent to an enemy piece (*b*), and an empty
square (*c*) is adjacent to *b*, and the square *c* can capture *b*,
then the square *c* is considered to be an enemy piece to *b*. Note that
this requires that the square in question is empty: if there is a piece
on the square, then that piece's `captures` is used instead.

#### `capt_sides x` ####
Overrides `capt_sides` for the piece that is standing on the square to
`x`, if `x` is not 0 and the piece is among `capt_sides_pieces` (else
the square does not have this effect). Requires that some piece can
occupy the square. Default: 0.

If `x` is 4, then `custodial` does not apply. Note that `capt_sides` for
pieces does not work that way (but in all normal rulesets, `capt_sides =
4` is always used with `!custodial`, hence this behavior).

When double trapping, `dbl_trap_encl` takes precedence over this
setting.

#### `capt_sides_pieces x` ####
Specifies that the pieces in `x` are affected by the square's
`capt_sides` setting. Pieces that are not in `x` are unaffected. Note
that if `capt_sides` is specified for some square, then
`capt_sides_pieces` must contain at least one piece (which can occupy
the square).

#### `escape` ####
Specifies that pieces with `escape` can escape to this square to win the
game.

#### `ui_bit x` ####
Works exactly like `ui_bit` for pieces, but for squares.



Interface: command-line
-----------------------
The command-line interface always runs on program startup. The RC file
is actually just a file with commands that are automatically run on the
command-line before it starts reading commands from `stdin`. You can
then start the X interface from the command-line interface, and when you
close the X window, you go back to the command-line interface.

Type `"h"` for help.

Entering `EOF` in `stdin` is equivalent to the `"quit"` command. The
program never asks for confirmation for any command.

### RC files ###
Commands in RC files are subject to some additional limitations that are
not in effect when reading commands from `stdin`.

*	All commands are echoed with `"# "` as prompt (after the line is
	interpreted and tokenized, so that you see the command as the
	program sees it).
*	When the program guesses directories, it never tries the
	filename itself (*1* in *"How the program guesses
	directories"*).
*	The following commands are suppressed if they have been given as
	invocation parameters or environment variables:
	-	`-e` suppresses `e`.
	-	`-d` or `$HNEFATAFL_PATH` suppresses `d`.
	-	`-l` or `$HNEFATAFL_LANG` suppresses `l`.
	-	`-r` or `$HNEFATAFL_RULES` suppresses `r`.
*	The following commands are forbidden:
	-	`w` (save game)



Interface: XLib
---------------
Type `"h"` for help. The help in X is a bit more terse than in the CLI
because only one line can be used for printing, but the commands are
essentially the same.

### X console ###
*	Press `<Escape>` to abort a command.
*	Press `<Enter>` to execute a command.
*	Press `<Backspace>` or `<Delete>` to delete a symbol.

You can not move the caret.

### Themes ###
In the theme file (`<data>/xlib/themes`), there is (by default) a theme
named `null`, which does not have a directory. This is intentional (and
this is why there is a file named `null` — so you can't create a
directory with the that name). You can load the `null` theme if you want
to use placeholder graphics.



Translating
-----------
If you translate the language files (in `data/lang/`), and if you are OK
with distributing them under the ISC license (see *License and
warranty*), please send them to me so I can distribute them with the
program.

The syntax of the language files is very simple. The first word, which
is separated by white spaces or tabs, is the *language key*. This is
used by the program to find the translated text string that is shown to
the user. You should not change the language key. The rest of the line
is the translated text string which is changed when translating.
Example:

	cli_cmd_game_over	The game is over

This can be translated into Swedish by changing the line to:

	cli_cmd_game_over	Partiet är slut

*	The encoding is UTF-8.
*	The file is valid if it can be loaded by the program.

You can print all the required language keys with the `-L` invocation
parameter.



Diagnostics
-----------
The errors that are printed usually describe what's wrong. If no
language file has been loaded, the program may print an error code
instead. These types of error codes exist:

*	`FR`: general error, such as failure to allocate memory or I/O
	error.
*	`RREAD`: the ruleset file is so malformed that it can't even be
	parsed. In this case the program usually prints out the line
	that was read when the error occurred.
*	`RVALID`: the ruleset file can be parsed but the rules are not
	valid.
*	`FRX`: XLib interface error.

### Language files ###
When the program reads language files, it doesn't tolerate the slightest
error. All language keys must be present and have translated language
strings, and no unknown language keys may be present — otherwise the
file is rejected.

If you see weird text strings like, for example, `"cmd_game_over"`, then
it means that no valid language file has been loaded.

If you see an error message like `"fr_1"` (`"fr"` is the error type and
`"1"` is the error code), you can check the translated string in the
language file.

### Locale ###
If the program prints an error message about `setlocale()`, it's because
it can't guess what `$LC_ALL` or `$LC_CTYPE` should be. `$LC_ALL` (or
`$LC_CTYPE`) should preferably indicate an UTF-8 locale. If those two
environment variables are not defined, the program tries to use `$LANG`.

If the X interface does not read or print UTF-8 symbols correctly, it is
probably because `$LC_ALL`, `$LC_CTYPE` or `$LANG` does not indicate an
UTF-8 locale. The problem could also be that X can't open the correct
font (FontSet). You can try setting `$HNEFATAFL_FONT` to a font that you
know exists. If that doesn't work, it's a problem with the operating
system.

If no FontSet is specified, the program first tries
`"-misc-fixed-medium-r-normal-*-*-140-*-*-*-*-iso10646-*"` and then
`"fixed,*"`. It is recommended to use a monospaced font since all text
is painted in a console.

The program tries to use the user's locale by setting `$LC_ALL` (or
similar). If that's not possible, it falls back on Latin-1 (which will
render UTF-8 symbols incorrectly). If you can't get FontSet to work, you
can, in the worst case, force the program to use Latin-1 by the `-s`
invocation parameter. If so, language files containing symbols other
than ASCII will not be rendered correctly, unless you convert them from
UTF-8 to Latin-1 with `iconv`(1).

	iconv -l
	iconv -f UTF-8 -t ISO-8859-1 <file>

However, the program is designed for UTF-8, and barely tested with other
encodings. The program is expected to print strange symbols sometimes if
you don't use UTF-8, but it should never *crash* because of it (so
please send a bug report if it happens).



Bugs
----
The hash table has two known bugs and is therefore not compiled into the
program by default:

*	It makes the computer player slower.
*	It makes the computer player select different moves sometimes,
	compared to when it's playing without the hash table (because it
	doesn't know of the `forbid_repeat` rule).



Sources
-------
The sources should not be blamed for any errors I've made.

*	[Hnefatafl — the Strategic Board Game of the Vikings](
	http://hem.bredband.net/b512479)
	by *Sten Helmfrid*.
*	[Hnefatafl — the Game of the Vikings](
	http://tafl.cyningstan.org.uk)
	by *Damian Walker*.



See also
--------
Vǫluspá



Homepage
--------
`www.hnefatafl.se`



Author
------
Alexander Söderlund
`<soderlund` *at* `tafl` *dot* `se>`



Contributors
------------
Alexander Dolgunin
`<a` *dot* `dolgunin` *at* `gmail` *dot* `com>`
has contributed source code to the `core` component (see comments in
`board.c`).

Damian Walker (`http://tafl.cyningstan.org.uk`) has contributed rulesets
(all the ones that begin with `recon_*`) and rule expertise.



Copyright
---------
The Hnefatafl program consists of four components: `gleipnir`, `core`,
`aim` and `uicx` (see the `src/` directory).

*	`core` is © 2013-2014 Alexander Söderlund (Sweden) and
	Alexander Dolgunin (Russia).
*	`gleipnir`, `aim` and `uicx` are © 2013-2014 Alexander Söderlund
	(Sweden).
*	The following rulesets are © 2014 Damian Walker (United
	Kingdom):
	-	`recon_alea_evangelii`
	-	`recon_brandub`
	-	`recon_coppergate`
	-	`recon_gokstad`
	-	`recon_tablut`
	-	`recon_tawlbwrdd`
	-	`recon_vimose`
*	This manual and other files are © 2013-2014 Alexander Söderlund
	(Sweden).

The whole Hnefatafl program and all related files (source code, ruleset
files, manuals and other files) are released under the ISC license (see
*License and warranty*, below) with permission from all contributors.



License and warranty
--------------------
Copyright © 2013-2014 Alexander Söderlund (Sweden),
2013-2014 Alexander Dolgunin (Russia),
2014 Damian Walker (United Kingdom)

Permission to use, copy, modify, and distribute this software for any
purpose with or without fee is hereby granted, provided that the above
copyright notice and this permission notice appear in all copies.

THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

