>I

Why is there always a flame war in this forum? :(I have several addon planes that require a default plane to be loaded beforehand. These addon planes push the limits of what is capable in MSFS, and in order to use them we must accept the limitations and strange prerequisites :). The default gauges load various settings into the memory, and allow us to display complex non-default gauges ... I have no problem with this :)

The PMDG B1900 IS, in effect, a default aircraft. It uses default gauges, with default coding. There is nothing there that requires initialisation or loading before it will work. The same applies to many other add-ons, but far from all.The point is that if you start with an add-on aircraft that DOES require background code to be running, and you experience problems with it, the chances are that it's because the code is not loaded or initialised. If you want more than that very basic level of functionality provided by the default gauges and the SDK, the background code is essential.There's no flight management system coding in FS or the SDKs, there's no weather radar, TCAS, GPWS, pressurisation... Most of the basics are there, but it is only the basics and if people want to build on that, they have to work outside the SDKs. If you work outside the SDKs, that means ALL the coding has to be built into your gauges and objects. That code requires loading, so you have to initialise it before it will work.If you're happy without that extra level of functionality, don't buy complex add-ons, that way you won't have to initialise functions. If you want the extra functionality, you need the extra code because it is NOT present in default FS. If people think the FS developers are so incompetent because they can create functions that are far outside the realms of what MS provide them as a base, people can prove it's possible to do so much better by doing it themselves.It really is that simple.Ian P.(edited to correct grammar)

Bang on, Ian P. I couldn't have said it better myself. The level of sophistication that is being programmed in some add-on's is WAY outside the realm of MSFS. For the 767, the AFDS was built from the GROUND UP, as MSFS does not model many of the modes that a jetliner like the 767 has.Best bet (again): use the CREATE A FLIGHT menu to start your flight.http://www.ldsflyingclub.com/siggies/ds.gif

Hi, Ian.>The point is that if you start with an add-on aircraft that DOES require background code to be running, and you experience problems with it, the chances are that it's because the code is not loaded or initialised.

I'd say, however, that you weren't working with proprietry code - or were working with the support of the developers of that code.I work in the UK railway industry, a lot of the time with systems called Train describers that basically don't do much other than tell a signaller what trains are standing/moving where. The problem is that a lot of them are proprietry. We can't officially access the code - rather like people officially can't access the back end of FS and, if a hardware supplier tells us that this is the way the TD works, that's what we have - we have to code a way around it in the data. It means we end up with some very odd bits of code flying around which make no sense at all until you sit down and work out what they actually do.That's what happens with FS, because MS will only tell you the very surface and not the rest. The rest the developers have to code around.You know when you start up your kit - the same as we do when we start up a TD - what the state of the system is: It's cold and dark. You will clear memory, load program files from firmware coded PROMs, you initialise everything from a known state and then you start actually doing things with it. That's all starting from a default flight does, it goes from a known base position. It's common sense, not some great conspiracy of inept programming.I agree about the commercial development environment hindering information interchange, but don't see exactly what you can do about it. A private commercial venture, whether in instrumentation and control or FS, is a private commercial venture. Why should they give all their secrets away to competitors who would then use it to develop, as the term "competitor" implies, competing products?Ian P.

I've followed these arguments but still no one has yet explained the reasons why it's necessary to load the default aircraft first. All that's been said is won't work otherwise.Consider modelling complex aircraft systems in C. I'd expect the programmer to develop the model by declaring and initialising all his own necesary variables, and by writing the code to model the relationships between. I'd also expect the system model to interface with the state of Flight Simulator by accessing the published Token Variables.In that case, I'd like an explanation of what causes the need to load a default aircraft. For example:- Do the Token Variables return the wrong values?- Are other variables within Flight Simulator being used directly?- Any other reasonsA specific example to illustrate the problem would also be helpful.

Hi, Ian.While I am calling your name directly, it does not imply that I think that you are the one that has done, or does these things. It

While I'd like to thank you for the compliment, I think you have me confused with someone else... My programming talents are nothing compared to the people who write add-ons for FS - it's just that I understand some of the challenges that face them! ;-)In Industry - especially safety critical like medical and transportation, we tend to have have licensing structures, documentation and procedures that are designed to make things as standard as possible. You'll never get that in FS. Because people are constantly working around, rather than with, what they are given in terms of standards documentation (the SDKs), you're into a world where people discover things by trial and error. No, it's far from the best solution, but it really is all they have.We, the customers, are constantly demanding more. People found ways of displaying where the AI traffic are and called it "radar", so the customers complained that it didn't show the weather. So people found a way of showing real-time weather, so we complained that it wasn't integrated into the navigation display. It's a constantly moving ballpark. The UK heavy rail infrastructure is great... Most of it hasn't changed since the 1970s and 1980s, so we pretty much know what we're getting these days (and replacing it as fast as we can!!). The life cycle of FS add-ons is two years at most? And for over 50% of that the information needed to develop around it is still being worked out? It doesn't allow for much development time per product. Plus the amount of effort required to develop a new "toy" far oustrips any gain from putting it in your product for all but the largest groups. It simply takes more man-hours to put in than you get rewards for at the end.Anyway, I think this thread has seen enough of my epic posts by now, so I'm going to bow out gracefully. if the guy further up the thread still demanding to know why he hasn't read why he should start complex add-ons from a default flight hasn't read any of this yet, he isn't going to. That comes under "his problem, not mine", unfortunately.All the best,Ian P.

>- Do the Token Variables return the wrong values?>- Are other variables within Flight Simulator being used>directly?>- Any other reasons>>A specific example to illustrate the problem would also be>helpful.Actually, sometimes the 'state' of the token variables aren't what are needed at the time of loading. These of course, can (mostly) be changed by the gauge programmer on panel load.Also, you seem unaware that there are a lot of "state data" that're only saved in the "default flight" file, that are not included in any specific "saved flight" file.It's somewhat similar to the relationship between the aircraft.cfg file and the .air file. Whatever isn't specifically defined in the aircraft.cfg file is then loaded from the .air file.When loading a "saved flight," the data not saved with that file are loaded from the "default flight" file.Essentially, there are three case scenarios at play here:1) simple a/c that use only SDK gauge methodology may be loaded at anytime.2) more complex a/c may require that the "default flight" be one of the default a/c, such as the C172, but you can still load the chosen a/c without first loading the C172 directly.3) the most complex a/c might require that you first load a default a/c (such as the C172), and then switch to your desired a/c.

Why not? We get blamed for everything else. ;)

>Why not? We get blamed for everything else. ;)ha! It's about time you took the blame :(

Thanks for your helpful explanation but...The sequence you describe is:1) Load the default flight that will presumably load all the data from the default .flt file2) Load the complex aircraft that will first load the specific data about that flight followed the data not saved with that file from the default .flt file. The last step will surely overwrite the data loaded in 1)? The data overwritten should be the same anyway?I note your comment that all of this is un-necessary if developers work to the published SDKs. Presumably those who didn't caused some of the problems with installing the Flight Simulator patch, making their users have to restore Flight Simulator to its original state before they could install the patch. This reminds me of those programmers who decided to use unpublished Windows API calls a few years ago. They had apparent success until Microsoft eventually up-issued the APIs with new documentation. Then the programmers found the the effects of the calls were different. In some cases applications that ran with the old APIs crashed when the updated ones were used.

>I note your comment that all of this is un-necessary if>developers work to the published SDKs. Yes, that's right. And as a nice by-product you'll get add-ons that are exactly as sophisticated as the default B-737. I guess that's what you want? I for one am not going to die if I have to load a default plane prior to loading a complex add-on, but to each their own. :-)

No one has yet explained why it's necessary to go outside the SDK or what exactly is done when it is.