RE: Full Thrust Format for Email games

On Fri, 30 May 1997, Joachim Heck - SunSoft wrote:

>   An FTF file consists of a series of zero or more blocks, with each
> block contained in curly braces.  Each block consists either of one
> attribute value pair or of an attribute followed by a curly-brace
> delimited set of attribute value pairs.

Its probably counter-productive to use curley-braces as a
block-definition system; it makes parsing sequences a lot more complex
than necessary.  A better method might be to use a nested RFC822 (the
UseNet format for email/news headers) structure.

The basic structure is this: you have a series of fields, each
terminated by a colon and a space, followed by a value.  Each group of
headers is followed by a blank line.  That's it.  

Of course, to do iterations of things like weapon mounts, etc, you
have to get creative (check the first field, is it another weapon or
have we moved to the next descriptor-type?), but its easily doable and
libraries already exist for Python, Perl, C and other languages to
parse RFC822.

If you really wanted to get fancy, you could use RFC822 in concert
with a MIME structure, where each sub-module gets its own MIME section
and the program only parses out those sections it recognizes and the
RFC822 sections/fields within that it has understanding of.
Personally, I prefer the former option.

An example follows, of a DSII design instead of a FT ship, but this is
a hint that the formats may be extended later.	;)

===
DSIIVehicle: Medium Battle Tank (Tracked)
Description: Standard MBT, relatively low-tech.
Class: 3
Mobility: Fast Tracked
Powerplant: HMT
Armour: 3
ECM: Enhanced
PDS: Enhanced

Weapon: HKP
Class: 3
Number: 1
Turret: Yes
Mount: Full Traverse

Weapon: RFAC
Class: 3
Number 1
Turret: Yes
Mount: Full Traverse
===

A relatively naiive but efficent way to parse this would be to take
the whole message and RFC822 it, turning the top block of fields into
the accessed header, and all following the first blank line into the
Body.  Parse the first block, looking for your standard fields and
consider any fields that may or may not be present (like PDS).

Once you have the basic block headers parsed, look at the first field
of the Body, splitting it on the colon and considering what's on the
line before it.  This should tell you what kind of block it is.
RFC822 the Body (turning the new block into the header to consider and
the rest of the blocks into the new Body) and parse for fields
meaningful to the type of block you've already determined it is.  Once
that's done, repeat recursively to the rest of the message.

This algorithm has the advantage that the only static field that can't
be anywhere in the block is the one on the first line of the block
that determines what kind of block it is.  It also is advantageous
that not only is the format human-readable, but human-writable as
well, just in case someone uses it in an automated PBeM turn-gatherer
at some point, and someone can't run the client that generates the
file for whatever reason.  Another advantage is that, in necessity or
for good reason, multiple vehicles can be packaged in the same file
(ie. if I read a block that starts again with DSIIVehicle, I know its
time to start parsing a new vehicle and save/print/whatever the older
one).  You could even, theoretically, store /multiple kinds/ of
vehicle in the same file (for instance, for documenting an entire
Legion, including Centuries and landing craft, plus tenders).

[Yeesh, can you tell I spend all day designing/implimenting stuff like
this?]

-- 
[  Alexander Williams {thantos@alf.dec.com/zander@photobooks.com}  ]
[ Alexandrvs Vrai,  Prefect 8,000,000th Experimental Strike Legion ]
[	     BELLATORES INQVIETI --- Restless Warriors		   ]
====================================================================
		      "There are no innocents."