Harald Johnsen wrote:
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.
It would not only be one line of text in most cases, but rather
using one node for everything would make some basic formatting
necessary to assign certain fragments of a string to certain
locations on a CDU screen.
Except that the 3D cockpit can't handle text display atm.
The 2D panel can.
Sounds like a feature request to me ;-)
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.
Okay, I see - I know that situation somehow myself, would you
care to elaborate on the exact limitations and what would
be needed to be added to Nasal/FG in order for you to be able
to use Nasal for most of the logical implementation ?
I think it would definitely make sense to address these
issues, it's not long ago that I brought up a very similar
topic, where the solution to the problem would finally mean
to adapt the Nasal<->FlightGear interface and add additional
functionality, something that was quite controversially discussed
here, so in that context it might very well help if you could
individually address the shortcomings that *you* encountered to
really show that there'd be also need by other projects/ideas to be
able to use more features within Nasal than those that are currently
available.
Once it start to work I'll see how to make a buildin version.
so, did you drop the Nasal based approach entirely because
of the problems you mentioned above ?
We are talking of an FMC but of course
I wanted to redo at least the ehsi display (for the eye candy).
Erik mentioned some time ago that it isn't yet really possible to
do simple animations using Nasal in FlightGear, at least that's
what Andy indicated when he was asked about that, I think.
So, I doubt that there'll be an easy way really soon to simply
create/animate a NAV display that would fit to a FMC using Nasal -
simply because most of its modes require some kind of animations,
which all differ from make to make.
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...
well, good luck: would also like to see something like that
to be available, so there'd be already TWO FlightGear based ideas
that might benefit from an extension to add basic
animation support to Nasal - hey, doesn't this sound convincing ? :-)
This would have delayed the ehsi too much.
is there really that much lag involved when doing
such things using Nasal - i.e. NO smooth animations ?
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.
nope, but very few people here seem to be in favour of
extending Nasal in a way to add more enhanced functionality -
I did make suggestions for similar interfaces, did also
offer to take of such things myself, but ...didn't even
get much feedback about what _might_ be added and what not.
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.
Also, you'd usually want to have an array of waypoints
as well as the possibility to add inactive waypoints,
i.e. setting a certain property in each WP if its
active or not.
And then there's of course the scenario that Manuel
mentioned, where not only one FMC would need to
available but rather 2 or even 3 FMC which act
indenpendently from eachother, so accessing all the
same properties in the first place would tie them
together.
Hence, you'd usually rather want to be able to
determine what data actually feeds the FDM and
what data is merely backup data of another running
FMC.
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).
yes, sure - I do know, but what I meant by the above paragraph: is
that stuff also exported to be available within Nasal scope ?
be it by means of some specific property tree nodes or
specific Nasal/FGCommands - I don't think so, but correct me
if I am wrong.
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.
There are various pages where there are explanations about the
most widely spread types of FMS, if you haven't already done so,you
might want to check out http://www.b737.org.uk/fmc.htm
But there are other pages as well, check out pprune.org for
threads about FMS/FMC and CDUs, where those most involved
features also get explained.
Some are obvious, some not, I don't have a real manual. And of
course I never used a real FMC.
If you want me to, I would not mind to provide real (but dated)
information scanned from an original manual, either as a PDF file
or simply as a set of images, there's still this big manual that
I once purchased from ebay :-)
But that stuff can be pretty large if scanned in... :-/
While the purpose and functions of each CDU page is very well
illustrated in those manuals, there are permanent references to
all the other systems of the aircraft, so the terminology is not
necessarily self-explanatory in each case. Particularly if you
don't have the full manual available.
Hence, you might end up having to learn much more than you actually
intended to: while you mentioned mainly the EHSI that you want to
redo, there's one other pretty significant thing that interacts with
the FMS - the "Mode Control Panel", this isn't yet implemented in
FlightGear either.
Stuff like LNAV/VNAV and all the other abbreviations that aircraft
manufacturers came up with are a lot easier to grasp when there's
some "hands on example".
Without a basic MCP implementation in FlightGear, one could not
take that into account for an implementation.
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.
Actually, the fact that FMS-designers try to keep CDUs
(their "GUI") quite simple, does also come in handy if
you want to resemble it:
For example, looking at the b737 page - the keypad itself
would not even require that much thinking because many
of the alpha-numeric keys simply need to put a character/number
into the scratchpad area when pressed, while each line select key
would merely need to make a specific line active to string
retrieval from the scratchpad.
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).
I am going to send you a private eMail, about the manual stuff
that I've here and that might come be useful - on the other hand
there is other FMC software that might be suitable to familiarize
you with the look, feel and some of the basic functionality,
"Project Magenta" has a complete suite of all these systems and
if though it's actually commercial, there are demo downloads available
where the FMC/CDU itself is USABLE while there's simply no functionality
to really use it with a game.
But for the purpose of getting more familiar it might be a good idea
to take a look into projectmagenta.com
The gui (with skins) and the ability to build new looks/functionalities
with XML config and nasal code is a great idea.
yes, one could provide general functions to set up the CDU and
use specific functions like
legs_page = createpage();
and customize each page then by doing something like:
legs_page.title="Legs");
etc.
As most of the pages follow a generic template it should be
possible to use some basic template mechanism in order to have
all objects available on each newly created page.
I talked a bit about the ehsi allready, I don't know how to enhance the
one in FG without using opengl code.
I'm afraid there's no real other way if I remember Erik correctly :-/
----------
Boris
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
