Optional Fields/Values - FTF

On Wednesday, May 28, 1997 7:35 PM, Joachim Heck - SunSoft 
[SMTP:jheck@East.Sun.COM] wrote:
>   Destroyed/damaged is good and here is one place where you start to
> run into compatibility problems.  Maybe somebody's got an optional
> rule that allows batteries to be damaged and fire as the next lower
> class - should that be handled in this file format somehow?  Maybe not
> specifically, but perhaps there's a way of keeping the format general
> enough that this information could be contained in it somehow.
>

joachim makes a good point and one I am pondering the way to handle
optional 
/house modifications - he gives a good example and the one I remember is
in a 
B5 game where the batteries could be switched into 'Intercept' mode.

Currently I am writing a big spread sheet for the FTF records and data
fields 
and my strategy is as joachim suggests to come up with a set of valid 
descriptive values which form the core and then allow optional and
additional 
modifications, for example a system status can be one of :-

{destroyed, damaged, empty, inactive, active}

This should be exhaustive for the common states of an FT system (i.e.
any 
icon in a hull box)
but is extensible to cover other states. A parser should ignore states
it 
doesn't understand.

Another way to do this is to have record fields that are optional for a 
weapon this might be

TargetMode: {antiship, intercept, pointdefence}

The default is antiship if not explicitly stated.

Tim Jones