Manuel Bessler wrote:
I know that it would have some advantages if the FMC were part of
flightgear, however I tend towards an seperate program like Harald is
planning.
It could be easily networked so you could use an older computer with a
small monitor to put the FMC/CDU on. The FMC program wouldn't even have
to provide a text/graphics output necessarily.
regarding the ability to easily network it, pretty much all
necessary data for that purpose should already be available
via the exported property tree, I'd think - of course using
a separate machine for that purpose is an interesting idea
for some users and one which would not be taken care of if
one simply used FlightGear internal implementations
exclusively...
Of course, if there's running X11 on that other machine,
FlightGear could still provide the graphics for such an
externally displayed CDU via network without the need to
explicitly be running on that machine :-)
Would it work to have one node in the property tree that would contain
the text on the CDU display ?
This should not be problem I think, except maybe that CDUs usually have
several lines/columns with individual text and the actual layout
differs from CDU to CDU, so you'd rather provide a general
node with sub-nodes defining what's getting displayed and where.
Also, I'd personally consider it not a good approach to add
these things statically to a node, rather they should be
possible to be dynamically modified by users who really
want to "design" their own FMC, be it logically or really
visually.
It should be very easy to use the NewGUI feature (xml gui) to present a
display with buttons as well as pc keyboard input.
How about the setup in a B747-400 with 3 CDUs (and AFAIR also 3 FMCs).
For those building cockpits at home, having more than one CDU, each
displaying different pages would be nice :-)
IF there is a basic framework for FMCs/CDUs it shouldn't matter how
many of these are being displayed, in general it would make use of
the same resources, the only thing that would really change is
the data/mode being used, so it would be merely a matter of
creating several instances of an FMC data object [arrays] to
be able to differentiate between all these different
systems.
That way, each CDU could display specific data.
But I'd agree that an approach to add FMC/CDU support externally
does have its justification when it really comes to those
professional users who are building their own cockpits or
simply those users that are using those expensive external
standalone CDU units.
On the other hand I think one has to ponder about the pros & cons,
and certainly it would be more of an advantage for the AVERAGE
user to have a GENERAL xml-configurable mechanism to add support
for FMCs/CDUs to FlightGear than having merely a way to code
your own stuff by accessing the property tree via network.
As long as its underlying interface is general enough and also
accessible within the property node, external software for
purposes like the ones you mentioned above, could still easily
make use of the functionality provided by FlightGear, while
the majority of users could use XML-configured systems.
----------
Boris
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
