AAFREV

This review of the Aircraft and Adventure Factory from
Mallard/BAO deals only with the latter: the adventure part.

With AAF it is possible to write "scripts" or "scenarios" which
are really BASIC-type programs. These, when compiled ("AAF
YOURFILE.TXT YOURFILE.ADV") will create "adventures" which can
then be run with MicroSoft's Flight Simulator 4.0.

A typical adventure will find you at the threshold of a runway.
When you're ready to contact Clearance, you say (into your
imaginary mike) "Wherever Clearance, Cessna 1234B requesting
clearance for wherever, as filed." Then clearance will come back
with "Cessna 1234B, cleared as filed. Squawk 1234." In digital
sound, if you have a sound card (most popular brands are
supported) -- what's really happening is that a sound .VOC file
is being played. You acknowledge: "Cessna 34B direct wherever"
etc.; clearance says "Cessna 34B readback correct. Ground on
point whatever." On through contact ground, contact tower,
contact departure, contact approach, contact (destination) tower,
contact (destination) ground. etc. You actually hear ATC as you
(or your friends, to give different voices for different
stations) make them as .VOC files.

Or you're on standby with a rescue squad. You hear "Cessna 1234B,
can you pick up a guy with a broken leg at Mount Snow?" Respond,
receive detailed orders, and take off.

Or, when flying over RFK stadium hear "Hail to the Redskins!"
from the band as the 'Skins score another touchdown.

The script, which is a text file later to be compiled, looks, as
remarked, much like a BASIC program, and indeed the language is a
somewhat cut-down version of QBASIC. It depends largely on "if. .
. . [then]/endif" statements, such as:

if com(121.35)
     PLAY "CLEAR.VOC"
endif

This means if your COM radio is tuned to 121.35, play the
(recorded by you) CLEAR.VOC file. But you don't *have* to play
something (maybe you don't have a sound board). That instruction
could have read PRINT "Cessna 23B, cleared as filed", and such a
message would print out at the bottom of your screen.

All kinds of variables can be tested: not just COM tuning, but
also:

if airspeed(500,1000)  ;speed range low-hi
     print "You're going too fast"
endif

if altagl(0,100)     ;altitude above ground level, range low-hi
     play "PULLUP.VOC"
endif

if cylinder(16580,12346,0,15)
     print "You're within 15 nautical miles"
endif

This last means if you're in an imaginary cylinder centered at
those FS North and FS East coordinates with a radius of 15 miles,
print the message.

if key("a")
     gosub readout
endif

If you press "a" you will go to a subroutine which will print on
your screen your current altitude and course, and then return you
to the rest of the adventure. GOSUBs are typical BASIC commands;
you can also GOTO another part of the adventure, which has a
particular "label" -- again a standard BASIC routine.

if gearup()   ;this one has no other parameters
     print "Put your gear down, you ninny!"
endif

Most of these are checking a variable or a condition and taking
appropriate action. But you can also *set* certain variables:

if key("b")
     setvar(cloud1top,5000)
     setvar(cloud1bot, 500)
endif

This sets the top of cloud level 1 to 5000 (meters) and the
bottom to 500 meters -- cold front coming through. The condition
("if" statement) on this could have been a cylinder, as above:
when you're within that cylinder (so far from those coordinates),
roll in the clouds.

You can check whether you're on the glideslope, whether you're on
the ground, whether your course is within certain limits, whether
you have a sufficient climb rate, etc. AAF can do more than radar
can. There are a good many "standard" inquiries/requests as in
the foregoing, and also a great many FS variables which can
otherwise be tested and changed: cloud1top is one of them. They
are all listed in the appendix to the AAF documentation -- I do
not myself yet know what all of them mean and do!

Another interesting program fragment is:

if course(0,0)
endif
printvar(result,"Your course is: ")

(PRINTVAR is a primitive which prints the value of any variable
with a header.)

The variable RESULT "contains the value to be compared against
(LOW, HIGH)" according to the documentation. Here it will contain
your course. So also with AIRSPEED(LOW,HIGH), ALTITUDE(LOW,HIGH),
BANK(LOW,HIGH), although I haven't tried all of these. The gosub
readout routine mentioned above uses these.

So, PLAY or PRINT a voice file or a message. But you can also
VIEW: a .PCX graphics file. If you have a .PCX file with, say, an
instrument approach plate for your destination airport, you can
issue:

if cylinder (x,y,0,15)
     view(10,DCAIAP.PCX)
endif

If you're in that cylinder, your DCAIAP.PCX will come up on the
screen for ten seconds. .PCX files are PC Paintbrush files, and
can be created with many different graphics programs, including
Windows Paint. They have to be 320 x 200 resolution and 256
colors.

In the case of demos (which you make) PLAY is replaced by $PLAY.
Other "primitives" are WAIT(x) -- a certain number of seconds
before proceeding; and SETPOSITION(NORTH,EAST,ALTITUDE), which
puts your plane at such-and-such FS coordinates at a particular
altitude.

Now the catch with all of this, of course, is that you have to
learn at least the rudiments of BASIC (as used here) to write
these scripts, and that might be a little scary for those who
have never done this sort of thing ("all I know how to do is turn
on my computer and type FS!"). But this is not complicated BASIC:
as a matter of fact, it does not include some commands which are
pretty common in BASIC: IF . . . ELSE, FOR loops, WHILE
statements, etc.: I myself miss all of these, and whereas they
can all be duplicated in AAF-BASIC, it's pretty cumbersome. The
AAF compiler is fast, but not terribly robust: it gives you some
warnings if you make a mistake, but these are not always obvious,
and sometimes you can write an .ADV which sure won't work because
of some syntax error, and the compiler won't tell you anything.
My own advice is to look at the original text files (before
compiling) that have been produced by others -- no doubt they
will be made available on the FSFORUM and elsewhere. As of this
writing, there are, however, only two available: SAMPLE.TXT,
which comes with AAF, and my CMIBMI.TXT, in CMIBMI.ZIP, library
5/Aircraft/Adventure. Ask yourself "why did he do that?" and "why
does that work?" Or, write some small programs with just a few
routines, see how they work, and then combine them (with a word
processor) into a larger program. You can write up quite a series
of subroutines, such as the readout mentioned above (gives you
current altitude and heading).


Making the voice files (.VOC) is another matter. I myself write
programs first to PRINT to the screen, to see if they work:
then I write a .VOC and change PRINT to PLAY. Sound cards usually
come with a utility to produce .VOC files -- for example,
Soundblaster Pro has VEDIT2. I somewhat prefer a shareware
program, Blaster Master, available (BMST5.ZIP) in the Sound Cards
library of the MIDI forum. Both of these programs can "pack" .VOC
files so they take up less room (and therefore less disk space
and less upload/download time). But these have to be unpacked to
restore the original before they can be used with AAF: there is a
utility to do this provided with the program. I do not myself
find it very helpful: "packed" and "unpacked" files sound pretty
awful. However, I *do* find that at least for voice, you can do
your "sampling" at a very low rate, even 4000, and this
considerably cuts down the size of the .VOCs. Anyway PKZIP won't
touch packed files: they're already compressed.

Of course some ATC messages work much better as PRINTs than as
PLAYs. In my readout subroutine, I print on the screen airspeed,
course, and altitude -- I just use PRINTVAR(x,"message") here. It
would be a killer to make up .VOC files for all the possible
combinations!

What They Say:
It is always a bit difficult to get the conventions and jargon of
ATC communications. There are several sources, however. One is
John Rafferty's Realistic Commerical Flying with Flight Simulator
(Compute! Books, 1989), which has several good examples. The best
book here, however, is by Paul Illman and Jay Pouzar, The Pilot's
Radio Communications Handbook (Tab Practical Flying Series, Tab
Books, 1989) -- everything from UNICOM to transiting an Air
Traffic Control Center, with a great many examples and a complete
script for Kansas City to Minneapolis and back. Or, of course,
you can follow the examples provided with AAF or from other
sources, such as Simutech's ProSim Plus series, as well as files
which will be uploaded to the FSFORUM. And you can buy a scanner
and listen to real ATC (and the pilot's responses) if you're
within range of an active airport. Basically there are certain
procedures: the pilot calls clearance, clearance clears and hands
off to ground; ground authorizes taxi and hands off to tower;
tower clears for takeoff; departure sends one on the way;
approach gives general directions and then (destination) tower
gives such things as vectors and final landing clearance, handing
off to ground, etc. SubLOGIC's Air Transport Pilot has all of
these and others as well, printed to the screen. Obviously there
are other messages: "Descend and maintain x thousand", "Turn
right to heading y", "Execute missed approach", and the like.

I really have been playing with AAF for only a short time, and I
am sure that there are many more applications which have not yet
occured to me: no doubt we will be seeing some of them on the
FSFORUM. But still, at least in my experience so far, this is the
best "add-on" to MicroSoft's Flight Simulator since the Aircraft
and Scenery Designer. I confidently predict that it will produce
a whole flurry of new scenarios/scripts which will extend our use
of FS by a major factor. And that's not even counting the
aircraft designing functions, which are another matter for
another day (and most probably another reviewer!).

Jim Ross 70235,143