Board index FlightGear Development Aircraft Cockpit development

Why are cockpits so integrated with planes?

Discussion about creating 2d and 3d cockpits.

Re: Why are cockpits so integrated with planes?

Postby Hooray » Tue Jan 28, 2014 10:56 pm

KL-666 wrote in Tue Jan 28, 2014 10:18 pm:Where are the people that take pride in the "invisible" work? I do in my job, i work on back-ends, so no-one sees anything flashy. Me knowing it is flashy is enough to me. Others just notice that it is not slow and easily maintainable by other programmers. That is enough applause for me.


There are many opportunities for people with this sort of background to get involved in the project and help with such "invisible" things - in fact, even non-programmers could help by maintaining XML files and ensuring that these don't end up being messy, especially due to the pseudo-programming constructs meanwhile supported by many PropertyList-encoded files.

Thus, you don't need to know C++, C or Nasal in order to be useful to the project.
For example, Philosopher's MapStructure work is virtually invisible to people using his code, but it makes the ND stuff much more efficient. Galvedro's work improves instrument design quite a bit and provides a more flexible architecture. Neither of these things are visible to end-users.

It's not that other contributors don't refactor or optimize code, but most people tend to adopt some feature/code and focus on that, such as FDMs, AI traffic, the GUI or the autopilot system - and rarely, if ever, touch other parts of the code base to refactor things over time. For example, Stuart recently improved performance of some of his code.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11309
Joined: Tue Mar 25, 2008 8:40 am

Re: Why are cockpits so integrated with planes?

Postby hvengel » Tue Jan 28, 2014 11:23 pm

Hooray wrote in Tue Jan 28, 2014 12:49 pm:...I would be really surprised if anybody looking into this, shouldn't come to the same conclusion - once you look into aircraft that have little or zero Nasal code, things are usually straightforward to "remap".


I would go even farther. Most aircraft that don't have Nasal code involved in cockpit related interfaces will tend to be using standard predefined properties to interface with the typical cockpit components like the airspeed indicator or manifold pressure gauge. No remapping should be needed for any for these common components. Where things would need remapping is when there are no standard/predefined properties in the tree for a particular component and the aircraft dev, out of necessity, adds aircraft specific properties to the tree. Remapping shouldn't be difficult for these but depending on what the dev did these could be almost anywhere in the tree and only the aircraft dev is going to know what these are and where they are located without digging around in the cockpit related XML.

If there had been guidelines for how this should be setup (IE. how the tree should be structured for these aircraft specific components) it would make remapping/restructuring of this easier and maybe even doable with some type of automation. Unfortunately that ship sailed a long time ago and I think that it is really up to those who are maintaining the existing inventory to rework/update cockpits if such standards/guide lines are put in place.

On the other hand I agree that having some kind of "panel builder" GUI could be very useful to those who have not already built advanced cockpits and might encourage those who have less advanced cockpits to at least get basic instruments into their aircraft. I also don't think it would be that hard to put together this kind of utility along with supporting documentation. If a sufficiently large library of instruments and other cockpit components where available many aircraft would only need a few custom/aircraft specific components and building the more generic parts of the panel would only take a few hours to a few days, depending on the complexity of the aircraft, with this type of utility.

I also think that this would be facilitated by encouraging aircraft devs to to put any existing non-aircraft specific cockpit components into one of the shared instrument directories to encourage greater reuse of these components. There are a number of these instruments/devices in the P-51D cockpit that could be moved to Aircraft/instruments3d that could be used in a wide range of WWII aircraft. It is also highly likely that other WWII aircraft have their own versions of the same devices. Some of these may actually be better than the ones in the P-51D so it might make sense to try to find and then standardize on the best available examples of any given device. My guess is that if we combed through the existing aircraft inventory we would find a huge number of reusable cockpit devices that could be added to Aircraft/instruments3d or some other shared location.
hvengel
Retired
 
Posts: 1128
Joined: Sun Dec 24, 2006 4:35 am
Location: Minden Nevada

Re: Why are cockpits so integrated with planes?

Postby Hooray » Tue Jan 28, 2014 11:36 pm

Well, we do have a few corner-cases were even the old "pure XML" approach caused some workarounds and weird naming conventions - but overall, it really is the flexibility provided by Nasal, and extensively used by aircraft developers, that complicates the whole matter - i.e. "systems" being modeled in scripting space without having any well-defined interface, and without following protocols that are used and enforced by existing C++ code. Note that I am not saying that Nasal is generally bad, but the way people have been using it, is causing quite a bit of work when it comes to maintaining things in the long run.

A simple GUI would be possible, even with existing means - and we could teach it to load/edit/save existing instruments. Identifying existing components that should be moved to the global directory may require some pretty tricky/sophisticated heuristics though.

Originally, David Megginson actually mentioned on the devel list that he envisioned a design where instruments would explicitly define their inputs and outputs via XML markup using some form of typing/units system, so that they could be plugged together with other systems, honoring types as appropriate (heading/azimuth, voltage, ampere etc).

galvedro mentioned that he will be looking into a refined systems modeling framework shortly, so maybe things won't be as bad in 3.2 :D
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11309
Joined: Tue Mar 25, 2008 8:40 am

Re: Why are cockpits so integrated with planes?

Postby KL-666 » Tue Jan 28, 2014 11:53 pm

Hooray wrote:

Note that I am not saying that Nasal is generally bad, but the way people have been using it, is causing quite a bit of work when it comes to maintaining things in the long run.


From my purist standpoint i would say, if code allows for misuse, it is not good.

Also i noticed that some people try to pull me in the project. I know of myself that if i do, i get fully involved and take on the complete project. For sanity's sake, i better stay at some distance and just do some plane testing and inspiring for some programming ideas.

Kind regards, Vincent
KL-666
 
Posts: 784
Joined: Sat Jan 19, 2013 1:32 pm

Re: Why are cockpits so integrated with planes?

Postby Hooray » Wed Jan 29, 2014 12:04 am

KL-666 wrote in Tue Jan 28, 2014 11:53 pm:From my purist standpoint i would say, if code allows for misuse, it is not good.

There are quite a few people who manage to write good and clean Nasal code, just look at TheTom's canvas modules for examples, or any of Philosopher's code.
But obviously that's a matter of expertise.
And there's basically no entry barrier involved when it comes to writing Nasal, it's a dynamically typed scripting language after all.
So really easy to get started - people able to read/write and understand more difficult programming languages (C, C++, assembly, bytecode) have obviously had more exposure to programming than people who really only got into programming due to FlightGear and Nasal. So it isn't quite fair to attribute a misuse of the language to Nasal itself.
Otherwise, you would need to replace Nasal with some dialect between Ada/SPARK dialect.
There's is no way in Nasal to enforce certain coding patterns, there's basically not even proper encapsulation possible, i.e. in the form of public/protected and private access known from C++ or Java.
You cannot expect to do large-scale systems programming in such a language, and that wasn't really the point.
To avoid misuse, you would need to introduce DbC or other patterns - while tedious, it would be possible, but at that very instant, we would lose roughly 90% of the people who currently contribute through Nasal coding. It's really not that we don't have any expertise here, there are quite a few people here, who are capable of writing "good" code, regardless of the language being used - but we don't have too many people able/willing to adopt such "best practices" - for understandable reasons, a CS degree takes roughly 3-4 years to complete - you cannot expect to teach or learn everything in just a few weeks of spare-time coding while contributing to an OSS project like FG.




Also i noticed that some people try to pull me in the project. I know of myself that if i do, i get fully involved and take on the complete project. For sanity's sake, i better stay at some distance and just do some plane testing and inspiring for some programming ideas.

there are countless ways to get involved, without sacrificing all your spare time - while still contributing your expertise.
As long as you don't commit directly, there's also a natural barrier to entry involved - because not all of your stuff ends up in the repository, and because reviews are getting increasingly throrough.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11309
Joined: Tue Mar 25, 2008 8:40 am

Re: Why are cockpits so integrated with planes?

Postby KL-666 » Wed Jan 29, 2014 12:33 am

Hello hooray,

Your nasal argument is valid, but for how long? A startup wants to get some quantity body. So get me as many planes as possible, no matter the quality of the plane or the quality of code. But if you get at some 100 horsedung quality planes, then the organization should shift from quantity to quality. Then emphasis should shift from no code quality at all, to imposing requirements to implement certain interfaces. And if nasal can not deliver interfaces, it should be changed or replaced to do so.

We can not go on for ever in the startup mode: the more planes the merrier, no matter the quality of code.

Kind regards, Vincent
KL-666
 
Posts: 784
Joined: Sat Jan 19, 2013 1:32 pm

Re: Why are cockpits so integrated with planes?

Postby hvengel » Wed Jan 29, 2014 12:34 am

Hooray wrote in Tue Jan 28, 2014 11:36 pm:...galvedro mentioned that he will be looking into a refined systems modeling framework shortly, so maybe things won't be as bad in 3.2 :D


System modeling is a big issue particularly for YASim aircraft where Nasal is about the only option and there are no standardized frameworks.

JSBSim aircraft can model most systems directly in the FDM using standard JSBSim constructs but it can be very difficult to do and it typically requires many layers of functions, switches and other hand built JSBSim XML components. These systems tend to be very abstract and can be hard to understand and maintain and in many cases were more or less created in a ad-hoc manner. So it would be really nice to have a set of systems modeling frameworks for JSBSim FDMs that could be included in the FDM and then configured in a simple way. For some aircraft it is actually possible to get things like electric and hydraulic schematics (this is true for many WWII aircraft for example) and in a ideal world it should be possible to feed a schematic into a utility then map various FDM devices to the schematic and have it dump out a working system for the aircraft.

One other related issue is that sometimes the built in stuff is just missing things that should be there by default. For example, the JSBSim piston engine stuff is very air cooled centric and there is no way to get it to do a full liquid cooled simulation without some user supplied extensions. Because of this it is necessary for the aircraft dev to "fake" some things. One example is setting up a way to get a liquid coolant temperature, all the engine model gives you is the cylinder head temperature for an air cooled engine, so that this can be displayed on the coolant gauge. I have this working in the P-51D FDM and getting this working in a reasonable way was a significant amount of work (several days of tweaking and testing). It seems like we should already have a basic set of JSBSim XML that does this type of thing for aircraft that are liquid cooled so that everyone working on these FDMs could just paste or include the code and perhaps do a few tweaks to have a working temperature gauge (to get this back to cockpits). I sometimes wonder how many times that particular wheel has reinvented although I suspect that there are a number of liquid cooled JSBSim FDMs that have (perhaps modified) copies of the P-51D code.
hvengel
Retired
 
Posts: 1128
Joined: Sun Dec 24, 2006 4:35 am
Location: Minden Nevada

Re: Why are cockpits so integrated with planes?

Postby Hooray » Wed Jan 29, 2014 1:24 am

@KL-666:

well, aircraft quality is not a function of scripting language features - in fact, Nasal provides many more features than are being used by 99% of its users, including core developers - to see what is possible, just look at some of the code written by people like mfranz, AndersG - or more recently Philosopher. We have people here who have written massive amounts of Nasal code, who still stand no chance understanding what's going in code that was written using meta-programming techniques.
So it's really not so much a lack of features, but rather a lack of understanding by people using it.

Entirely replacing Nasal also is not straightforward - quite a few people have discussed this over time (see the archives), and some of them really familiar with the internals of the project, but also with the type of Nasal use in FG.
Also, replacing Nasal with something else would be of very little use.
Still, there are people looking into this and considering this step at some point... personally, I don't see that happening within the next 5 years (at least) - simply because at that point, HLA is going to become increasingly mature - and then, it no longer matters what language you are using as long as it has HLA bindings, i.e. you could use Python, Ada or Java - it would no longer matter. But that will obviously cause new challenges for the project, because FG may end up being "too partitioned", and requiring too many different runtime environments (think python, lua, jre etc)

Thus, it would be a much more natural step to simply use cppbind and provide HLA bindings for Nasal, so that we can run existing code outside the fgfs main loop.

Extending Nasal to make it stronger, and more strict, would be possible - but at the cost of making it more difficult for people to use it.
Extending it would not even be very difficult, we now have a handful of people here who understand the internals of the Nasal engine fairly well, thanks to work that Philosopher has done (see $FG_ROOT/Docs/nasal-internals.pdf)

We could come up with restricted modes that enforce certain "best practices", either through Nasal-space interfaces using metaprogramming, or by coming up with a DSL for certain well-defined tasks, such as instrument modeling - that would provide all the flexibility needed, without sacrificing Nasal.

Like hvengel said, even JSBSim suffers from a lack of expressability at times - and at least there, Nasal is generally not considered a viable solution.

A while back, some core developers were considering to add a dedicated systems modeling component to FG, i.e. in the form of "SPICE".
You can probably find a few related discussions, i.e. see: https://www.mail-archive.com/flightgear ... 27607.html

The point being, we cannot keep on reinventing the wheel - Nasal itself is already very much a niche language.
But thanks to TheTom's cppbind work, exposing new C++ systems to Nasal has become pretty straightforward.

So I guess that's something that would be worthwhile to reevaluate - but overall, the whole debate is kinda academic obviously, because you are just making generic claims and requests without necessarily contributing to the solution of the real problem. And thus, my responses are kinda pointless, too ...
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11309
Joined: Tue Mar 25, 2008 8:40 am

Re: Why are cockpits so integrated with planes?

Postby KL-666 » Wed Jan 29, 2014 1:52 am

Hooray wrote:

So I guess that's something that would be worthwhile to reevaluate - but overall, the whole debate is kinda academic obviously, because you are just making generic claims and requests without necessarily contributing to the solution of the real problem. And thus, my responses are kinda pointless, too ...


I disagree on the academic part. Some people that are involved in fg code might be inspired. As i explained before, i myself for now wish to stay aside, which in itself does not make any remark more academic. With or without contributing to software, there can be truth in certain knowledge shared. I really do not see any good use of resources in propositions like: Oh well do it yourself in some plane. What is the use, if a whole project goes in some (any) direction? Do not fix a part if the system is broken. The part will break soon again due to the broken system.

If there were a chance to fix the system, i might be inclined to get involved. But everyone in fg denies that there is a system.

Kind regards, Vincent
KL-666
 
Posts: 784
Joined: Sat Jan 19, 2013 1:32 pm

Re: Why are cockpits so integrated with planes?

Postby Thorsten » Wed Jan 29, 2014 6:38 am

But if you get at some 100 horsedung quality planes, then the organization should shift from quantity to quality.


What organization? There is no central authority which can tell people what direction to go - FG is a body of volunteers self-organizing by discussion, exchange of information and merging work from different areas. You're as much the 'organization' as I am.

The only way you can make progress is to either convince people or just go ahead and do something. After persistent nagging and long discussions, we now have a rating system for aircraft where we had none before. It's not perfect, but it's better than nothing and something to build on. If you think it's important, take charge of it, double-check self ratings of developers, bug people, make sure it's accurate.

But complaining that others should do it because it's important to you is cheap. We work by our own priority lists (which tend to be overfull).
Thorsten
 
Posts: 10531
Joined: Mon Nov 02, 2009 8:33 am

Re: Why are cockpits so integrated with planes?

Postby galvedro » Wed Jan 29, 2014 8:09 am

One of the main developers at LaminarResearch (XPlane) recently published an interesting post that is very related to this quality filtering thing.

A bit of context: XPlane has traditionally managed its airport layout database as an open source project where everybody could send data updates. The same database is used by FG, actually. Now, they are extending the idea to be able to populate those ground layouts with buildings, so there is a debate on how to manage the quality of those contributions. Sounds familiar? :D

http://developer.x-plane.com/2013/12/airport-authoring-sharing-airports/

I think it is interesting because it shows how a commercial product that does not have an army of paid workers is approaching essentially the same problem. An open source project survives from contributions, which means that it will be alive as long as there are contributors that keep an interest in updating the project. Quality is of course desirable, but it is not a requirement for survival. But these guys live from sales, which means that they are actually committed to delivering quality to the end user and make them happy. And you know what? They still think it is beneficial to be open and accept contributions as they come, even when they might not be as good.
galvedro
 
Posts: 145
Joined: Mon Oct 07, 2013 12:55 pm
Location: Sweden

Re: Why are cockpits so integrated with planes?

Postby Hooray » Wed Jan 29, 2014 1:13 pm

KL-666 wrote in Wed Jan 29, 2014 1:52 am:I disagree on the academic part. Some people that are involved in fg code might be inspired. As i explained before, i myself for now wish to stay aside, which in itself does not make any remark more academic. With or without contributing to software, there can be truth in certain knowledge shared.


Show me the "knowledge" that you shared with us, that we didn't have already. Please don't think that all of us don't have a programming/CS/SE background - this may apply to many/most aircraft developers, but people contributing to the coding side of the project are usually pretty well aware of the required knowledge, many having at least a master's degree and some even PhDs.

And what you have "shared" with us so far is not really new or even helpful to be honest. Thus, the debate is very much academic. Many of us have been in your shoes, thinking that we shared "certain knowledge" and that this should suffice - just do a forum search, you will find core developers telling me that they felt I was "lecturing" them - so it didn't do any good, until I prototyped at least a proof-of-concept. We have a million of great ideas in the archives - 90% of them much more informed than yours, i.e. coming from long-time contributors with the required knowledge.
There's very little need for inspiration through suggestions actually - as sad as it may sound, the only currency valid here is your time, i.e. the time spent contributing to the project, in whatever form.
In fact, Gijs recently started deleting quite a few wiki articles which had lists of ideas, along with "knowledge shared by others".
the project doesn't work like this - even though I do agree that it would be great if this were not the case.
Just go and ask Thorsten how much people have "shared knowledge" with him regarding his advanced weather system, and ultimately none of this ended up affecting the system, unless it happened to be specific and useful - as in polly's contributions, or Stuart's and Torsten's work.

We have roughly 95% ideas and knowledge - and only 3-5% of them actually end up being implemented.



If there were a chance to fix the system, i might be inclined to get involved. But everyone in fg denies that there is a system.

that's one of the most common excuses we've been seeing here over time, people saying that they won't get involved UNTIL X/Y/Z is fixed accordingly.
Imagine this for a second: I made the exact same bold statement in early 2000 on the devel list :D
In over 5 years, I have never seen any of those making such claims actually get involved once the corresponding change has happened, including myself.
Thus, Thorsten is absolutely right.

The problem is that there really is no such thing as a system - unless you accept that you are one important part of it ALREADY - once you figure this out, you have grasped how the project works, and to change the system - i.e. by changing yourself, and behaving accordingly.
There's no difference between you, myself or others - you are just as much part of the system as all of us are.
Look at some of the very first postings we made here (people with >= 2k posts) and you will see that we went through the same thing.

For some reason, being the change I wanted to see, works out rather well for me - admittedly, I hardly get to work on a single project any longer, but I am usually involved in 6-10+ different projects and actually see them make progress, and people keep telling me just how beneficial it is to have someone support them early on.
In fact, there are now 3-5 guys emulating this behavior, and they're having the same experience.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11309
Joined: Tue Mar 25, 2008 8:40 am

Re: Why are cockpits so integrated with planes?

Postby psadro_gm » Wed Jan 29, 2014 5:38 pm

Reading recent posts to these threads makes me smile. It's been 3 1/2 years since I joined the forum after maybe 6 months of playing the sim. I came from MS FSX, and was disappointed with the scenery. I decided it would be nice to have textured roads instead of the plain boring asphalt. That's all I wanted to do.

Being naive, I figured it was just a matter of creating a better texture and applying it to the road polys. I was disappointed to learn that the texture always pointed north, regardless of the road direction. Very few people were involved in the scenery tools anymore (I started studying up on terragear right after Ralf Gehrlich moved on). Long story short, after 4 attempts at adding texture coordinates that would actually follow the road direction, we've finally used these tools to generate the world scenery 2.0. And guess what - we didn't texture the line data ( it will require a bit more work to keep framerates on older hw from plunging, with so many textures / polys in OSM data ).

The point is, If you feel something is poorly designed, and should be done differently, go ahead and try to improve it. If others can be convinced of the merit, it most likely will become the 'new way'. So many examples of this in the past 4 years of development.

advanced weather, random buildings, Rembrandt, ALS, canvas and OSGEarth. These are features that at one point, someone said - I wish FG could do xxx. Then, they sat down, and figured out HOW FG could do it.

I also really liked the single player mode ATC in FSX - I'd love to work on that, as well. Currently, I'm completely clueless where to begin. I know the feature somewhat collides with multiplayer ATC, so I'm not sure what kind of reception such a system would have. I'm also short on time, and still have lots of scenery bugs to work on. It's likely that I'll never get around to it. But I'm quite sure that if someone new to the project felt strongly about it, they may go off and do it. I would encourage them.

Pete
8.50 airport parser, textured roads and streams...
psadro_gm
 
Posts: 750
Joined: Thu Aug 25, 2011 2:23 am
Location: Atlanta, GA USA
IRC name: psadro_*
Version: git
OS: Fedora 21

Re: Why are cockpits so integrated with planes?

Postby Stiglr » Wed Jan 29, 2014 6:50 pm




Something like this would be GREATLY appreciated, even if it usually failed in an attempt to generate a "decent quality aircraft". If it only generated some color-coded lines in the resulting files that pointed out the holes that were missing good data, it would be worth the investment in time and energy to create it. At the very least, a novice or code-phobic user (guilty as charged here!) would have an idea of what types of data he/she were missing, where they were in the file structure (don't underestimate the importance of this!!!) and following a little steerage or advice as to what "types" of expertise he might need to drag into the project to move it forward.
Stiglr
 
Posts: 67
Joined: Thu Nov 03, 2011 3:53 pm

Re: Why are cockpits so integrated with planes?

Postby Hooray » Wed Jan 29, 2014 7:00 pm

You do have a point, we take many things for granted that are easy to miss, because we may have certain experience or because we may know where to obtain certain info. So a fresh set of eyes could be helpful.

If you would be interested in helping with this, i.e. via feedback, usability hints etc (NOT coding!) - just get in touch, we have currently 3 people helping with coding, one of them familiar with aircraft development. It's currently just a rough prototype, but it could certainly be improved upon in time for the 3.2 release cycle. Currently, it's not much more than a template-based stub generator, that fills in some fields, based on user input. But it is already a "GUI" tool, i.e. more straightforward to use than a text/xml editor (well, for newcomers).
It would obviously be helpful if you are able to run FG 3.0 to test this and provide feedback - installation-wise, it's just about dropping a single file into the data package (FG_ROOT) - eventually, it may comprise extracting a zip file ...
I would just suggest to keep feedback simple and straightforward - we all do agree that having a dedicated "aircraft/cockpit designer" would be awesome, but it's gonna happen over night - we need to walk before we run, and explore the boundaries of this first. Extending it is simple enough, even without any coding experience - it currently involves just editing a text file that generates new wizard pages and fields.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11309
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to Cockpit development

Who is online

Users browsing this forum: No registered users and 0 guests