[Flightgear-devel] FGFS Externals

[John W. <ca...@mm...>]

Ahh, the perversity of it all... Getting ready to run some sims and tests to
look
at the net traffic, and the net crashes, the gateway is sick.

After a little fussing with the firewall, things were back to normal

The bottom line: (Good news)
The net traffic looks just fine. Addresses are what they should be and all
machines can
send and receive UDP datagrams. One interesting exception; the wireless
laptop cannot
send data but it can receive. This might have something to do with the
firewall inside the
3Com box setting/restricting certain privileges and services for wireless
devices.

The fact that Norman Vine's test program
(http://vso.cape.com/~nhv/files/fgfs) receives the
cur_fdm_state indicates that the io is working so the most likely problem is
somewhere in
the interface between the flightsim and simgear.

(Not so good news)
If you look at the code modules in External.cxx in the FDM directory you
will see only placeholders,
while the other models are"busy" exchanging data structures with Simgear. If
the "external" option is
envoked (see the fg_init function) then it would seem reasonable the data
exchange would occur here.
So broadcast works at the lower levels, the "cookie crumb trail" ends at
External - nothing comes in and
nothing goes out.

 I am considering adding some functionality to External.cxx to take network
input and output it to the Simgear
structures consistent with the other FDMs. There is some new code in the CVS
respository in ../src/Network
that Curtis has just added. Does this (should this) be coordinated?

IMHO: The interfaces between the FDMs and Simgear should be consistent and
External should be the
place to enforce that consistency with the OSI Layered model. Machines
communicating with simgear
might be running on an IBM, an old VAX (very old), in Fortran, in Ada. who
cares. As long as they meet the
interface spec, they are welcome.

Developers wishing to add additional features or calculations to the input
would do so here within the walls
of the External module. For example; in a former life I worked with the
AFHRL folks in Arizona on a large flight sim project for air-to-air combat.
The "enemy computer" would always win any engagement with a human pilot
since it always had "perfect information" as to the adversery's state while
the human had to estimate based on visual and radar observations. It was
necessary to "dirty-up" the computer's channels to level the playing field.

Regards
Jack W