Re: [Flightgear-devel] FGFS Externals

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

> It isn't clear from your text; there may be a misunderstanding here.

C++ is still a little strange to me and some of it's finer points and
nuances
still elude me

> 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.

> 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?

BTW: the code is well written and structured; when the village idiot (me)
can make
sense of it that speaks volumes....

> So, the fact that you're observing the packets travel (and arrive)
suggests
> that there is something about the way that the smearing is done, that
might
> not be working under Windows (but does under Linux).
>
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.

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

Jack W