Martin Spott wrote:
Well, I prefer you to understand it as well-meant lobbying, driven by
the strong feeling that FG needs this - not for me but for others who
could do much more by connecting an external FDM to FG than I ever
could.
Just have a look at the CIGI "Interface Control Document", they do care
very much about defining the low-level protocol. Although CIGI isn't
adequate for being used as FDM interface for FlightGear I find it very
interesting to see how they approach the goal to offer a reliable
interface to the developer.
When I became aware of FG I first started looking for something like a
"remote FDM interface definition", but I was put off by the "simply
copy the struct" way that I would have had to go. As I was quite
uneducated in mangling other people's C++ code I grounded my project
after a while. As you know I'm not the only one who felt offended by
the mentioned 'interface'. Other people who actually _did_ interface to
FG decided not to follow the ongoing changes and stick to old FG
versions as long as there is no 'official' interface definition that
they can expect to be stable and platform independent.
Now as you aim to interface to a quite unrelated FDM I had the hope an
interface definition that matches the forementioned attributes might
evolve as a side effect.
Well there is always a struggle between designing the perfect module or
interface and getting things done.
Too much designing and you can design something that can't be built in a
finite/human time frame. With no design effort or advance thought, you
end up with a big mess. So there needs to be a balance between the two
... obviously we want to get things done, but obviously we want to avoid
big messes.
There is a proposal on the table for a flexible binary structure similar
to the "generic" protocol, but binary. But as far as I know, no one has
started any coding.
But, an FDM interface needs to do more than shove a datastructure back
and forth. There needs to be some higher level communication to tell
the remote FDM when it should reset it self or when it should trim for
in air or on the ground, and what trim conditions are requested (i.e.
start in air at 4500' MSL, 98 kts, 10 degree flaps, gear up, in a 20
degree right banking turn.)
There are also very important and difficult timing issues to consider
with a remote FDM. How those are handled can have a *huge* impact on
the latency and smoothness of flightgear rendering.
The other issue to consider is we could create the worlds most super
whiz bang remote FDM interface, but you must remember that 99% of the
time, people are trying to interface to remote FDM code that already
exists. These people typically aren't going to want to spend months
implimenting the other end of our super feature rich protocol, and the
more complicated we get, the less they'll want to write the other end of it.
As you suggest, passing a C struct over the net has some disadvantages,
but it is simple, it is easy to code, it is efficient, and can be made
to work very well. Most people doing this stuff are doing it on the
same machine, or between similar machines. If endianness does pose a
problem, these people are usually smart enough to quickly discover that
and the fix is pretty easy (maybe a bit tedious but easy.)
There are always a lot of factors that influence people's design
decisions, and don't be too quick to rule out simple, easy, robust,
quick to code ....
As I'm sure you know there is room for many different interfaces within
the FlightGear umbrella, so if anyone wants to do something better (or
maybe I should say something with a different feature set and different
strengths and weaknesses) we all would welcome it. In open-source, good
ideas tend to succeed and grow, bad ideas tend to die on the vine ...
but no one wants to stand in the way of anyone trying out a new idea ...
that is one of FlightGear's core values.
Curt.
--
Curtis Olson http://www.flightgear.org/~curt
HumanFIRST Program http://www.humanfirst.umn.edu/
FlightGear Project http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
_______________________________________________
Flightgear-devel mailing list
[email protected]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
