.\" Automatically generated by Pod::Man 2.23 (Pod::Simple 3.14) .\" .\" Standard preamble: .\" ======================================================================== .de Sp \" Vertical space (when we can't use .PP) .if t .sp .5v .if n .sp .. .de Vb \" Begin verbatim text .ft CW .nf .ne \\$1 .. .de Ve \" End verbatim text .ft R .fi .. .\" Set up some character translations and predefined strings. \*(-- will .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left .\" double quote, and \*(R" will give a right double quote. \*(C+ will .\" give a nicer C++. Capital omega is used to do unbreakable dashes and .\" therefore won't be available. \*(C` and \*(C' expand to `' in nroff, .\" nothing in troff, for use with C<>. .tr \(*W- .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' .ie n \{\ . ds -- \(*W- . ds PI pi . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch . ds L" "" . ds R" "" . ds C` "" . ds C' "" 'br\} .el\{\ . ds -- \|\(em\| . ds PI \(*p . ds L" `` . ds R" '' 'br\} .\" .\" Escape single quotes in literal strings from groff's Unicode transform. .ie \n(.g .ds Aq \(aq .el .ds Aq ' .\" .\" If the F register is turned on, we'll generate index entries on stderr for .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index .\" entries marked with X<> in POD. Of course, you'll have to process the .\" output yourself in some meaningful fashion. .ie \nF \{\ . de IX . tm Index:\\$1\t\\n%\t"\\$2" .. . nr % 0 . rr F .\} .el \{\ . de IX .. .\} .\" .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). .\" Fear. Run. Save yourself. No user-serviceable parts. . \" fudge factors for nroff and troff .if n \{\ . ds #H 0 . ds #V .8m . ds #F .3m . ds #[ \f1 . ds #] \fP .\} .if t \{\ . ds #H ((1u-(\\\\n(.fu%2u))*.13m) . ds #V .6m . ds #F 0 . ds #[ \& . ds #] \& .\} . \" simple accents for nroff and troff .if n \{\ . ds ' \& . ds ` \& . ds ^ \& . ds , \& . ds ~ ~ . ds / .\} .if t \{\ . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' .\} . \" troff and (daisy-wheel) nroff accents .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' .ds 8 \h'\*(#H'\(*b\h'-\*(#H' .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] .ds ae a\h'-(\w'a'u*4/10)'e .ds Ae A\h'-(\w'A'u*4/10)'E . \" corrections for vroff .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' . \" for low resolution devices (crt and lpr) .if \n(.H>23 .if \n(.V>19 \ \{\ . ds : e . ds 8 ss . ds o a . ds d- d\h'-1'\(ga . ds D- D\h'-1'\(hy . ds th \o'bp' . ds Th \o'LP' . ds ae ae . ds Ae AE .\} .rm #[ #] #H #V #F C .\" ======================================================================== .\" .IX Title "C4 6" .TH C4 6 "2011-05-24" "Tile World" "" .\" For nroff, turn off justification. Always turn off hyphenation; it makes .\" way too many mistakes in technical documents. .if n .ad l .nh .SH "NAME" c4 \- Chip's Challenge combined converter .SH "SYNOPSIS" .IX Header "SYNOPSIS" .Vb 1 \& c4 [\-INTYPE] INFILENAME [\-OUTTYPE] OUTFILENAME .Ve .PP c4 allows one to translate between the several different types of files used to represent level sets for the game Chip's Challenge. .PP c4 expects there to be two files named on the command-line. c4 reads the levels stored in the first file, and then writes the levels out to the second file. The format to use with each file usually can be inferred by c4 by examining the filenames. If not, then it may be necessary to use switches before one or both filenames to indicate their type. .PP There are four different types of files that c4 understands. .PP .Vb 1 \& \-D MS data file (*.dat). .Ve .PP This is the file type used by Chip's Challenge for Microsoft Windows 3.x. It is the file type used by most other programs, such as ChipEdit and Tile World. .PP .Vb 1 \& \-R Lynx ROM file (*.lnx, *.lyx) .Ve .PP This \*(L"file type\*(R" is actually just a \s-1ROM\s0 image of the original Chip's Challenge for the Atari Lynx handheld. It is used by Lynx emulators such as Handy. .PP .Vb 1 \& \-P MS\-DOS fileset (directory of *.pak files) .Ve .PP This is the format used by the MS-DOS port of Chip's Challenge. In this case, the filename given on the command line actually names a directory, containing *.pak files. .PP .Vb 1 \& \-T textual source file (*.txt) .Ve .PP This file type is native to c4. It is a plain text file, which allows levels to be defined pictorially using a simple text editor. A complete description of the syntax of these files is provided below. .SH "EXAMPLES" .IX Header "EXAMPLES" .Vb 1 \& c4 mylevels.txt mylevels.dat .Ve .PP Create a .dat file from a textual source file. .PP .Vb 1 \& c4 \-P levels \-D doslevels.dat .Ve .PP \&\*(L"levels\*(R" is a directory of MS-DOS *.pak files. c4 translates the directory contents into a single .dat file. Note that the switches in this example are optional, as c4 would be able to infer the desired formats. .PP .Vb 1 \& c4 mylevels.dat chipsch.lnx .Ve .PP Embed the levels from the .dat file into a Lynx \s-1ROM\s0 file. Note that c4 does \s-1NOT\s0 create chipsch.lnx. You must provide the \s-1ROM\s0 image file, which c4 then alters to contain your levels. (Obviously, you should not use this command on your master copy of the \s-1ROM\s0 file.) .PP .Vb 1 \& c4 chipsch.lnx \-T out .Ve .PP Output the levels in the .dat file as a text file. Here the \-T switch is needed to indicate that a text file is the desired output format. .PP When producing a text file, c4 will attempt to produce legible source, but the results will often not be as good as what a human being would produce. (In particular, c4 cannot draw overlays.) .SH "NOTES" .IX Header "NOTES" Be aware that there can be various problems when translating a set of levels using the \s-1MS\s0 ruleset to one of the Lynx-only file formats. There are numerous objects and configurations in the \s-1MS\s0 ruleset which cannot be represented in the Lynx ruleset. Usually c4 will display a warning when some aspect of the data could not be transferred intact because of this. .PP The remainder of this documentation describes the syntax of the textual source file format. .SH "LAYOUT OF THE INPUT FILE" .IX Header "LAYOUT OF THE INPUT FILE" The source file is broken up into subsections. Each subsection defines a separate level in the set. .PP The subsections are separated from each other by a line containing three percent signs: .PP .Vb 1 \& %%% .Ve .PP A line of three percent signs also comes before the first level and after the last level, at the end of the source file. .PP Any other line that begins with a percent sign is treated as a comment, and its contents are ignored. .PP Beyond these things, the source file consists of statements. Statements generally appear as a single line of text. Some statements, however, require multiple lines. These multi-line statements are terminated with the word \fBend\fR appearing alone on a line. .SH "INPUT FILE HEADER STATEMENTS" .IX Header "INPUT FILE HEADER STATEMENTS" There are a couple of statements that can appear at the very top of the source file, before the first level subsection. .PP .Vb 1 \& ruleset [ lynx | ms ] .Ve .PP The \fBruleset\fR statement is the most important of these. It defines the ruleset for the level set. If the \fBruleset\fR statment is absent, it defaults to \fBlynx\fR. .PP .Vb 1 \& maxlevel NNN .Ve .PP The \fBmaxlevel\fR statement specifies the number of the last level in the .dat file. By default, this value is provided automatically and does not need to be specified. .PP In addition to the above, a set of tile definitions can appear in the header area. See below for a full description of the \fBtiles\fR multi-line statement. Any tile definitions provided here remain in force throughout the file. .SH "INPUT FILE LEVEL STATEMENTS" .IX Header "INPUT FILE LEVEL STATEMENTS" Within each level's subsection, the following two statments will usually appear at the top. .PP .Vb 2 \& title STRING \& password PASS .Ve .PP The \fBtitle\fR statement supplies the level's title, or name. The title string can be surrounded by double quotes, or unadorned. The \&\fBpassword\fR statement supplies the level's password. This password must consist of exactly four uppercase alphabetic characters. .PP If the level's number is 150 or less, the \fBpassword\fR statement may be omitted. In that case the level's password will default to match that level in the original Lynx set. (N.B.: The Lynx \s-1ROM\s0 file format does not provide a mechanism for setting passwords, so in that case the default password will be used regardless.) .PP The following statements may also appear in a level subsection. .PP .Vb 1 \& chips NNN .Ve .PP The \fBchips\fR statement defines how many chips are required on this level to open the chip socket. The default value is zero. .PP .Vb 1 \& time NNN .Ve .PP The \fBtime\fR statement defines how many seconds are on the level's clock. The default value is zero (i.e., no time limit). .PP .Vb 1 \& hint STRING .Ve .PP The \fBhint\fR statement defines the level's hint text. As with the \&\fBtitle\fR statement, the string can either be unadorned or delimited with double quotes. If a section contains multiple \fBhint\fR statements, the texts are appended together, e.g.: .PP .Vb 3 \& hint This is a relatively long hint, and so it \& hint is helpful to be able to break it up across \& hint several lines. .Ve .PP Note that the same can be done with \fBtitle\fR statements. .PP .Vb 5 \& tiles \& DEF1 \& DEF2 \& ... \& end .Ve .PP The \fBtiles\fR multi-line statement introduces one or more tile definitions. The definitions appear one per line, until a line containing \fBend\fR is found. Note that the tile definitions given here only apply to the current level. A complete description of tile definitions is given below. .PP .Vb 9 \& map [ X Y ] map [ X Y ] \& LINE1 LINE1 \& LINE2 LINE2 \& ... ... \& and end \& OVER1 \& OVER2 \& ... \& end .Ve .PP The \fBmap\fR statement defines the actual contents of (part of) the level's map. The line containing the \fBmap\fR statement can optionally include a pair of coordinates; these coordinates indicate where the the section will be located on the level's map. If coordinates are omitted, the defined section will be located at (0 0) \*(-- i.e., the upper-left corner of the level. The lines inside the \fBmap\fR statement pictorially define the contents of the map section, until a line containing \fBand\fR or \fBend\fR is encountered. When the map is terminated by \fBand\fR, then the lines defining the map section are immediately followed by lines defining an overlay. The overlay uses the same origin as the map section (though it is permissible for the overlay to be smaller than the map section it is paired with). A complete description of the map and overlay sections is given below. .PP .Vb 1 \& border TL .Ve .PP The \fBborder\fR statement specifies a tile. The edges of the map are then changed to contain this tile. Typically this is used to enclose the level in walls. .PP The following statements are also available, though they are usually not needed. They provide means for explicitly defining level data, for the occasional situation where the usual methods are more cumbersome. .PP .Vb 1 \& creatures X1 Y1 ; X2 Y2 ... .Ve .PP The \fBcreatures\fR statements permits explicit naming of the coordinates in the creature list. Pairs of coordinates are separated from each other by semicolons; any number of coordinate pairs can be specified. There can be multiple \fBcreatures\fR statements in a level's subsection. .PP .Vb 1 \& traps P1 Q1 \-> R1 S1 ; P2 Q2 \-> R2 S2 ... .Ve .PP The \fBtraps\fR statement permits explicit naming of the coordinates for elements in the bear trap list. Coordinates are given in one or more groups of four, separated by semicolons. Each group consists of the x\- and y\-coordinates of the brown button, an arrow (\->), and then the x\- and y\-coordinates of the bear trap. Any number of \fBtraps\fR statements can appear in a level's subsection. .PP .Vb 1 \& cloners P1 Q1 \-> R1 S1 ; P2 Q2 \-> R2 S2 ... .Ve .PP The \fBcloners\fR statement permits explicit naming of elements in the clone machine list. It uses the same syntax as the \fBtraps\fR statment, with the red button's coordinates preceding the coordinates of the clone machine. .PP .Vb 1 \& level NNN .Ve .PP The \fBlevel\fR statement defines the level's number. By default it is one more than the number of the prior level. .PP .Vb 1 \& field NN B01 B02 ... .Ve .PP The \fBfield\fR statement allows fields to be directly specified and embedded in the .dat file. The first argument specifies the field number; the remaining arguments provide the byte values for the actual field data. These statements are only meaningful in conjunction with producing a .dat file. .SH "DEFINING TILES" .IX Header "DEFINING TILES" A tile definition consists of two parts. The first part is either one or two characters. The characters can be letters, numbers, punctuation \&\*(-- anything except spaces. The second part is the name of a tile or a pair of tiles. The characters then become that tile's representation. .PP Here is an example of some tile definitions: .PP .Vb 6 \& tiles \& # wall \& * teleport \& rb red button \& @ chip south \& end .Ve .PP (Note that a single tab character comes after the characters and before the tile names.) Once these definitions have been provided, the newly-defined characters can then be used in a map. .PP The above definitions all use singular tiles. To define a pair of tiles, combine the two names with a plus sign, like so: .PP .Vb 4 \& tiles \& X block + bomb \& G glider north + clone machine \& end .Ve .PP Notice that the top tile is named first, then the bottom tile. .PP The \fBtiles\fR statement is the only statement that can appear in the header, as well as in a level's subsection. Tile definitions in the header are global, and can be used in every subsection. Tile definitions inside a subsection are local, and apply only to that level. .PP A number of tile definitions are pre-set ahead of time, supplying standard representations for some of the most common tiles. (If these representations are not desired, the characters can always be redefined.) Here are some of the built-in definitions: .PP .Vb 5 \& # wall $ computer chip \& , water H socket \& = ice E exit \& & fire [] block \& 6 bomb ? hint button .Ve .PP See below for the complete list of tile names and built-in definitions. .PP A few groups tiles allow one to specify multiple definitions in a single line. For example: .PP .Vb 3 \& tiles \& G glider \& end .Ve .PP This one definition is equivalent to the following: .PP .Vb 6 \& tiles \& Gn glider north \& Gs glider south \& Ge glider east \& Gw glider west \& end .Ve .PP (Note that \*(L"G\*(R" by itself is still undefined.) All creatures, including Chip, can be defined using this abbreviated form. .PP Doors and keys are the other groups that have this feature; the following definition: .PP .Vb 3 \& tiles \& D door \& end .Ve .PP is equivalent to: .PP .Vb 6 \& tiles \& Dr red door \& Db blue door \& Dy yellow door \& Dg green door \& end .Ve .SH "MAP SECTIONS" .IX Header "MAP SECTIONS" Once all the needed tiles have defined representations, using the map statement is a simple matter. Here is an example: .PP .Vb 7 \& map \& # # # # # # \& # & & # # # \& [] H E # \& # & $ # # # \& # # # # # # \& end .Ve .PP This is a map of a small room. A block stands in the way of the entrance. Three of the four corners contain fire; the fourth contains a chip. On the east wall is an exit guarded by a chip socket. .PP Note that each cell in the map is two characters wide. (Thus, for example, the octothorpes describe a solid wall around the room.) .PP Here is a larger example, which presents the map from \s-1LESSON\s0 2: .PP .Vb 4 \& tiles \& B bug north \& C chip south \& end \& \& map 7 7 \& # # # # # # # \& # $ # \& # # \& # # # # # # # # # # # # \& # # # # B , , $ # \& # E H # # B , , [][]C ? # \& # # # # B , , $ # \& # # # # # # # # # # # # \& # # \& # $ # \& # # # # # # # \& end .Ve .PP There are a couple of different ways to fill a cell with two tiles. The first way is to simply use tile definitions which contains two tiles: .PP .Vb 4 \& tiles \& X block + bomb \& G glider east + clone machine \& end \& \& map 12 14 \& # # \& 6 E # \& # # X \& G \& end .Ve .PP The second way is to squeeze two representations into a single cell. Obviously, this can only be done with both representations are a single character. .PP .Vb 5 \& tiles \& [ block \& G glider east \& + clone machine \& end \& \& map 12 14 \& # # \& 6 E # \& # # [6 \& G+ \& end .Ve .PP In both cases, the top tile always comes before the bottom tile. Note that you can \*(L"bury\*(R" a tile by placing it to the right of a space: .PP .Vb 5 \& map \& # # # # # # \& 6 6 6E # \& # # # # # # \& end .Ve .PP Any number of map statements can appear in a level's subsection. The map statements will be combined together to make the complete map. .SH "OVERLAY SECTIONS" .IX Header "OVERLAY SECTIONS" Every map statement can optionally include an overlay section. This overlay permits button connections and monster ordering to be defined. .PP The overlay is applied to the same position as the map section it accompanies. The overlay can duplicate parts of the map section it covers, and any such duplication will be ignored. The only characters in the overlay that are significant are the ones that differ from the map section it covers. These characters are treated as labels. Labels are always a single character; two non-space characters in a cell always indicates two separate labels. Any non-space characters can be used as labels, as long as they don't match up with the map. .PP An overlay section defines a button connection by using the same label in two (or more) cells. One of the labelled cells will contain either a bear trap or a clone machine, and the other will contain the appropriate button. If there are more than two cells with the same label, all but one should contain a button. .PP Characters that only appear once in an overlay, on the other hand, indicate creatures. The characters then indicate the ordering of the creatures in the creature list with respect to each other. The ordering of characters is the usual \s-1ASCII\s0 sequence (e.g., numbers first, then capital letters, then lowercase letters). .PP For example, here is a map with an overlay that demonstrates all three of these uses: .PP .Vb 7 \& tiles \& G glider east \& + clone machine \& r red button \& * beartrap \& b brown button \& end \& \& map \& G v # \& G+ * r * G+ b & # r \& G+ * r # # r \& # > b b G < # # \& and \& 2 v # \& A c C d C d & # A \& B a C # # B \& # > a c 1 < # # \& end .Ve .PP In this example, capitals are used for the clone machine connections, lowercase for the bear trap connections, and numbers are used for the creature ordering. .PP (Note that the gliders atop clone machines are not numbered. While it is not an error to include clone machine creatures in the ordering, they are ignored under the \s-1MS\s0 ruleset.) .PP It is not necessary to reproduce any of the map section's text in the overlay section. Blanks can be used instead. The ignoring of matching text is simply a feature designed to assist the user in keeping the overlay's contents properly aligned. .PP The \fBtraps\fR, \fBcloners\fR, and \fBcreatures\fR statements can be used in lieu of, or in conjunction with, data from overlay sections. In the case of the creature list, items are added to the list in the order that they are encountered in the source text. .PP If a level contains no overlay information and none of the above three statements, then this information will be filled in automatically. The data will be determined by following the original Lynx-based rules \*(-- viz., buttons are connected to the next beartrap/clone machine in reading order, wrapping around to the top if necessary. (Likewise, the creature ordering is just the order of the creatures in their initial placement, modified by swapping the first creature with Chip.) Thus, if you actually want to force an empty bear trap list, clone machine list, or creature list, you must include an empty \fBtraps\fR, \&\fBcloners\fR, and/or \fBcreatures\fR statement. .SH "TILE NAMES" .IX Header "TILE NAMES" Here is the complete list of tiles as they are named in definitions. Two or more names appearing on the same line indicates that they are two different names for the same tile. Note that the tile names are not case-sensitive; capitalization is ignored. .PP .Vb 10 \& empty \& wall \& water \& fire \& dirt \& ice \& gravel \& computer chip ic chip \& socket \& exit \& ice corner southeast ice se \& ice corner southwest ice sw \& ice corner northwest ice nw \& ice corner northeast ice ne \& force floor north force north \& force floor south force south \& force floor east force east \& force floor west force west \& force floor random force random force any \& hidden wall permanent invisible wall permanent \& hidden wall temporary invisible wall temporary \& wall north partition north \& wall south partition south \& wall east partition east \& wall west partition west \& wall southeast partition southeast wall se \& closed toggle wall closed toggle door toggle closed \& open toggle wall open toggle door toggle open \& blue door door blue \& red door door red \& green door door green \& yellow door door yellow \& blue key key blue \& red key key red \& green key key green \& yellow key key yellow \& blue button button blue tank button \& red button button red clone button \& green button button green toggle button \& brown button button brown trap button \& blue block floor blue wall fake \& blue block wall blue wall real \& thief \& teleport \& bomb \& beartrap trap \& popup wall \& hint button \& clone machine cloner \& water boots water shield flippers \& fire boots fire shield \& ice boots spiked shoes skates \& force boots magnet suction boots \& block moveable block \& cloning block north block north \& cloning block south block south \& cloning block east block east \& cloning block west block west \& chip north \& chip south \& chip east \& chip west \& ball north \& tank north \& bug north bee north \& paramecium north centipede north \& fireball north flame north \& glider north ghost north \& blob north \& walker north dumbbell north \& teeth north frog north .Ve .PP (The last nine lines, listing the creatures, only show the north-facing versions. The remaining 27 names, for the south\-, east\-, and west-facing versions, follow the obvious patttern.) .PP Note that tile names may be abbreviated to any unique prefix. In particular, this permits one to write names like \*(L"glider north\*(R" as simply \*(L"glider n\*(R". .PP There are also tile names for the \*(L"extra\*(R" \s-1MS\s0 tiles. These tiles are listed in parentheses, as an indicator that they were not originally intended to be used in maps. .PP .Vb 10 \& (combination) \& (chip drowned) \& (chip burned) \& (chip bombed) \& (unused 1) \& (unused 2) \& (unused 3) \& (exiting) \& (exit 1) \& (exit 2) \& (chip swimming north) (chip swimming n) \& (chip swimming west) (chip swimming w) \& (chip swimming south) (chip swimming s) \& (chip swimming east) (chip swimming e) .Ve .PP Finally, note that one can also explicitly refer to tiles by their hexadecimal byte value under the \s-1MS\s0 rules by using the \*(L"0x\*(R" prefix. Thus, the names \*(L"0x2A\*(R" and \*(L"bomb\*(R" are equivalent. .SH "PREDEFINED TILE DEFINITIONS" .IX Header "PREDEFINED TILE DEFINITIONS" The following is the complete list of built-in tile definitions: .PP .Vb 10 \& # wall E exit \& $ ic chip H socket \& , water = ice \& & fire 6 bomb \& ; dirt : gravel \& ~ wall north ^ force floor north \& _ wall south v force floor south \& | wall west < force floor west \& | wall east > force floor east \& _| wall southeast <> force floor random \& ? hint button @ chip south \& [] block [ block \& ^] cloning block north + clone machine \& <] cloning block west + clone machine \& v] cloning block south + clone machine \& >] cloning block east + clone machine .Ve .SH "LICENSE" .IX Header "LICENSE" c4, Copyright (C) 2003\-2006 Brian Raiter .PP Permission is hereby granted, free of charge, to any person obtaining a copy of this software and documentation (the \*(L"Software\*(R"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: .PP The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. .PP \&\s-1THE\s0 \s-1SOFTWARE\s0 \s-1IS\s0 \s-1PROVIDED\s0 \*(L"\s-1AS\s0 \s-1IS\s0\*(R", \s-1WITHOUT\s0 \s-1WARRANTY\s0 \s-1OF\s0 \s-1ANY\s0 \s-1KIND\s0, \&\s-1EXPRESS\s0 \s-1OR\s0 \s-1IMPLIED\s0, \s-1INCLUDING\s0 \s-1BUT\s0 \s-1NOT\s0 \s-1LIMITED\s0 \s-1TO\s0 \s-1THE\s0 \s-1WARRANTIES\s0 \s-1OF\s0 \&\s-1MERCHANTABILITY\s0, \s-1FITNESS\s0 \s-1FOR\s0 A \s-1PARTICULAR\s0 \s-1PURPOSE\s0 \s-1AND\s0 \s-1NONINFRINGEMENT\s0. \&\s-1IN\s0 \s-1NO\s0 \s-1EVENT\s0 \s-1SHALL\s0 \s-1THE\s0 \s-1AUTHORS\s0 \s-1OR\s0 \s-1COPYRIGHT\s0 \s-1HOLDERS\s0 \s-1BE\s0 \s-1LIABLE\s0 \s-1FOR\s0 \s-1ANY\s0 \&\s-1CLAIM\s0, \s-1DAMAGES\s0 \s-1OR\s0 \s-1OTHER\s0 \s-1LIABILITY\s0, \s-1WHETHER\s0 \s-1IN\s0 \s-1AN\s0 \s-1ACTION\s0 \s-1OF\s0 \s-1CONTRACT\s0, \&\s-1TORT\s0 \s-1OR\s0 \s-1OTHERWISE\s0, \s-1ARISING\s0 \s-1FROM\s0, \s-1OUT\s0 \s-1OF\s0 \s-1OR\s0 \s-1IN\s0 \s-1CONNECTION\s0 \s-1WITH\s0 \s-1THE\s0 \&\s-1SOFTWARE\s0 \s-1OR\s0 \s-1THE\s0 \s-1USE\s0 \s-1OR\s0 \s-1OTHER\s0 \s-1DEALINGS\s0 \s-1IN\s0 \s-1THE\s0 \s-1SOFTWARE\s0.