> Would it work to have one node in the property tree that would contain > the text on the CDU display ? > The 3D cockpit could listen for changes to this node and when one > happens, update the CDU display in the 3D cockpit...
I like this idea, the text could be use for the FG cockpit or for some external CRT CDU. Except that the 3D cockpit can't handle text display atm. The 2D panel can. > Using a dynamic - non library-based - approach, possibly utilizing > Nasal for it, would probably be preferable if all the stuff is available > within the Nasal scope, that way one could easily borrow fragments of > code from other FMC implementations and add it to your own FMC. > ... My first idea was to write everything in Nasal ;) But due to some limitations in FG I have decided to start with an external FMC. Once it start to work I'll see how to make a buildin version. We are talking of an FMC but of course I wanted to redo at least the ehsi display (for the eye candy). Now there is a few problems with 3D gauges : can't draw text, can't draw dynamic occurence of sprite/texture. Similar limitations with 2d gauges concerning the dynamic part. So I was thinking about draw to texture technique and some graphical api in Nasal to generate that kind of display... This would have delayed the ehsi too much. > So, you'd mainly want to have access to all the relevant data, > the first thing that comes to mind would be functions to > interactively retrieve data from the navaids/airports file > in order to deal with those value accordingly, I don't think > that Nasal can already retrieve such data !? It's not difficult to add a few interfaces to acces this data. Even waypoints can allready be added just by touching the right property but the code in auto_gui.cxx is too restrictive about the type of wp one can insert. > In order to really determine what data and functions to access > it would be necessary, one would first need to look into a > FMC manual and find out what data sources are being used to > compute the stuff, OR what -flightgear based data- could > ALTERNATIVELY be used for that purpose. FG has the needed databases for the routes (airports, runways, nav, airways). > here, but actually there's still a bit more to it - which is probably > easier to find if you really get your hand on a FMS (training) manual, > actually that would be quite a sufficient source because you could > design the whole FMS -> page by page <- after it. I am looking the web to find the information and I try to understand the different pages. Some are obvious, some not, I don't have a real manual. And of course I never used a real FMC. > Another idea I just had: Why not put all the general algorithms needed > in an average FMC into a library (possibly as part of SimGear). > Things like performance calculations, (access to) route databases, input > validation (eg: airport code exists?, does this airport have a runway > xxR?),routing calculations,... > > This library could then be used/linked to build an FMC, either withing fgfs our > as a standalone program. Sure, and the external version is allready using part of FG code, as is or modified. When we are more advanced in the project we will see where to put back all the adds. > An approach like the one suggested by Jim would certainly have > the potential to add many variations of FMCs simply because it > would be mainly a thing of specifying the appeareance and logics > using a XML file with some Nasal code. Right. > Or... how about implementing it outside of flightgear at first and then > hooking it in when the code is somewhat stable? Yes. > Maybe Harald can provide some more details about what he want to > take into consideration and if there are any things that weren't > yet mentioned in that thread. Thanks for the feedback. Concerning the implementation of the fmc I will continue with the external version for now because I think it's the one that can be ready the first in time. As I said before I don't have all the knowledge to build it enterely by myself so I will need a lot of feedback at the beginning (the fonctions of the fmc but also the look and feel). The gui (with skins) and the ability to build new looks/functionalities with XML config and nasal code is a great idea. I talked a bit about the ehsi allready, I don't know how to enhance the one in FG without using opengl code. Harald. ps: I hope you can read me, english is not my first tongue. _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
