Re: [Flightgear-devel] FGFS Externals

[Curtis L. O. <cu...@fl...>]

John Wojnaroski writes:
> [C++ is still a little strange to me]

We are all in the process of learning ... I really hadn't done much
C++ myself before we started the FlightGear project.

> and some of it's finer points and nuances still elude me

Unless your name is Bjarne Stroustrup, I'd be a little suspicious of
anyone who said they completely understood *all* the nuances and finer
points of the language. :-)

> > The fdm=external is specifically present to force the system to run
> completely
> > without an FDM.  That's why there are only placeholders.  On the master
> system,
> > you must not use this option, in order that there is an FDM somewhere on
> your
> > network of computers!
> >
> Yes, I see that, but what happens if you run an internal FDM
> with --native=socket,in,...
> then the external source will overwrite, then the internal -> the battle of
> the FDMs, may
> the faster machine win.

It boils down to this.  We have provided "capabilities" but not
enforced "policies".  So, you could engineer an FDM battle if you
wanted; in C/C++ there's nothing in the language that says you can't
run way off the end of your arrays.  This means mistakes are possible,
but hopefully people will be able to figure out how to effectively use
the capabilities without stepping on too many land minds.  This whole
section of code could be improved.  What you are seeing is a first cut
at the problem.

> > The --native option is used to emit the fdm data (as you observed) and on
> > receipt is supposed to smear it on top of the existing fdm data structure,
> > completely ignoring all the usual method calls.
> >
> In essence, you have a psuedo fdm running as a network module.
> Now you have two places to interface to Simgear, change the Simgear
> structures
> and you have two mappings to handle (FDM and Network) Also sounds like a
> backdoor,
> still like the approach through the FDM interface using all the usual calls.
> Perhaps a little
> more overhead, but more manageable. Curtis mentioned needing a change in
> plib for broadcast
> Would using the FDM interface route obviate that need?

I'm not sure I'm on the same page with you here.  SimGear provides the
low level communication support code ... socket, serial, file, etc.

> BTW: the code is well written and structured; when the village idiot (me)
> can make
> sense of it that speaks volumes....
> 
> That's a little strange and raises the issue of portability and OSF
> standards.
> If Curtis can ever stop having "fun" playing cops and robbers ;-) we might
> want to discuss it further.

I can give you my boss's cell phone number if you want to take it up
with him. :-)

> In the interim, will probably write some code this weekend just to
> see what happens, get a little more practice, and gain further
> understanding...

I'm about 650 emails behind (after weeding out all the spam and
unimportant stuff) so bear with me.  I'll do my best to answer
questions and provide feedback.

Regards,

Curt.
-- 
Curtis Olson   Human Factors Research Lab       FlightGear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org