Comparable Aircraft Models

[Wetted Area]

Aircraft Model Design, Accuracy & Integration

 

Hello All:

 

Thanks for helping to get me up to speed on how X-Plane handles flight dynamics.  I really appreciated the help on that front.    This next topic is one that I have seen posted before, but not in the way that I need to focus on the issue right now.

 

In many sim forums, I have noticed that when people discuss "Aircraft Models" they often times illuminate over their most favorite aircraft with warm and fuzzy language to discribe things like how "knobs turn so realistically," or how the "amber glow of the cockpit at night seem so ethereal," or how much the aircraft on screen "looks so much like the real thing."  However, that's nice - but that's not why I'm posting this particular thread. 

 

What I'm trying to understand is encompassed by three (3) large areas:

 

1) Who are the Aircraft Modelers

2) What do they know about Aircraft Modeling to Scale

3) Where do they obtain Planform & Geometry information for the Aircraft Model

4) How are they integrating the Aircraft Model Functions into the Flight Simulator

 

I hardly ever see discussions about the size of the rudder within the model and how precisely it was scaled-up from a two dimensional drawing without distorting the aspect ratio of the original design, as just one of a hundred different examples of what I typically don't see being discussed very much - or to much depth.

 

I know we've been discussion Flight Dynamics up until this point in the other thread.  I'd like to shift into at least some detail about Aircraft Models, how they are constructed and who is ultimately responsible for making certain that the aircraft is correctly sized (for example) and that its specific geometry is specified correctly.  Of course, this is another example of garbage-in-garbage-out.  I've read threads on forums where people were reporting incorrect aircraft geometry in everything from wing size, flap size, angle of incidence, aileron size, area rule, airfoil camber, aircraft length, etc, etc, etc.

 

In X-Plane, I would think that such design problems would present a significant problem for would-be aircraft modelers, given the approach that X-Plane takes to flight dynamics and how it ges about modeling it.

 

I see some of these videos of people taking 2D 3-up drawings of aircraft (I don't know where they obtain the drawings exactly), importing them into applications such as Sketchup and then literally stringing together a partial "frame" of the aircraft before they apply the geometric (fitted) shapes, contouring, textures. etc.  I then assume that they are saving the file as something that would be recognizable by FSX and X-Plane.  But, I do not know (yet) how they are getting actual integration between the model they just created in the 3D application and the Flight Simulator itself (aileron, flap and rudder movement; flight control actuation; landing gear actuation, etc.).

 

I'm not looking to build my own models (I hope), but I do want to understand who's building them, what they understand about such matters, where they obtain baseline data points for their 2D outlines or where are they obtaining the 3D models they start with and what understanding they have about aircraft mode shapes (geometry), planform, aspect ratio - I mean, there is a lot to know and discuss.

 

This is all predicate upon the assumption that when you develop an aircraft model and drop it into FSX or X-Plane, that the Flight Simulator is responding to the model's "physical" attributes as described somewhere (I don't know yet) inside the aircraft model's files and then uses that information to makes its flight dynamics projections  - as opposed to the Flight Simulator simply attaching its own idea about what the aircraft's geometry should look like and then forcing its own flight dynamics base on its assumptions of what it thinks it sees in the model.  I hope that makes sense.

 

Let me know if this is the right forum and/or the correct thread for this type of discussion, please.

 

Any help in this area is greatly appreciated as well.

 

Thanks! 

[guym-p]

I am one of the aircraft modellers.

 

What I like most about X-Plane, the quality that drew me to it in the first place, is how accessible all the modelling tools are.  They do not require any programming skill, and someone with virtually no knowledge can build an aeroplane straight away.

 

This is a double-edged sword, of course, because there is no guarantee that an aircraft you see available as a download has any real accuracy or authenticity. Models can range from something which is a bit of fun: a toy, to obsessively researched and painstakingly detailed facsimiles of the real thing.

 

However, to criticise the toys would be to miss the point about X-Plane.  I use both X-Plane and FSX.  I regard FSX as much more of a "user" oriented platform, where X-Plane is for people who enjoy rolling their sleeves up and having a go themselves.

 

This is where the fundamental building blocks of X-Plane comes in.  It calculates aerodynamic forces based on the actual shape of an aircraft.  If it's no good, it won't fly.  Therefore, as well as getting a huge amount of pleasure out of it, by building one aircraft, the modeller will almost certainly have had to troubleshoot and solve some handling vice or other, and, gradually, we all learn.  I always think X-Plane's value as an educational tool should be broadcast more effectively.

 

So, to answer your questions in order:

 

1) Who are the Aircraft Modellers

 

They could be anyone, or all of us.  Some aircraft modellers are building and publishing their first model, with no previous aeronautical experience; while at the other end of the scale, there are modellers who have been at it for a serious amount of time, or real engineers enjoying a "busman's holiday".

 

2) What do they know about Aircraft Modeling to Scale

 

Perhaps nothing, to start with.  X-Plane is very much about learning by doing.  Engineers, people with a technical background, or who just have an interest in engineering, will know about or take to scale modelling.  Anyway, engineering is only part of it.  The greatest amount of effort (in hours spent) is on 3D graphics, and a lot of X-Plane modellers are artists with an aptitude for engineering, rather than the other way round; or programmers with an interest in both.

 

3) Where do they obtain Planform & Geometry information for the Aircraft Model

 

Some aircraft have information and drawings that are widely available on the internet, some don't.  There are web sites that have tried to collate such information, but they don't have everything.

 

It is possible to find flying manuals, technical manuals, even repair manuals for most aircraft.  However, it is not necessary to know the precise height of the rudder to fly the aeroplane.  Even for maintenance, the manuals might only define the maximum play or backlash before the component needs to be stripped for repair.  Manuals will usually include a set of crude exterior projections with overall dimensions, and some components may well be drawn in detail, but not all.  What they are extremely good for is the precise location of CG, for explaining and illustrating how the aircraft and systems function, and actual flight performance, often in extraordinary detail, with which to compare the model.

 

It is possible to obtain detailed drawings from manufacturers, but (from my own experience) you need to know the drawing number in order to check it out of the manufacturer's archive, which requires (at the very least) an illustrated parts manual, and you won't be able to take it any further than to spread it out on a table in the archivists office.  General arrangement drawings (which is closer to what the modeller actually needs) are usually vast, and impossible to copy.

 

It's better, and a far more practical proposition, to look for aero-modellers plans.  Then to correct or enhance those plans with hard facts from manuals, and one's own observations, measurements, and photographs (often hundreds) of the real aircraft.

 

It's also important to understand that, although X-Plane functions a bit like a virtual wind-tunnel, even the most sophisticated industry models can not simulate real world physics with total accuracy.  X-Plane has to be able to run at reasonable speed on a typical PC or Mac.  Therefore there will be simplification, not only in the scenery you see through the windscreen, but also in the aerodynamic calculations.  Part of Austin Meyer and Laminar's skill is in choosing what to do in detail, what to simplify, and what to leave out altogether.  Therefore all models will involve some interpretation, or artistic license, to get them to perform well.

 

To use your rudder analogy, perhaps the rudder of an aircraft in X-Plane must be slightly larger than in real life, in order to compensate for a dorsal fin not being part of the aerodynamic calculations.  An arbitrary example, but those are the kind of issues that come up.

 

Computers get faster all the time, allowing more computations per second.  Therefore as they get better, so X-Plane develops and expands, and we can improve our aircraft.

 

4) How are they integrating the Aircraft Model Functions into the Flight Simulator

 

This works on two levels: a functional level and a cosmetic level.  The cosmetic level will be handled by animations for the 3D graphics.  This requires a lot of research about how the real aircraft's components moved or worked.  It's great fun.

 

To understand how developers make things function, I must explain another difference between X-Plane and FSX.  X-Plane gives the developer much more in terms of existing systems.  In FSX, a developer has to design a gauge and the programming logic to go with it.  In X-Plane, the outputs to waggle the needles of most flight gauges realistically is already there, including a number of interesting and exciting failure modes.  If Laminar improve the realism of that gauge, all aircraft using it benefit automatically.

 

So, when creating a simple aircraft, with analogue gauges, a modeller can simply draw from existing functions: there are "datarefs", which translate inputs, such as joystick movements, and outputs to waggle ailerons or gauge needles; and "commands" for most button clicks.  That makes it sound easy: believe me, there is still a lot of work, research and understanding to do it well.  The tools X-Plane, Plane Maker, Airfoil Maker, etc arm you with are like opening a box of lego.  The developer still needs knowledge and imagination to build something good out of it — but it is much, much easier to develop for X-Plane than for FSX.

 

With sophisticated aircraft, modellers might be more ambitious, and the basic set of datarefs and commands might not be enough.  Then the developer will have to start programming, and there is a software developers kit for X-Plane, as there is for FSX.  Potentially, the only limit is the developers imagination and the time they're prepared to spend on it.

 

This has been a long and somewhat waffly answer with few specifics, but I hope it serves as a broad overview.  I am sure many developers will pick up on some of the points, and agree or disagree vehemently!

 

Without wanting to repeat the disaster on the .Org, I am actually going to echo one of their constant refrains, which is that a lot of your questions sound as if they are written by someone still paddling at the edges.  I fully appreciate that you can only devote so much time, and you want to make the right choice of simulator, but the answer to a lot of your questions will become obvious when you have a go.

 

Guy.

[Wetted Area]

Hello Guy,

 

That was a pretty amazing post to say the least.

 

Yes.  I am wading into the desktop flight sim world slowly for the reasons given in another post on this forum.  I have nothing against gamers.  But, as you probably know by now, my interest in flight simulators is somewhat different.

 

Safety, will be my main goal and one of the ways that I can maintain safety is by remaining current at all times, even when I don't have time, or physically am unable to get to the airport.  So, I am carefully evaluating multiple paths for flight simulation for some good reasons.  Safety, proficiency and efficiency, are my ultimate goals and one of the ways to get there is through the repetition of good habits based on as accurate a model of simulation as possible, for a PC.  So, that's what this is all about for me personally.

 

Given your well written and well thoughout reply, I only have a few follow-up questions to ask, if you don't mind.

 

This is a double-edged sword, of course, because there is no guarantee that an aircraft you see available as a download has any real accuracy or authenticity.

 

Can you 'name names' for the following aircraft models, of people, or an online business entity that produce the most accurate aircraft models for use in X-Plane 10.11:

 

- Single Engine Land w/conventional instrumentation (retractable or fixed gear, high or low wing)

- Multi-Engine Land w/conventional and G1000 EFIS

- Multi-Engine Land Turbo-Prop w/G1000 EFIS

- Phenom 300 and/or Mustang II w/G1000

 

Having the models be as accurate as possible for a desktop computer simulation, obviously aide in the ability to practice good habits related to memory work and procedures.  If you feel uncomfortable 'naming names' in this thread, but you do have some opinions about who should be on that list and don't mind sharing it with me, please contact me at: wettedarea7@yahoo.com. 

 

Any information you reveal to me about who you believe to be "the absolute best" in this collection of various aircraft types and categories, will be held in strict confidence and not repeated and/or disseminated by me in any way, shape or form.

 

This is where the fundamental building blocks of X-Plane comes in.  It calculates aerodynamic forces based on the actual shape of an aircraft.  If it's no good, it won't fly.

 

Or, maybe it will fly, but fail to fly according to the manufacturers published performance limits.  This may, or may not be that important to a pure Gamer, if the purpose is to just have fun.  But, if the intent is to produce the potential for simulating actual procedures via memory patterns established by the operational requirements of a particular aircraft make/model/type/category, then it does become a rather important requirement to have available to you, an aircraft model that X-Plane can actually simulate within a reasonable approximation of specified OEM limits.

 

I really thank you for clarifying this part for me.  I'm familiar with how real world flight dynamics work.  And, I'm familiar with how real world aircraft development works.  What I did not understand is how X-Plane and Aircraft Modelers go about simulating that world.  I did not know if X-Plane simply took over the simulation and presented on screen its own definitions of the inputs coming from the end-user.  Or, whether or not X-Plane was truly rendering the actual simulated results from aircraft geometry and flight control surfaces that come from real world aircraft specifications.  So, again - thanks for reinforcing that which I have already discussed with another very helpful member of this forum.

 

 

2) What do they know about Aircraft Modeling to Scale

 

Perhaps nothing, to start with.  X-Plane is very much about learning by doing.  Engineers, people with a technical background, or who just have an interest in engineering, will know about or take to scale modelling.  Anyway, engineering is only part of it.  The greatest amount of effort (in hours spent) is on 3D graphics, and a lot of X-Plane modellers are artists with an aptitude for engineering, rather than the other way round; or programmers with an interest in both.

 

3) Where do they obtain Planform & Geometry information for the Aircraft Model

 

Some aircraft have information and drawings that are widely available on the internet, some don't.  There are web sites that have tried to collate such information, but they don't have everything.

 

It is possible to find flying manuals, technical manuals, even repair manuals for most aircraft.  However, it is not necessary to know the precise height of the rudder to fly the aeroplane.

 

So, this entire segment really caught my attention for some obvious reasons, I hope.  So, if you don't mind, let's drill down on this just a bit.  We can approach this from a number of different perspectives, but I'll try to keep this down to just one: Aspect Ratio. 

 

AR ~ b²/S

 

If you take a look at drag coefficient formulations, you will note that aspect ratio is a prominent driver of the resultant performance of the vehicle.  It is not the only factor, but it is one key factor in resultant aircraft behavior.  Changing this ratio and then plugging it back into a C_d formula, will net a different result each time.

 

Using our resident "Rudder" example (thank you for actually reading this stuff), we can obtain not only differential moments with variances in rudder AR, but in doing so, you will also obtain different handling characteristics which alters the total performance envelope of the aircraft (or, has the potential to).  And, this is just one of many different Geometric Variables that impact Planform.  There are many others.

 

So, my question is this --- Since X-Plane takes the geometry of the model and renders aerodynamic performance based on that; if the Modeler makes a change in the aircraft's original planform design when going from their 2D 3-Up Technical Drawings to their 3D renderings, what tool do they use for performance impact analysis that lets them know which characteristic behavior of the aircraft has changed and what they need to do about it, in order to bring the aircraft back into conformity, so that when I jump into the cockpit and launch down the runway, I ultimately get something that approximates the actual range of POH performance specifications -and- so that I don't inadvertently fly the aircraft outside its design limits (either above or below those limits) because the Modeler's changes to the geometry caused a significant difference in the expected behavior -vs- the actual behavior during the simulation?

 

 

It's also important to understand that, although X-Plane functions a bit like a virtual wind-tunnel, even the most sophisticated industry models can not simulate real world physics with total accuracy.  X-Plane has to be able to run at reasonable speed on a typical PC or Mac.  Therefore there will be simplification, not only in the scenery you see through the windscreen, but also in the aerodynamic calculations.  Part of Austin Meyer and Laminar's skill is in choosing what to do in detail, what to simplify, and what to leave out altogether.  Therefore all models will involve some interpretation, or artistic license, to get them to perform well.

 

I can definitely appreciate that  - thank you.  The one question I have here, is with respect to last six words: "to get them to perform well."

 

Does that mean to get them to "look" as if they are performing well on screen, or does that mean to get the aircraft being simulated by X-Plane's engine, to produce performance results (take-off, climb, cruise, descent, landing, roll-out) for a given set of atmospheric variables (density altitude, temperature, surface winds and winds aloft), that are as realistic as possible for a PC or Mac?  In other words, can you rely on the simulation to a reasonable degree (I understand it won't be on the dime every time) on any long range flight planning factors such as Range & Endurance, Climb & Descent Rates, V-speeds, etc.

 

 

So, when creating a simple aircraft, with analogue gauges, a modeller can simply draw from existing functions: there are "datarefs", which translate inputs, such as joystick movements, and outputs to waggle ailerons or gauge needles; and "commands" for most button clicks.

 

The commands are easy for me to understand conceptually.  Could you expand on the "datarefs" for me a bit more by giving a small example, please?

 

 

With sophisticated aircraft, modellers might be more ambitious, and the basic set of datarefs and commands might not be enough.  Then the developer will have to start programming, and there is a software developers kit for X-Plane, as there is for FSX.

 

So, I assume you are referring to some kind of API.  What is the language of the API (java, C, C++, C-Sharp, VB, Perl, XML, R...)?

 

 

This has been a long and somewhat waffly answer with few specifics, but I hope it serves as a broad overview.

 

It was not waffly and it was not short on good information.  It was a great post that explains a lot for someone looking for this kind of information.  I've learned more from this forum, than I have from all the others combined, about X-Plane.  The more I learn, the more the choice becomes easier to make.  Again, this will be one part of a much larger developmental program - so I'm not in this for the short haul.

 

Thank you for such a well written reply!  

Edited February 5, 2013 by Wetted Area

[Wetted Area]

BTW - Guy.  Where can I find a link to your work?

[Cameron]

BTW - Guy.  Where can I find a link to your work?

 

It's right there in his signature...

[Wetted Area]

It's right there in his signature...

 

Great, because I'm interested in his work.

[Wetted Area]

Hello Guy,

 

Just took a look at your site and it looks great.  I thought you might want to know that, before I replied to your post, I went to the link in your signature to look at your work.  Of course, I returned to ask you for a link, because after looking at the homepage, I got the impression that it was a only an historical reference website for the De Havilland Comet, because of the site's design.  Had I seen this link first: http://www.dh-aircraft.co.uk/about/'>DH-Aircraft, I would have immediately known about the X-Plane Aircraft Modeling information up front.  "About" links are often times depositories for generic information, so I never looked at that.  I don't know for what purpose you use the website, or if X-Plane Aircraft Modeling was the original intent for the site at the start.

 

The De Havilland Comet, especially with is storied history, has always been one of my favorite commercial aircraft of what was then the "new" jet age in commercial aviation.  The historical connections that run from De Havilland, through Hawker Siddeley, to BAE and then ultimately to Beechcraft (as you no doubt already know) lead to the current Hawker line of very light to light business jets.  The Comet's accident history, caused Hawker Siddeley to essentially build the entire line of Hawker Siddeley business jets like flying tanks. 

 

They are known for having a level of structural integrity and strength that surpasses most other business jets in class, which probably would not be the case (given the desire of most aircraft manufacturers to reduce manufacturing costs) had the De Havilland Comet not gone through its teething pains.  It also causes Hawker Siddeley to become somewhat obsessive about safety through redundancy of systems.  And, it is one of the primary reason why you cannot operate the Hawker 400XP as a single pilot - an aircraft I dearly love.  Of course, the Comet being the first commercial jet airliner to be put into official service, no doubt put a huge spotlight on everything De Havilland did with the aircraft.

 

Do you ever see yourself getting around to doing any of the distant cousins to the De Havilland Comet, such as the Hawker line of Business Jets?  Similar question for the line of Hawker Hunter Interceptors?  I'd be very much interested in both aircraft series as I believe them to be treasures in aviation past, present and future.

 

Regards.

[Wetted Area]

Hello Guy,

 

I also noticed on your site that you use AC3D for the modeling, I suppose.  I've noticed others who use that as well, but if I'm not mistaken, AC3D does modeling only.

 

What do you think about an integrated package such as http://www.symscape.com/products'>Caedium, that does modeling and CFD with both RANS and Panel flows?  I would think you could do some relevant optimization there, before porting over to X-Plane (if, Caedium produces a file that X-Plane can read).  Or, do you just create the model and then drop it into X-Plane, using their "datarefs" to tweak what you need to with or without the API (I'm not sure which)?

 

Regards.

[Cameron]

What do you think about an integrated package such as Caedium, that does modeling and CFD with both RANS and Panel flows?  I would think you could do some relevant optimization there, before porting over to X-Plane (if, Caedium produces a file that X-Plane can read).  Or, do you just create the model and then drop it into X-Plane, using their "datarefs" to tweak what you need to with or without the API (I'm not sure which)?

 

So long as you can export a model from Caedium to any of the following programs you can get your model into X-Plane:

 

1. AC3D

 

2. Blender

 

3. 3D Studio Max (payware exporter required)

 

4. Sketchup (limited...better for scenery since datarefs cannot be assigned here)

 

These are the only supported modelers for the X-Plane object format spec to export from. The datarefs are assigned in the 3D application prior to export, with the animation keyframes attached to the datarefs. 

 

Keep in mind that X-Plane will ONLY determine flight model data based on the acf file and its geometry, NOT the 3D application geometry you build. In other words, you have to build the same aircraft twice - once in Plane-Maker, and once for visual effect in 3D software (if you care about visuals). If you're purely after the flight model design you must use Plane-Maker for 3D/flight dynamics. Caedium, AC3D, Blender, etc will not help you out.

[guym-p]

This discussion is not helped by being in different time zones!

Thanks for your kind words about the dh-aircraft web-site. I've taken down a lot of pages about the X-Plane Comet because they were so out of date that they're not representative of the model at all. However, the news archive has much more recent screen shots, and it charts my journey along the learning curve. In retrospect, it was silly to start with something as complex as the Comet. I've enjoyed it (I still am) but it has taken so long that nobody else has been able to get their hands on it yet!

Can you 'name names' for the following aircraft models

Any free time I have is devoted to building and testing my own product, and very little time to downloading and trying other planes. I have bought many, but mostly airliners for benchmarking against the Comet, and no GA aircraft. My statement was simply that there is nothing to stop anyone from creating a model, good or bad. I am sure there will be people who fly GA aircraft who can give you a list, or at least a starting point.

It is obvious to me that some developers are making a tremendous effort to achieve very high procedural accuracy. You only have to read posts from the authors to realise how knowledgeable they are, and how earnestly they are trying to simulate the whole aircraft accurately, from engine start procedures to navigation. These include aircraft sold here, such as the Mitsubishi MU-2 and CRJ-200 — both of which I have. They are superb. Personally, I can't wait for the IXEG Boeing 737. I think it will become the gold standard for the next few years.

In the past, X-Plane has not attracted commercial development teams because it had a tiny market compared with MSFS and FSX. This is changing, and it's good news, because some of the FSX heavyweights have got involved. Perhaps you should talk to someone like Caranedo to see if they have anything that suits your needs.

What I did not understand is how X-Plane and Aircraft Modelers go about simulating that world.

The world is provided by Laminar Research. Just as real aircraft designers have to accept the world and its atmosphere as it is, so do X-Plane developers. Actually, there probably are talented programmers who could write more complex weather, or more realistic modelling of hidden or ducted components, or whatever, but that's not my area of expertise.

Also, it might be that you are over-thinking the problem. It is very simple to produce a flight model for X-Plane. The shape that X-Plane uses for the aerodynamic model is crude, but effective. All the highly detailed work you see on the latest creations is merely cosmetic fluff: beautiful, wonderful stuff, but totally invisible to the flight model. The only part that matters to X-Plane is the model in Plane Maker, known as the "ACF".

Also, it's not strictly true to say X-Plane behaves like a virtual wind tunnel, or that FSX is entirely governed by tables of values. They each do a bit of the other, but they are strongly biassed one way or the other.

The one question I have here, is with respect to last six words: "to get them to perform well."

I'll give you a broad-brush overview of my experience with the Comet. I had a lot of the correct information: I had dimensions, weights, CG, aerofoils, and a 160 page book containing tables and tables of performance data for almost every conceivable situation.

I created the Comet in Plane Maker, I used JavaFoil to calculate lift, drag and moment curves for Airfoil Maker. Obviously, as well as simplifications and approximations in X-Plane, my work was subject to any inaccuracies or inadequacies in JavaFoil too. However, I was delighted when it flew very well straight out of the box. Obviously, I had no experience of actually flying a Comet, or even of flying in one, but I had performance figures and written accounts from pilots.

When it comes down to it, we can only judge an X-Plane model's performance by measurable statistics. There are built-in tools to display development data on screen, plot it as a graph, or record data to a file, so that it can be analysed later. There is no satisfactory way to quantify subjective or abstract characteristics.

Something that made me smile was that a handling vice of the Comet 1 was clearly evident in X-Plane. In other words, X-Plane's simulation might be a crude approximation of the real world, but it is realistic enough to reproduce some of the actual character of the aircraft. I didn't have to invent it, or program it; it wasn't faked or induced. What's more, by modifying the aerofoil in exactly the same way DH did for the Comet 4, with reference to a research document from the Royal Aircraft Establishment, I was able to dial it out, and have stall speeds and unstick speeds within 2% of the real thing. That really impressed me.

As I started getting into it, I found many differences. The engines were particularly bad, but the aerodynamic model was pretty good. Fundamental characteristics, like stall speeds, were particularly accurate, and the behaviour on approach to the stall was as described by pilots. However, X-Plane could not "see" the Comet's ducted engines to calculate either the drag or the venturi effect, so I had to guess, increasing the drag curve for the wing root section in airfoil maker, until the performance figures were about right. There's a lot of that in developing something for X-Plane. It is an iterative process of test, feedback and change. Did you say "fudge"? Surely not!

Even then, some aspects of performance are simulated better than others. For example, in order for the Comet to have accurate cruise performance, I have had to sacrifice low altitude (holding pattern) performance. It's not bad, but it's not great, either. These compromises are typical of X-Plane, and I have a list of things I shall come back to repeatedly to rework as I find new facts, learn new skills, or new versions of X-Plane offer better solutions. Fighters will need different qualities from airliners, different authors will have different priorities, so there is broad scope for interpretation.

The X-Plane world is not a perfect one, but it is pretty good, and getting better all the time.

Could you expand on the "datarefs" for me a bit more by giving a small example, please?

Datarefs are like pointers, giving us "safe" access to variables in X-Plane. Some are writable (for example when pushing the yolk forwards, it will transfer your action via a dataref to X-Plane. Others are not writable. There is a full list of datarefs in every X-Plane installation, nested inside "X-Plane/Resources/plugins/DataRefs.txt" You'll find a list of commands there, too.

So, I assume you are referring to some kind of API. What is the language of the API (java, C, C++, C-Sharp, VB, Perl, XML, R...)?

I am only just getting into this myself, so I rely on experts like Sandy Barbour or Philipp Münzel to leap in when I get this wrong. Yes: there is a C API (by Sandy Barbour), further enhanced with useful C++ classes by Philipp, and other seriously clever stuff for other languages by others.

Plugins can either perform a stand-alone function, or interact with X-Plane. They could, in a sense, "hijack" a writable dataref, overwriting it in a situation where the developer thought the simulation in X-Plane was too crude, or not adequate for their particular aircraft. Perhaps the engine start procedure for a particular aircraft requires a couple of extra steps, or the engine thrust curve should have a "flat spot" to simulate changing air bleeds.

From that point of view, I have read about add-ons for FSX that make aircraft react to weather and air currents more like X-Plane, and an X-Plane plug-in could effectively force-feed a dataref with statistical data. With enough time and skill, X-Plane can be infinitely customised.

It sounds to me like your priority is an aircraft that is procedurally accurate, and that is entirely possible in X-Plane. You just have to find someone who has done it!

Do you ever see yourself getting around to doing any of the distant cousins to the De Havilland Comet, such as the Hawker line of Business Jets?

Yes: absolutely, but others will laugh because, at my current rate of progress, we will all be in our eighties before I've finished it! The DH-125 was a great little aeroplane, which developed into what we now think of as the Hawker (Beech) 900XP. It's the earliest examples I'm interested in. There's even a complete, beautifully restored one in the Science Museum, only 20 minutes tube ride from my home. I've already started collecting information about it. Do you know it's been in production for longer than any other jet aircraft ever made? I'm not talking about extensive refits, like the KC-135 (or still-born Nimrod MRA4) but brand new airframes rolling down the line. Major components are still produced in the former de Havilland Comet factory in Broughton (Chester), now the Airbus wing factory, so it counts as "continuous production". It's a shame that Hawker-Beechcraft became bankrupt last year. Lets hope they recover. If so, perhaps we can all celebrate 50 years in production later this year …

Guy.

Edited February 5, 2013 by guym-p

[guym-p]

Similar question for the line of Hawker Hunter Interceptors?  I'd be very much interested in both aircraft series as I believe them to be treasures in aviation past, present and future.

I forgot to answer this. I have a friend who has already developed a beautiful flight model for the Hawker Hunter. It's just the raw Plane Maker model at the moment. Having said I don't test anything other than airliners, I have to admit I spent several very happy hours scooting about the countryside at low altitude. It's lovely.

[tkyler]

I'll expand a short bit on "datarefs".  Datarefs are simply "public" x-plane variables, some read only, some read and write.... that x-plane makes available for monitoring and also for manipulation via a software SDK to allow customization or for debugging usage.  There are multiple thousands of these datarefs for every conceivable parameters of x-plane....I wouldn't even bother asking, "does it track variable x?" because the answer is probably yes, you just have to find it.  The list of datarefs are their descriptions (most of the time) are at  http://www.xsquawkbox.net/xpsdk/docs/DataRefs.html   There are two ways to utilize datarefs in a useful capacity.  One is through programming via the SDK or a 3rd party scripting engine like Gizmo or SASL where the goal is to control these variables directly or (more commonly)  derive behavior based on reading them.....for example say you want to make you own custom 3D airspeed indicator...you would need to read x-plane's pilot side indicated airspeed value to animate the 3D needle...and whether or not the pitot tube was iced up or the bus has electricity to power the gauge lighting.    With regards to scripting engines, these 3rd party efforts interface with x-plane using the official SDK, therefore these engines are a compiled plug-in DLL,  but then they go a step further and provide an easier to use scripting environment.  The benefit is you can customize x-plane with text files, no compiler needed.

 

Now for monitoring purposes..... say you don't want to customize x-plane but only monitor flight model parameters to see how your flight model is doing on an instantaneous scale, then there are two methods.   One is right there in x-plane already, the "data menu"...where you click checkboxes and x-plane will output the most common dataref values like speed, trim settings, AoA, engine power, prop thrust, throttle ratio right there on the screen.  You'll see this in a lot of screenshots...some green text in the upper corners of the screen.  The second method is a bit more "geek" but is a plugin called, "Dataref Editor"....a binary DLL plugin you have to obtain and install (more in a sec)  It's an absolute necessary debug tool for all things x-plane.    It is a translucent pop up window in x-plane and what it does it displays dataref names and their instantaneous values.  It has a filter text box so typical usage is to launch the window, type any text string from the dataref name you are looking for and the list will autofilter as you type and display the names of the dataref and it's instantaneous value. (which can be hard to read at 60fps sometimes)  For datarefs that are writable, you can click on the value to make it editable and change it via keyboard entry and in this case, you are simply writing to the public variable....BUT this does not mean that x-plane won't immediately overwrite what you just wrote one flight loop later.  Recall that x-plane calculates and writes to these variables too...some it writes occasionally and some it writes every flight loop.   Anyhow, that's a really long conversation....but the thing to know is that this tool is specifically for monitoring and changing datarefs for the purpose of debug or experiementation.  All you need to know about it is here:  http://wiki.x-plane.com/DataRefEditor

 

Once the plugin file is obtained and in the right folder, you can access it via the x-plane plugins menu.  By selecting the menu item, the translucent window will pop up and you are ready for performance debugging.

 

Tom K

[JimboG]

Thanks Tom,

 

A great post - I used this tool last week to build the interactive checklists for the JRollon Jetstream 32.... but may I ask you to expand on this a little more!?

 

As a person who is still quite new to X-Plane I wonder if you could offer any discussion around "Public vs Private" datarefs - how they work, how they are implemented and how to track them etc. I was able to get most of what I needed last week by examining the contents of files to "discover" custom datarefs, over and above what was visible in the dataref editor plugin. But there were a couple of "missing" datarefs that I simply had to reach out to Javier for...

 

To give some context I am not a developer, but I am a techie who can learn by looking - although doesn't mean I will be able to develop afterwards!

 

I have found you recent posts extremely informative, albeit beyond my understanding on some of the more mechanical engineering descriptions.

 

If you wouldn't mind giving me a little more background knowledge around the "digging for datarefs" I would be most grateful.

 

Cheers

 

James

[tkyler]

Hey James.

 

Public and private probably wasn't the best choice of words for those who know C++....so I"ll try and reword.  Datarefs can be what we generically call, "published"...meaning that a variable has been made available for other plugins to see and read.  The entire list of datarefs on Laminars dataref website are all "public" in the sense that they have been published (and can be seen by other plugins)  but not in the sense that you can write to all of them.   This list is all the "default x-plane datarefs" and the list grows slowly as new variables are introduced OR you coax Laminar into turning one of their internal variables into a dataref for usage in a plugin...which I have done for some electrical related values.

 

Now the SDK allows you to create your own custom datarefs with your own unique name and when a programmer does this, they can elect whether or not to publish their datarefs.......and you have to put in a few small lines of code into your source code in order to do this so that these datarefs can be seen by other plugins....and DatarefEditor IS just another plugin.   This process (and example code) of publishing your datarefs isn't the most visible in the xplane documentation and most C authors of plugins don't see it or even think about it.  They figure who wants to know what their datarefs are?  

 

For myself, when I wrote my C plugin for the Falco, I included code that published every custom dataref I created so I could debug with DRE (data ref editor), but that's just me.   I now use Gizmo and Ben Russell has included similar code so when you create a custom dataref in Gizmo, it too is published and can be seen in dataref editor.   In all my coding thus far, I just haven't found a need to not publish my datarefs, especially if cockpit builders are going to be dabbling with our stuff.

 

So the final synopsis is that all of x-plane's datarefs are published...and custom ones created through gizmo will be published.....but publishing custom ones created via the SDK is the choice/responsibility of the programmer and you pretty much just have to ask.

 

Tom K

Edited February 5, 2013 by tkyler

[JimboG]

Hi Tom,

 

Thanks very much, that explains it nicely! Makes sense of what I discovered during the process of creating Checklister plugin checklists for Javier's J32 - I was able to use the dataref editor plugin to get what I saw as the "default" X-Plane ones, and a couple of specific .OBJ files in the J32 install directory to get *most* of the custom datarefs.... but of course there were a couple "missing" that I just couldn't see in either...

 

So, not unlike the student asking the teacher and feeling a little awkward, I contacted Javier direct and asked him straight out - "How do you set your chocks?" LOL

 

Having attempted to guess quite literally beforehand, I was trying things like "J32/SetChocks", "J32/ChocksOn", "J32/ChocksSet", "J32/EnableChocks" - you see where I'm going?

 

So I asked Javier, and he very kindly told me: "Ah yes, this one: "J32/Chocks" - go figure.

 

At that point I kind of conceded that unless it is documented anywhere (similar to "published" I guess) you are just not going to know unless you ask the developer straight out or indeed ask that developer very kindly if he'll tweak the code to just spit out any and all datarefs to Gizmo / or X-Plane. (A good tip to know!)

 

So thanks again for filling in some blanks for me there - I must admit, during my first week of X-Plane I wanted to get my vrInsight MCP Combo Pro hooked up and Philippe very kindly sent me a whole load of datarefs - which made me go, "OK..............." but now I'm like the guy in Fifth Element who tries to mug Korben Dallas on his apartment doorstep stammering - "gimme the datarefs, gimme the datarefs, gimme gimme come on man come on".... What can I say? I love that film.

 

Anyway, thanks again - and sorry for jacking the thread.

 

Cheers

 

James

[JimboG]

Sorry - couldn't resist:

 

 

LOL - every single time.

 

Cheers

 

James

[Wetted Area]

This discussion is not helped by being in different time zones!

 

I get the strong sense that you live in the U.K.?  Though I live in the U.S., when I'm working the financial markets, I sometimes have the need to pull London hours.  Those can be very long work weeks for me, so I try to not do it all the time, but I have to go where the money goes - its my job!  But, I certain get the time zone thing being an issue.

 

 

In retrospect, it was silly to start with something as complex as the Comet. I've enjoyed it (I still am) but it has taken so long that nobody else has been able to get their hands on it yet!

Sounds like a direct correlation between real aircraft complexity and aircraft model complexity.  The more complex the real, the more time spent getting the model to "behave" the way it should - seems very reasonable.  Just chatting with you almost makes me want to take the plunge myself.  But, I can glean that I probably don't have the necessary time, and would end up detailing the aircraft so intensely, that I might not ever finish one myself.

 

Knowing me, I will end up most definitely taking it to the extreme of extremes just for the fun of it - but also because I am the eternal optimizer.

 

I'm struggling with the notion at this point.  I know I don't have the time for it, because I know I will become obsessed about getting it right and that will blow a hole clean through my work schedule.  Aircraft Models for X-Plane could become a dangerous slippery slope for my regular work schedule.

 

But, if I go after anything, it would be the Phenom 300, or the Mustang II.  Tempting.  But, I better not touch it.  It would be like trying to eat just one pistachio.  Impossible.

 

 

These include aircraft sold here, such as the Mitsubishi MU-2...

 

I used to refuel an MU-2 that made the FBO I worked at as a kid in school, one of its routine refueling/servicing points.  It was an extremely loud and very high pitch whiner.  We handled a lot of different aircraft including a tone of Piper Cheyenne's and King Air's.  But, none of those could compete with the whining pitch of the MU-2.  Though we were all going deaf from the turbine noise, we did love the smell of Jet-A and especially the lovely sweet scent of 110LL as it burned!  Ah, the memories. 

 

Do you fly real aircraft much?

 

 

Perhaps you should talk to someone like Caranedo to see if they have anything that suits your needs.

 

I've noticed that Carenado aircraft have a very distinctive "look" whenever you see them on the web.  The overall reveal of Carenado aircraft is very good - believable on the exterior, but the interiors tend to reveal even better than the outside in most cases.  I've only read one bad complaint about Carenado, but it was base upon insufficient aircraft functionality, as opposed to a complaint about some systemic problems with the model.  The owner just wanted "more" and felt that the aircraft should have had more actual functionality you would see in the real thing. 

 

I think the complaint was about the Baron B-58 - one of the aircraft I actually want/need for my project to fill the light weight multi-engine roll in my program.  I'll still give them a try and see how it goes.

 

 

The world is provided by Laminar Research.

 

The World is Not Enough!

 

I had to get that in there - I'm a part time comedian as well.  Though, I never get paid for being one.

 

Seriously, I think X-Plane is very good for what it is.  We are talking about aggregate powered desktop machines runing some fairly complex software. It this point, given my study and given my background, I do not consider either FSX, or X-Plane, to be a real flight simulator.  Those are just the facts.  They are both Hybirds.  They essentially 'simulate' a real simulation - if that makes any sense to you.  And, the appear to do it in different ways.

 

FSX, has more rigid (you can say religious) methodlogy that places the output (read: predictive rendering) of the simulation in a tighter box than does X-Plane, which has a methodology that allows for a greater degree of more fluid output (read: predictive rendering) of the same simulation theory.  Properly simulating equations of motion to an Nth degree margin of error is not hard.  It only becomes more difficult when you start adding spatial dimensions and competing force vectors to the equations.  Not to mention variables derived out of atmospherics and those related to viscous drag coefficients of multiple types.  This is to a large degree what makes desktop retail flight simulators, fairly hard thing to accomplish at a level of precision and accuracy that you find in some commercial grade full motion simulators. But, that's one issue.

 

The other issue is in the form of a question: Is it good enough?

 

I have concluded that for me - it is good enough.  Look, it really all comes down to the end user's expectations, because none of us can re-write the code base on either platform (FSX, P3D or X-Plane).  So, for me, it comes down to taking a look at what I required, what my expectations look like and figuring out if my needs can be met with what's currently available.  And, for me the answer is, yes.

 

Now, it is just a matter of finding the aircraft models that give me the most accurate "functionality" based on the type of flying that I intend to do in the very near future.  So, now, my shift is away from "can I use this desktop flight simulator as a tool to help me," to "where can I find the best aircraft models for my purposes."

 

Quite honestly, that might come down to being an iterative process where I end up buying every thing in the category and type I need, and then evaluating each one independently against a set of criterion that helps me make relevant distinctions.  This is where Keith's videos came in handy for me, personally (in the other thread).

 

Even then, some aspects of performance are simulated better than others. For example, in order for the Comet to have accurate cruise performance, I have had to sacrifice low altitude (holding pattern) performance. It's not bad, but it's not great, either. These compromises are typical of X-Plane, and I have a list of things I shall come back to repeatedly to rework as I find new facts, learn new skills, or new versions of X-Plane offer better solutions. Fighters will need different qualities from airliners, different authors will have different priorities, so there is broad scope for interpretation.

The X-Plane world is not a perfect one, but it is pretty good, and getting better all the time.

 

This pretty much sums it up for me to.  Good points all.

 

 

I am only just getting into this myself, so I rely on experts like Sandy Barbour or Philipp Münzel to leap in when I get this wrong. Yes: there is a C API (by Sandy Barbour), further enhanced with useful C++ classes by Philipp, and other seriously clever stuff for other languages by others.

 

Nice to know.  I've worked with API's of all kinds in the past and will no doubt be very rusty in initial approach to them today - if I had to do it.  But, the important thing to know is that an API is well documented!  I can't stress the importance of that enough.  A poorly documented rich API with depth, is worse than a very well documented shallow API - any day of the week.  But, a very well thought out SDK typically takes care of all this stuff.  I knew that one existed for X-Plane, but I did not know the language type.  That's why I asked.

 

 

It sounds to me like your priority is an aircraft that is procedurally accurate, and that is entirely possible in X-Plane. You just have to find someone who has done it!

 

Yes.  That's my goal in all this, but for three different levels of aircraft (SEL Trainer w/Conventional Gauges, MEL w/G1000 EFIS, MEL Turbo-Prop w/G1000 EFIS and Phenom 300 or Mustang II w/G1000 EFIS).  Those are the basic requirements (must have items).

 

So, I've got to find these aircraft models somewhere - or, I'm stuck with making them.  I know the SEL Trainer group is an easy one to fill.  However, the MEL w/G1000 EFIS, I'm not too sure about.  For the MEL Turbo-Prop w/G1000 EFIS, I think I might have seen somewhere before - not sure.

 

But, I have never seen a Phenom 300, nor a Mustang II w/G1000 for X-Plane at all.  Yet, I have seen a Phenom 300 w/G1000 for FSX and I have also seen a Mustang I w/G1000 - both for FSX (not the Mustang II).

 

So, the whole thing is coming down to aircraft right now.  The other issue of course, is changes to both navdata and navaids.  With X-Plane, when there is an update, you can download and upgrade your software to stay current.  With FSX, you have to manually make changes to navaids inside a few FSX files.  So, it can be done in FSX, but it would be a pain to have to do that each time you came upon an airport with differentials in the publish navaids, or when the navdata changes.  But, it is what it is.

 

Do you know it's been in production for longer than any other jet aircraft ever made? ... It's a shame that Hawker-Beechcraft became bankrupt last year. Lets hope they recover. If so, perhaps we can all celebrate 50 years in production later this year.

 

Indeed, the Hawker has had a long and well established career - legendary to be exact.  The whole HawkerBeech financial turmoil thing, I feel was a real blow to General Aviation as a whole.  HawkerBeech, was planning the new Hawker 200.  It would have been the largest Single Pilot Certified/RVSM Certified very light business jet in the world.  The company did not do a good job of managing the PR surrounding its bankruptcy and many believed that HawkerBeech would lose most of its VLJ production facility.

 

As it turns out, very recent news indicates that HawkerBeech will retain its "services" facilities and even expand them, while they still fumble the ball on news about the Hawker 200 VLJ.  They do indicate however, that certification will continue to be pushed forward on the Hawker 400 and 800 series airframes, citing a continuing relationship with Rockwell Collins and Honeywell.  Of course, the King Airs are never going away - in fact, they have indicated that they will be placing even more developmental focus on their Turbo-Prop series.

 

They are spinning off a separate entity to handle development of the Hawker 400 series and giving that entity the rights to develop the aircraft  Still, the 400 series won't be Single Pilot Certified (a total shame).  Though the Hawker 200 has un-officially been withdrawn, they still have the web page active and visible to the public: http://www.hawkerbeechcraft.com/hawker/200/'>HawkerBeech 200.

 

So, we are both hoping for improvement at HawkerBeech!  You want the classic Hawker to continue (and it looks like it will), and I want the single pilot Baby Hawker 200 to be put back on my list of potentials, as I don't see the Hondajet as having a competitive advantage in range over the other two choices.

 

As always - nice chatting with you.

 

 

 

[Wetted Area]

I forgot to answer this. I have a friend who has already developed a beautiful flight model for the Hawker Hunter. It's just the raw Plane Maker model at the moment. Having said I don't test anything other than airliners, I have to admit I spent several very happy hours scooting about the countryside at low altitude. It's lovely.

 

 

It would be fun to know how that turns out when your friend feels that he's "completed" his work on the Hunter.  I've developed an interest in the Hunter of the past couple of years that I never had before.  I never really appreciated the aircraft until I started studying it more closely.

[Wetted Area]

The list of datarefs are their descriptions (most of the time) are at  http://www.xsquawkbox.net/xpsdk/docs/DataRefs.html  

 

Brilliant!

 

There are two ways to utilize datarefs in a useful capacity.  One is through programming via the SDK or a 3rd party scripting engine like Gizmo or SASL...

 

I read somewhere that "Gizmo" and the other Plug-In, were problem children for X-Plane(?)  X-Plane was crashing down after audible lacerations of the human eardrum, etc.  Your opinion, please?  I've been right in the middle of Develper Cat Fights myself before and it ain't pretty.

 

where the goal is to control these variables directly or (more commonly)  derive behavior based on reading them.....for example say you want to make you own custom 3D airspeed indicator...you would need to read x-plane's pilot side indicated airspeed value to animate the 3D needle...and whether or not the pitot tube was iced up or the bus has electricity to power the gauge lighting.

 

 

Really.  Didn't know that such specificity was developed into X-Plane.  This is the kind of stuff that I did not want to ask questions about, because it seemed like too much minutia, but it really is important stuff for those building aircraft models.  As Cameron said, you have to build the model "twice" in X-Plane.  One being the Graphic representation of the aircraft, and the other being the Data representation of the aircraft that integrates the model with X-Plane, through DREFS, etc.

 

So, I always wondered how you get (as just one of many examples) the airspeed indicator needle to move with the right amount of acceleration around the face of the gauge.  Of course, airspeed is driven off the pitot (ram air) system.  So, I was trying to work out in my own head, how Austin, might have gone about encoding that kind of functionality.  I know how it works in a real airplane, but I did not know how Austin, translated that concept in X-Plane.  But, it sounds like the key to Aircraft Systems Functionality (at least much of it) is predicated on datarefs.

 

I opened up the file that Guy, referenced for me, ran a search on "datarefs" and found quite a few inside an unformatted text file.  I could see how the datarefs were "pointing" to paths (A/B/C/D) that lead to other reference information.

 

What's up with Squawkbox.  I thought that squawkbox was for use with VATSIM only as one of the client applications for connecting to their network.  Why does Squawkbox need to know anything about X-Plane datarefs?  Or, is the link that you gave me just a website that contains X-Plane dataref documents only, with no programmatic link to Squawkbox?  Or, are datarefs themselves some kind of global methodology for integrating aircraft functionality into desktop flight simulators?

 

With regards to scripting engines, these 3rd party efforts interface with x-plane using the official SDK, therefore these engines are a compiled plug-in DLL,  but then they go a step further and provide an easier to use scripting environment.  The benefit is you can customize x-plane with text files, no compiler needed.

 

 

Compiled code in a "real-time" environment is something I find interesting - good things its is local. 

 

Among other things, I develop automated systems (Bots) that I use in the financial markets that run inside of 32bit real-time streaming applications.  Streaming data comes in from a remote server, gets algorithmically processed in real-time and then rendered graphically on the client side within a real-time custom GUI.  Within real-time environments, compiled code typically runs slower than procedural code (scripting). 

 

In a real-time remote streaming data environment, the use of client side .dlls has to be weighed against the pain you suffer in slower processing and rendering speeds, against the benefit you gain from a cleaner coding methodology relative to hand scripting necessary functionality into the system.  In X-Plane's case, it doesn't have to worry about handing real-time streaming data across a network - so, it does not have that built-in lag condition to deal with.

 

What's the net/net bang on the system for having to deal with these types of .dll files as Plug-Ins?  Right off the bat, I would imagine that we are talking about some kind of hit on memory, just for starters.  And, another hit on CPU, depending on how the .dll is written and how large the file.

 

I'm just curious.

 

 

Now for monitoring purposes..... say you don't want to customize x-plane but only monitor flight model parameters to see how your flight model is doing on an instantaneous scale, then there are two methods.   One is right there in x-plane already, the "data menu"...where you click checkboxes and x-plane will output the most common dataref values like speed, trim settings, AoA, engine power, prop thrust, throttle ratio right there on the screen.

 

When I did my X-Plane walk-through, I did notice some kind of output data only type of mode.  I took a mental note and moved on.  But, it is nice to know that you can obtain these kinds of performance parameters from the client side.  Sounds similar to an MT4 Data Window, where you see the actual output from the system numerically, as opposed to visually.  I can also dump MT4 data into an excel file in real-time with custom parameters for columns and formatting, for further excel based analysis.  So, the concept sounds familiar.

 

You'll see this in a lot of screenshots...some green text in the upper corners of the screen.  The second method is a bit more "geek" but is a plugin called, "Dataref Editor"....a binary DLL plugin you have to obtain and install (more in a sec)  It's an absolute necessary debug tool for all things x-plane.  It is a translucent pop up window in x-plane and what it does it displays dataref names and their instantaneous values.

 

Khool!

 

It has a filter text box so typical usage is to launch the window, type any text string from the dataref name you are looking for and the list will autofilter as you type and display the names of the dataref and it's instantaneous value. (which can be hard to read at 60fps sometimes)  For datarefs that are writable, you can click on the value to make it editable and change it via keyboard entry and in this case, you are simply writing to the public variable....BUT this does not mean that x-plane won't immediately overwrite what you just wrote one flight loop later.  Recall that x-plane calculates and writes to these variables too...some it writes occasionally and some it writes every flight loop.

 

What is a "flight loop?"  Is that that starting and stopping of X-Plane, or the repositioning of the aircraft's location within X-Plane, etc?

 

 

Anyhow, that's a really long conversation....but the thing to know is that this tool is specifically for monitoring and changing datarefs for the purpose of debug or experiementation.  All you need to know about it is here:  http://wiki.x-plane.com/DataRefEditor

 

More Brilliance! 

 

Hey, thanks for tip on the tools and for checking in again on my X-Plane 101 training, Tom.     Although, I have met one individual who seems know quite a bit about FSX - it is also true that I've learned more about X-Plane from you guys than I have about FSX from anywhere else.

Edited February 6, 2013 by Wetted Area

[Wetted Area]

What's up with Squawkbox.  I thought that squawkbox was for use with VATSIM only as one of the client applications for connecting to their network?

 

Nevermind.  I back-tracked the URL you gave me to the domain name and found that it is xSquawkbox, which is different than the SB posted on the VATSIM main website.

 

Edited February 6, 2013 by Wetted Area

[Wetted Area]

Hey James.

 

Public and private probably wasn't the best choice of words for those who know C++....so I"ll try and reword.

 

It did send me scratching my head just a bit. 

 

Datarefs can be what we generically call, "published"...meaning that a variable has been made available for other plugins to see and read.

 

Well, then - my head is now spinning once again.  By that definition, it sounds very Public to me.

 

The whole idea behind OOP is to essentially hide the data.  Its like a big shell game (no pun intended) to languages like C++.  Or, like a game of hide and seek (keep the implimentation hidden from the interface).  Typically, you don't want to "expose" the flank of your most treasured variables, especially to "other" third-party code and under no circumstance is it ever appropriate to make public things like Class type Variables - no way.

 

However, I recall reading several instances of Austin, as he talked about trying to make X-Plane code "open."  The other thing too, is that from what you guys are telling me, the application architecture of X-Plane is one that should be exposed to a greater degree than other types of applications, just based on the nature of what Aircraft Modelers have to do, in order to optimize how their aircraft work inside the flight simulation model.

 

So, I guess its ok to break some traditional OOP rules about variable exposure through public auctions of their functionality to the highest bidding Third-Party Plug-In.  It is not like X-Plane gives access to source by doing this - certainly.  That would not be appropriate, I don't think.

 

Thank you for the clarification!

[Cameron]

I read somewhere that "Gizmo" and the other Plug-In, were problem children for X-Plane(?)  X-Plane was crashing down after audible lacerations of the human eardrum, etc.  Your opinion, please?  I've been right in the middle of Develper Cat Fights myself before and it ain't pretty.

In past days, but no longer an issue now. This happened ONLY if you had SASL also installed, by the way. See here: http://blog.x-aviation.com/2012/11/gizmo-and-sasl/

 

 

So, I always wondered how you get (as just one of many examples) the airspeed indicator needle to move with the right amount of acceleration around the face of the gauge.  Of course, airspeed is driven off the pitot (ram air) system.  So, I was trying to work out in my own head, how Austin, might have gone about encoding that kind of functionality.  I know how it works in a real airplane, but I did not know how Austin, translated that concept in X-Plane.  But, it sounds like the key to Aircraft Systems Functionality (at least much of it) is predicated on datarefs.

You are correct.

 

 

What's up with Squawkbox.  I thought that squawkbox was for use with VATSIM only as one of the client applications for connecting to their network.  Why does Squawkbox need to know anything about X-Plane datarefs?  Or, is the link that you gave me just a website that contains X-Plane dataref documents only, with no programmatic link to Squawkbox?  Or, are datarefs themselves some kind of global methodology for integrating aircraft functionality into desktop flight simulators?

As you have now noted, the spelling is different, but to further the answer, that website is maintained by Ben Supnik (the now primary programmer of X-Plane).

 

  

What is a "flight loop?"  Is that that starting and stopping of X-Plane, or the repositioning of the aircraft's location within X-Plane, etc?

The flight loop is where data is calculated at fractions of a second, constantly looped. This applies to not only flight dynamics, but also custom plug-ins. Code is constantly being looped through since variables may changed based on airspeed, etc. Think of it like an audio recording that plays and loops at a very rapid pace.

[Wetted Area]

Anyway, thanks again - and sorry for jacking the thread.

 

Cheers

 

James

 

You did not skyjack the thread - you asked some relevant questions and those of us that need to learn, did learn something from these guys.

 

So, thanks for offering relevant input to the topic! 

[guym-p]

I get the strong sense that you live in the U.K.?

Yes: London. Right underneath the flight path for approach to Heathrow 27R. The aircraft pass directly overhead at 3,000 feet, which is perfect for a bit of spotting in the garden on a nice summer's day, but not so noisy that it stops all conversation. Fly-pasts for the Queen's Tattoo (and other events) tend to whoosh overhead, too, which is fun (although they've usually begun to break formation by the time they reach here and scatter to their relevant bases).

 

Do you fly real aircraft much?

I regret not. I am purely an armchair pilot, although I benefit from my father having been in the aircraft industry from 1946-60. My early career was spent in the motor industry. I did a fair bit of test driving and developed procedures and test routines for other test drivers, so arranging relevant tests in X-Plane and analysing data is second-nature.

 

I do not consider either FSX, or X-Plane, to be a real flight simulator.

That's also the view of my father's contemporaries at DH, two of whom were test pilots.  They make astute observations about FSX and X-Plane, and polite comments, but say they would only consider them for familiarisation with instruments and navigation, or perhaps for illustrating a scenario during training, or a crash investigation.

On the other hand, younger pilots tend to me more generous about how useful home simulators can be.  There is at least one current, active, Airbus pilot who also "flies" the QPAC A320, and is impressed by it.  Have you looked at that? Some are disappointed by it's lack of a 3D cockpit, but it's priority is accurate systems simulation.

 

http://www.qpac.de/index1d9d.html?id=79〈=en

 

Now, it is just a matter of finding the aircraft models that give me the most accurate "functionality" based on the type of flying that I intend to do in the very near future.

You may find you have to take an existing aircraft and modify it to suit your needs. Perhaps you will find a beautifully modelled aircraft which lacks the right G1000 EFIS, and you have to borrow that from something else. If you engage the enthusiasm of the original developers of those aircraft, you might find them keen to help, or pleased to give you license to do it yourself. At least then you'd not be creating an aircraft from the ground up.

Edited February 6, 2013 by guym-p