Yes, it's the best but not only to start learning.
It's the best for learning, and one will learn fast how limited it is. If he hasn't yet, it's only because he still have tackled something *really* complex.
If you take a look at the vast universe of freeware and commercial aircraft and panels released for FS (9&X) you'll find that a huge majority use XML files as a source for standard gauges.
You keep mentioning "quantity", while I was more concerned about QUALITY. And this, I'm afraid, is sorely lacking. Yes, even the most famous FSX developers out there, could do MUCH better.
Even the latest commercial projects, some with highly advanced Virtual Cockpits, are handling complex code within their modeldef XML files.
Again, the quantity of XML used doesn't say much. And I've said in my previous reply to Bill, of course XML will be used inside .MDL files, but what I don't agree with, is precisely the usage of it for "complex code", because it makes for LESS efficient code and it's NOT any faster to develop, because it's just wrong trying to shoehorn something that XML has never designed to do, and does it in an inherently messy way.
Commercial developers have been using C++ to model standard systems since FS' first days, in one way to protect their work from piracy and competitor's watch.
That's just a very minor reason for using C++. Again, if someone uses C++ JUST to protect from piracy, he's missing the WHOLE point of using C++ in the first place...
Since Virtual Cockpit has become the standard view mode, most of them are programming their gauges directly as animated objects controlled by modeldef XML scripts, as I stated before. Some of them still use C++ in extensive graphical displays and system's control, but even in those cases you'll find basic 2D gauges (like COMMs,Airspeeds, etc) coded in XML and defined in VC sections within panel files.
Doing an hybrid approach it's even worse. Once you took the pain to setup a C++ compiler, it's way easier to do everything in C++.
I find this very reasonable because I don't see a true reason to program otherwise; I can develope gauges and or modules in C++, with or without Simconnect, and I wouldn't ever think of writing an analogic Airspeed in anything but XML, for obvious reasons that you resist to accept.
I wouldn't ever think of writing an analogic Airspeed in anything but C++, instead, if I were doing a 2D panel. On a VC-only panel, instead, I would probably model the needle in 3D, link it to an animation with modeldef.xml which doesn't do *anything* other than rotate the needle, and drive the variable from C++, so it would be properly integrated in the bigger picture of a larger, probably more complex, system simulation.
A sample of something that, as of today, is still unbeaten in speed, smoothness and quality, using ANALOG gauges on a 2D panel (yes, 2D panels are passè today, but I did this in 2005...), I suggest having a look or at least read some reviews of the Cloud9 MB339 and the Cloud9 Phantom. These were using a framework (100% C++, of course) that allowed me to use GDI+ for ANALOG gauges, dispelling the common knowledge that GDI+ was "slow" (it's not, if you know how to use it) and only useful for glass cockpits, because nobody figured it out how to have a background with smooth GDI+ needles on top of it.
The Cloud9 Phantom was released in 2006, see some comments here on Avsim from 2012 (6 YEARS later!!) commenting on a newly released F4, that still couldn't match it:
http://forum.avsim.net/topic/381357-newly-released-f4-phantom/
A sample of something that instead uses the approach of a fully 3D VC (with no 2D panels), was of course the F/A-18 we made for Microsoft to be included in FSX Acceleration. This uses the approach I think it's the best of two worlds: there's a LOT of XML modeldef.xml animations, but the XML inside is as DUMBEST as it can possibly be. The real work is done entirely in C++, and the interesting fact is that, the whole airplane code is just 800K... The result, of course, is that the F/A-18 is one of the smoothest airplanes ever made for FSX, which is even more interesting, considering it's made with 4 ( 3 DDI + 1 HUD ) GDI+ glass gauges, which are usually considered very "slow".
This a discussion of the famous "Petraeus Index", a benchmark which was made to test AIRPLANE relative performances, all other things being equal:
http://forum.avsim.net/topic/242828-the-petraeus-index-version-2-feb-2009/
Unfortunately, the actual graphics is not available anymore on the internet, but if you read the comments in that thread, BOTH the F/A-18 AND the EH-101 (the other airplane I made for MS), were at the TOP of the benchmark. The F/A-18 was released in 2007, and it was even fps *limited*, by default, but it includes tweaks to make the fps even better, so with a today's fast machine, the gauges can refresh at 60+ fps, if your system can handle it.
Regarding what you noticed of a lowering in some addon's quality, it has nothing to do with XML but it's basically related to market strategy.
This might be true, but it doesn't have anything to do with the choice of using XML vs C++. I'm not even happy with the quality of some that are considered the best products out there. There must be something *wrong* if an airplane lowers your fps in half, and takes 1GB of RAM, and I simply don't buy the explanation that "it models complex systems", there might something else going on, because C++ code on modern CPUs can't really slow down a system, regardless how "complex" it is. Either the developer doesn't do his job properly, or there's a fundamental problem in the overall approach.
BECAUSE an airplane .MDL is "complex", that's PRECISELY why you want to keep the XML in it (in the modeldef.xml file) as simple as possible, and do the "real" work in C++. An airplane with hundreds or even more ( I think the PMDG 737 has more than *thousands* draw calls = part animations ), moving part, will benefit more and more from moving away from XML, because nothing is slower than string processing, and XML parsing is the showcase piece of string processing!
Really it's a shame that you have such difficulties with XML. I, on the other hand, find it simple, easy to understand and easy to code. But maybe it's just me.
This can be easily reversed: if you can't see how FASTER and BETTER is debugging with C++ and the excellent Visual Studio debugger, compared to the clumsly and limited debugging options you have with XML, the only possible explanation is that you never tried doing a real comparison.
Well, you can suggest, or not suggest, whatever you want. In the end will be nothing but your personal opinion, which some people might consider valuable and some other might not.
The whole point of this forum is to share opinions. It has been years since I've made an airplane product, and I'm really too busy right now managing my company, to have any hope of doing another airplane project again.
But precisely because many years has passed, I think I can now share some of the things I've learned in those 20 Years of professional Flight sim development, and I don't considered them to be business secrets anymore, so maybe someone might find it useful and research on his own.
Anyone has the right to ask money for his work, and there will be someone who will probably buy his product. Succeeding in sales will depend on how much customers liked the product, not the level of C++ expertise the developer has. I've never seen a customer ask in a support forum whether the gauge programmer knows how to setup a compiler, or build a sort routine.
Of course users don't care how something is done, but they WILL notice when something has good performances and doesn't take too much memory. It's not user's role to question development languages, but they will surely notice when something works better than something else.
Now, MS at one point faced with kinda same dilemma: to choose a language/tool that, being simple, reliable and rather easy to program should bring more developers to the Flightsim arena, meaning more future sales. Indeed they had already C# and C++, but that wasn't enough. So they included XML and that was, obviously, a clever decision as well.
And they started to move away from it, because they introduced LUA (which I'm not particularly love, but at least IS a script language...) in the MS Flight SDK, and got away with RPN notation in modeldef.xml! While still not the best possible solution, at least they knew what the biggest XML shortcomings were. Note that, if MS Flight SDK ever reached the release stage, it would have meant an "earthquake" for XML developers, since they would have had to REDO all their existing XML code (the more complex, the more rework needed), since the "new" XML in MS Flight wasn't backward compatible, in the most painful way, in the expression evaluator, the core of it...
Of course, someone that used my preferred approach, of making the XML code as simple as possible and doing everything with C++, would have been spared from such pain...that's another very good reason to prefer C++ to XML. XML is not a standard, it can be anything, depending how it's parsed. Something changes in the sim and how it processes XML, and your precious code might become useless. Just see what happened with P3D, which only accepts > and doesn't accept the > sign. It's very *minor* thing, but it's enough to stop lots of code from working.
Of course, if you have your own routine coded in standard C++, nobody will ever take it away from you, your time investment is preserved, even if you would need to eventually move away from the FSX "family".
If a developer made a complex airplane entirely using standard C++ code and libraries, and linked it to FSX only in the thinnest way possible (as I've suggested), compared to another developer who made incredibly complex things in XML "code", who do you think will ever had any chance to move to, let's say, X-Plane, in case FSX and/or P3D would eventually "fail" ?
And FS, when building gauges, uses similar functions both when reading their structures from an XML file and when reading them from a compiled .gau/dll. The main difference lies in XML files being compiled by FS at run time, and C++ coming already compiled and thus, (allegedly) better optimized. Using XML source files FS builds gauge classes that also have equivalent to C++ module init/deinit, gauge callback, mouse callback and event_handler functions/routines.
"(allegedly) better optimized" ??? A WORLDS AWAY BETTER OPTIMIZED!! But again, that's not the whole point, the whole point is that with XML code, you are forced to do something that it would have been very *easy* (and very fast) in C++, more complex that it would have been. So, it's slower for two reasons: both because XML parsing is inherently slower, and it scales very badly, but also because the code logic itself becomes more complex because it's limited by what is really a glorified expression evaluator, not really a "language".
I wouldn't dare to talk about a tiny fraction. Just do a search on this forum and you'll discover very interesting projects that were developed by using advanced XML scripts combined with external modules like those named by Bob (the OP). Fortunately MS was smart enough to include XML to C++ interaction via those modules, which expanded XML possibilities to a level hard to imagine years ago. Another clever decision for sure, whether you accept it or not.
Doing something just because it can be done, doesn't automatically means it's a good idea doing it. Yes, I could go off-road with a sport car, but why would I ?
MS brought XML to developers. Developers (mostly) made a choice. Customers also. And FSX blossomed, still being current after so many years since released. Reality is the only valid truth.
You just made my point. Customers, without even knowing, grant with commercial success the developers who use mostly C++, just look what the best selling airplanes are.
Yes, someone might enjoy very good commercial success with a product that doesn't use C++ at all, why not ? But this doesn't prove your point that *because* it can be done, it's always the best choice, maybe it was for a particular product, but you will never know if it could have been an even better in C++, your argument that because there are developers having success using XML or that the FSX platform has blossomed because of that, it's not enough to prove that XML is the automatically the "best" choice.
I might say that, instead, without any support for C/C++ and 3rd party modules with very extensive access to the platform, FSX would have been JUST like any other "moddable" game out there, something that might be nice for users having fun modding stuff, but not nearly enough to start a (small) *industry*.
Many games have some kind scripting technologies, similar to what you could do in FSX XML, most of the times even better using more powerful languages like Python, LUA, etc. but very, very FEW allows full development of proper (and potentially dangerous) .DLL modules using C++ and guess what, NONE of these games has so much commercial development available.
So, the only fact I see here, when comparing FSX to other games, is that FSX has C++ and full blow support for plug-in modules and if it only had XML, it wouldn't be much better (in relationship to having started an "industry" of add-ons, which of course keep users interest high) than all those other games with scripting abilities.
As I've said, it's not that having XML included was a "mistake". Offering a development environment geared towards beginners has ALWAYS been a successful strategy for MS, some argued it was Visual Basic which really kicked off Windows, and the ability to develop something with an easier starting approach DOES bring value to the "platform", and this will in turn attract better developers, or will simply turn beginners into better developers, and those will soon enough realize how much better they will work with a better programming language.
There IS room for both kind of developers, but for exactly the same reason, it's just wrong insisting that you can do "everything" that C++ can do in XML so, there's no point using C++ because XML can do "everything". Yes, it can do lots of stuff, but C++ would do the same stuff way better and more efficient and even consuming LESS developer's time. It will take more time to LEARN C++, but once you learned what it really MEANS programming in C++ (which doesn't mean compiling a gauge, it means using proper classes and programming patterns), and you have all your base framework in place, you will proceed FASTER with C++.
While XML was designed to exchange data, C++ was designed to increase programmers productivity.
Now to learn this.
