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

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

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

Reply via email to