Digital Battlefield Reports

> Mk wrote:

--Not that I was taking a defensive stance or anything; just if you got
some
--ideas, thoughts, suggestions, etc, about improving the reports - feed
me!!
--I'm willing to do what I can but want to still keep them
human-readable.

The solution Alun used was to use AWK to reformat the Mk reports into a
computer readable form. I'm using the same method for the current Scott Field
pbem game.

Basically its impossible to get everyone to agree on a standard FT report and
the requirements for humans and computers are orthogonal. My strategy now is
to have a single computer readable FT format and to translate all the myriad
report
styles to it using AWK/Java/Perl etc. (AFAIK some version of AWK's
available on
platforms including VMS - Mac?)

This strategy works well in my place of work where we have to translate vector
data into & out of editing systems (DXF,DGN etc.). Architecturally its the
best solution and creates the least amout of work. Believe me, I've been
working in this field for some years now. If we could standardise the human
readable form then the number of filters to write would be less.

FYI - we have VMS too and it has Motif and behaves like any other
X-server?

> timj@uk.gdscorp.com writes:

@:) Basically its impossible to get everyone to agree on a standard FT @:)
report and the requirements for humans and computers are @:) orthogonal.

I'm not sure I agree with either of these statements. I haven't really tried
to get anyone to agree to a standard FT report, but I don't think anybody
really complained about Mark's in his PbEM game. As far as computer vs human
requirements, Mark's reports, plus some delimiters (begin ship USS Shoshone,
eg) to make it easier for the machine to recognize where ships started or
where systems ended and hangar bay contents began, would have been enough.
Actually until I screwed it up the program I was working on was taking the
existing input without any real complaints. Oh, the only other thing I think a
computer program would require would be a stable report structure. Some
surprising things happened along the way, like approximate positions (denoted
by ~), that screwed up my input routines. But none of that was hard to fix, so
as long as one knew it was coming, one could pretty easily be prepared in
advance to handle it.