Best working glass cockpit airliner for FS 3.0 ?

[drmccoy]

Hello there, dear FlightGear Community!

I recently discovered this precious gem of flight simming software, and I am amazed by the quality of some of your content. I am highly interested in very realistic cockpits (i.e. high quality textures, every control clickable, etc ...) for multiple airliner planes. I have found some really promising work (i.e. the Airbus 320/330 or the 747), but a lot of planes I download won't utilize their PFDs, CDUs and FCMs. All the screens are simply pitch black. Everything else seems to work quite fine. In case of the Airbus 330, I have even downloaded the latest git master (seeing as the last commit was sometime around summer last year, this did not provide a fix for the problem). Without working controls, the planes are pretty useles, sad to say. In case of the Boing 707 (which doesn't have a glass cockpit but another lovely highly realistic cockpit environment), I cannot get the plane to start up. Neither by using the included auto start feature, nor by doing it on my own following the provided checklists.

That being said, I realize there are probably a lot of planes that are not optimized for newer versions of FG, let alone 3.0. The only plane with a glass cockpit that seems to work is the included 777. While it's love to have a working glass cockpit airliner, the cockpit itself is rather scarce, and half the controls aren't clickable, which is a shame I think.

So I was wondering, can any of you point me in the right direction for working glass cockpit airliners for FG3.0? I also thought about helping out here or there. I'm not a very talented artist, meaning I won't improve the visual quality of a 3D cockpit at all. But as a software engineer, I think it wouldn't be too hard to make a lot of the unclickable controls in a plane clickable (even if nothing will happen after clicking them, like for a passenger cabin light switch).

Let me finish by asking you to not get me wrong. I'm not demanding anything and I think this whole project is quite ahead of some of the other so called flight simulators (FSX is really quite shitty compared to this).

[Hooray]

That being said, I realize there are probably a lot of planes that are not optimized for newer versions of FG, let alone 3.0. The only plane with a glass cockpit that seems to work is the included 777. While it's love to have a working glass cockpit airliner, the cockpit itself is rather scarce, and half the controls aren't clickable, which is a shame I think.
So I was wondering, can any of you point me in the right direction for working glass cockpit airliners for FG3.0?

So far, the 777-200ER ("Seattle Edition") is our most advanced airliner featuring a "plausible" airliner cockpit, but it's far from complete - and nowhere close to what's offered through various commercial FSX/XP addons.

I also thought about helping out here or there. I'm not a very talented artist, meaning I won't improve the visual quality of a 3D cockpit at all. But as a software engineer, I think it wouldn't be too hard to make a lot of the unclickable controls in a plane clickable (even if nothing will happen after clicking them, like for a passenger cabin light switch).

As a software engineer interested in glass cockpit stuff, it would actually be better if you had a look at FlightGear scripting - FlightGear has an integrated scripting language called "Nasal".
This works very much like JavaScript in your browser - it can be used to extend/create simulator features without touching the c++ code or rebuilding the binary: http://wiki.flightgear.org/What_is_Nasal

Nasal for C++ programmers

It's a functional programming language that is very close to JavaScript/C syntax (curly braces) and looks a lot like Php for example.
Nasal code can be written/tested just by running FlightGear and using the integrated Nasal Console:
http://wiki.flightgear.org/Nasal_Console


2D rendering is accomplished through a hardware-accelerated 2D rendering API implemented on top of our property tree called "Canvas".

The 2D rendering API is a wrapper on top of ShivaVG (OpenVG, vector graphics), OSG (OpenSceneGraph) primitives and a handful of rendering primitives (raster images, groups, maps, paths).
Nasal has scriping space bindings (wrappers) for those APIs. This is the way glass cockpit displays can be fully implemented in scripting space these days. Even without a lot of coding.

For an introduction, see: Canvas - 2 years later

• http://wiki.flightgear.org/Nasal
• http://wiki.flightgear.org/Canvas

The ND is based on a scripting space framework for creating maps/charts using a MVC approach - this allows us to use the same back-end code for rendering instruments, but also maps/charts for other purposes (e.g. the GUI): http://wiki.flightgear.org/MapStructure


The following screen shot shows the ND which is purely implemented in scripting space on top of the "MapStructure" framework, which internally uses Nasal/Canvas:
http://wiki.flightgear.org/Canvas_ND_Framework


There are a few other efforts to help port existing instruments/dialogs to use Nasal/Canvas, but that's very much work in progress and not yet finished:

• http://wiki.flightgear.org/Canvas_MCDU_Framework
• http://wiki.flightgear.org/Canvas_PFD_Framework
• http://wiki.flightgear.org/Canvas_MFD_Framework
• http://wiki.flightgear.org/Canvas_EFB_Framework

If you are interested in helping with any of these, just get in touch - being able to use git and gitorious would be a plus.

[drmccoy]

Wow, now this was not only a quick but also very detailed reply. I don't have too much free time at my hand at the moment, but I'd be very interested in helping you guys out here to create few more interesting planes with glass cockpits. I work with git every day, haven't used gitorious so far, but platforms like github or atlassian's stash, so I guess this won't be much of a hassle. How do I sign up?

[Hooray]

I work with git every day, haven't used gitorious so far, but platforms like github or atlassian's stash, so I guess this won't be much of a hassle. How do I sign up?

http://wiki.flightgear.org/Git
http://wiki.flightgear.org/FlightGear_G ... developers

Once you have a gitorious account, you can clone the fgdata repo there - which will take a while if your connection is slow - if in doubt, use the torrent/git bundle instead: http://wiki.flightgear.org/Downloading_ ... bittorrent

To get started, I'd suggest to play a bit with Nasal scripting and Canvas - there are a few tutorials that you may want to check out (see the wiki). Also, to help with Nasal/Canvas and glass cockpit stuff, you should ideally know how to use OOP in Nasal (which is extremely simple and straightforward actually) - we have a handful tutorials on that. Basically, classes in Nasal are implemented as hashes, with a "this" pointer named me and inheritance implemented through a vector named parents, the vector contains a list of parent classes that are used to look up fields/methods. There's no access specifiers or encapsulation in the form of "public/protected/private" - it's all basically like a C struct, i.e. always public visibility/access. For example:

Code: Select all

struct Position2D {
 double latitude_deg, longitude_deg;
};

struct Position3D : public Position2D {
double altitude_ft;
};


Would look like this in Nasal:

Code: Select all

var Position2D = {
 latitude_deg:0, longitude_deg:0
};

var Position3D = {
parents:[Position2D],
altitude_ft:0,
}


For details check out: http://wiki.flightgear.org/Object_orien ... g_in_Nasal
http://wiki.flightgear.org/Object_Orien ... with_Nasal

So the syntax is a bit different, but the concepts are identical otherwise.

Once you have made some working experiments with Nasal and Canvas, we can add you as a committer to the "canvas-hacker" team clone, which is all about canvas related improvements, including stuff like the ND/MapStructure etc.

The main scripting space frameworks are illustrated below (this may be a bit out of date):



If you are interested in mapping/charting stuff (NDs), you'll need to understand the MVC approach taken by the MapStructure framework:


The wiki should contain quite a few pointers on things that we're hoping to work on sooner or later - so you can basically pick something you are interested in, or come up with something new.


However, if you should come up with something completely new, please do get in touch first, so that we can coordinate things a little.
Airliner/glass cockpit stuff like the PFD/ND/EFIS are currently being worked on by Gijs and Hyde - back-end stuff (generic code) is mostly being maintained by the MapStructure folks (Philosopher, D-LEON, me). Canvas specific things are being maintained by TheTom, who's also the main Canvas developer (C++ and Nasal).

Also, please don't start working on massively complicated features that cannot be currently expressed in scripting space easily, i.e. things like a moving map etc - those would be better implemented by extending the C++ code: http://wiki.flightgear.org/Canvas_Development

[drmccoy]

Again, thanks for the well structured and large reply. I'm familiar with most OOP programming concepts (including MVC). I'll go ahead and play around with the whole feature set in the coming days I think. Thanks again for the nicely and informative written info!

[Hooray]

I realize that this may seem like a lot of info to digest/process - but most of the screen shots showing maps are actually created with just a handful lines of front-end code these days - i.e. the first map is created with less than 15 lines of Nasal code while being fully dynamic - so there's a fair bit of abstraction/layering going on (through OOP) - not all of this needs to be necessarily understood to make meaningful contributions.

For example, the ND guys (Gijs & Hyde) have so far basically never touched any MapStructure stuff - even though that's what it's internally used by their code, likewise, the MapStructure guys, have rarely -if ever- had any need to touch the C++ code or the underlying Nasal bindings.

So please don't think that we know all of this stuff necessarily - there's so much abstraction behind the scenes, that there's rarely any need to understand everything at the same time.

In fact, I have contributed to Philosopher's MapStructure framework without fully understanding it too. And we have other users currently working on new features, like a Radar/ATC layer, without them ever having had a need to look at MapStructure (or even Canvas!) code.

Currently, the PFD code is non generic unfortunately - we were planning to come up with a simple animation framework for animating SVG symbols and using that in all places eventually. So that would be a relatively simple and straightforward project without having to understand a lot of existing stuff. Otherwise, mapping stuff is obviously very gratifying because the results are pretty "visual" and compelling

[drmccoy]

Don't worry. It does seem like a lot of info of course, but I'm also eager to learn more about this project. If the reward will feature more airliners with a glass cockpit, I'll be happy to help. I had a look at the wiki pages for naval MCDU and PFD, MCDU actually looks very promising already. I think I won't have many problems with the actual programming (I've been in the software development industry for years, working on some high class applications), but I'm afraid my knowledge about those instruments are very limited.

As you stated earlier however, I don't think it'll be that much of a hassle with all the documentation and example material around. Since the ND is already heavily functional and there's tutorial on how to use it, I think the first things I'm going to play with is trying to implement it into the A330 or a similar plane.

[Hooray]

Yeah, the MCDU is definitely pretty mature already - and extremely consistent, but that shouldn't come as a surprise, it was written by the same guy that came up with canvas in the first place

Most other frameworks are pretty crude and simple, put together by combining various existing features that people worked on independently - so that's why things are less elegant and less consistent there..

The ND integration steps are pretty straightforward actually, see: http://wiki.flightgear.org/Canvas_ND_Fr ... r_aircraft
Some of the instructions were recently updated and things are still a bit messy there - so feel free to edit/improve things there.
However, make sure that your work is not overlapping with other efforts, i.e. try to get in touch with the maintainers of the aircraft you are interested in working on.

A fairly self-contained project would be coming up with an animation framework using Nasal/Canvas: http://wiki.flightgear.org/Canvas_Animation_Framework
A simple framework covering most existing use-cases should be possible to write within a few weeks of spare-time coding.
Once that is in place, we would adopt that in existing wrappers (ND, MapStructure, PFD) - in fact, the ND/PFD code would be a good place to look for existing animation scenarios.

Instrument knowledge is indeed a bottleneck, but Gijs,Hyde and others are typically adding features based on downloaded copies of real aircraft manuals, and replicate features that way.
Based on my involvement in the ND/MapStructure efforts, it seems pretty safe to say that aircraft developers can easily add such features once they have some kind of framework in place.
But in general aircraft developers tend not to optimize things in terms of generic designs, i.e. reusability and framework-level design concepts.
So that's where having more programmers involved could actually be helpful - as can be seen in navdisplay.mfd, there's a fair amount of non-generic code added to the update() method, even though there's a framework in place already - so we probably need to document things better to make the design more self-explanatory.

This thread should have enough pointers to get you started on the right track - if you find yourself having to "drop the ball" for a while, I'd suggest to document your plans using the wiki - that's how projects survive despite people having to take a hiatus every once in a while