C gauges in FS11

[byork 2,259]

So I asked Phil Taylor in another forum about C gauges in FS11.His response:"unknown at this time, all I can say is they will cause a lot of work if we need to keep them."Doesn't look good for C gauges :-)-Bryan

[Chuck_Jodry-VJPL 663]

Thanks for clearing that up , i read the original and was not absolutely sure i had placed Phil

[WarpD 824]

>So I asked Phil Taylor in another forum about C gauges in>FS11.>>His response:>>"unknown at this time, all I can say is they will cause a lot>of work if we need to keep them.">>>Doesn't look good for C gauges :-)>>-BryanIf this is true, it will eliminate a great deal of commercial products.

[dragonflightdesign 98]

And quite a few developers, me included. I'm pretty sure I can find something else to do with my time and it won't be learning XML gauges.-Dai

[taguilo 33]

Well, it wouldn't surprise me that MS takes this kind of decision.It's a fact that the old C-style's macro structures used in panel-tied .gau/dll files have not been improved almost a bit since the old FS days. Instead, there has been a massive movement towards XML-style gauges, scenery, mission and similar kind of FS files; I believe MS-ACES has developed FS's internal routines - mostly C++ classes - that handle XML source files in a very efficient way, considering the simulator's overall performance.As current XML-format limitations are actually schema limitations, it's very possible that we could find XML stuctures which will make possible to manage file IO, graphics and sound in future FS versions; even FSX shows a lead in that way, with the combination of "master" C++ dlls and XML "custom" related files for panel management. Now, the very weak point of an XML based system is the lack of effective copy protection for the sources. Even though FSX gives the possibility to "precompile" XML gauge files, it's not secure enough when speaking of complex commercial projects. So we'll have to wait and see how things evolve in this area.Tom

[ddawson 35]

Such a comment would seem to paint ACES as being out of touch with the "3PD's" as Phil likes to refer to them as.Rest assured Phil, you need to keep them, even if you do have to change their structure going forward.

[WarpD 824]

>Well, it wouldn't surprise me that MS takes this kind of>decision.>>It's a fact that the old C-style's macro structures used in>panel-tied .gau/dll files have not been improved almost a bit>since the old FS days. Instead, there has been a massive>movement towards XML-style gauges, scenery, mission and>similar kind of FS files; I believe MS-ACES has developed FS's>internal routines - mostly C++ classes - that handle XML>source files in a very efficient way, considering the>simulator's overall performance.>>As current XML-format limitations are actually schema>limitations, it's very possible that we could find XML>stuctures which will make possible to manage file IO, graphics>and sound in future FS versions; even FSX shows a lead in that>way, with the combination of "master" C++ dlls and XML>"custom" related files for panel management.> >Now, the very weak point of an XML based system is the lack of>effective copy protection for the sources. Even though FSX>gives the possibility to "precompile" XML gauge files, it's>not secure enough when speaking of complex commercial>projects. So we'll have to wait and see how things evolve in>this area.>>Tom>>>>>>>The weakest point of XML is it is an 'interpreted' language and thus can not process data and information as quickly as a compiled language such as C++. Nor can you write extremely complex systems like a realistic autopilot and/or flight management system with XML. Simply 100% impossible.I shudder to think of how limited my current project would be if it was written in XML.

[taguilo 33]

>>The weakest point of XML is it is an 'interpreted' language>and thus can not process data and information as quickly as a>compiled language such as C++. This doesn't seem to be a real limitation for most -if not all- possible projects, considering there are so many elements that affect FS performance appart from gauges. >Nor can you write extremely>complex systems like a realistic autopilot and/or flight>management system with XML. Simply 100% impossible.>Well, your statement reveals how much of XML scripting's power is directly ignored by many people. But the fact is, using XML and C++ dlls combined like shown in the SDK, there is no limit at all to build the most complex system available in any aircraft. Now I'm starting to notice that ACE's staff is well aware of this ;-)>I shudder to think of how limited my current project would be>if it was written in XML.Ed, I can agree with you here :-)Tom

[WarpD 824]

Well... the current C++ DLL support was almost gone with FSX... so don't be holding your breath. You have nooo idea how much they intended to kill in module support.As for scripting power... that's a beautiful oxymoron in my opinion. Do you truly think a scripted file like a .bat(ch) file can be even remotely as powerful as a full-blown .exe(cutable) file? I hope not... seriously.XML performance can indeed reveal significant performance impacts... the G1000 on my computer crawls with frame-rate issues... whereas the Mindstar G1000 (c++ .gau) does not.

[n4gix 4,949]

>As current XML-format limitations are actually schema>limitations, it's very possible that we could find XML>stuctures which will make possible to manage file IO, graphics>and sound in future FS versions; even FSX shows a lead in that>way, with the combination of "master" C++ dlls and XML>"custom" related files for panel management.The primary drawback to such a "hybrid" system is that it simply shifts the computational, sound and file I/O to a futher layer of complexity, increases the memory overhead, and forces longer development time, all of which add up to increased costs. >Now, the very weak point of an XML based system is the lack of>effective copy protection for the sources. Even though FSX>gives the possibility to "precompile" XML gauge files, it's>not secure enough when speaking of complex commercial>projects. So we'll have to wait and see how things evolve in>this area.Indeed, this is the burr in the saddle. Absent the development of robust protection against reverse-engineering, the community will ultimately suffer, as developers exit the business.

[taguilo 33]

Ed, I didn't know they planned to get rid of DLL module support. Why was that?And please do not compare the scripting system of an XML gauge file with a batch file. Instead, think about this: a C compiled .gau contains optimized code that is going to be "loaded" by core FS functions embedded in its main executable files. An XML structured file contains tags and scripts that are going to be "interpreted" (put into memory stack) by other FS core functions located in the same executable files.Obviously there should be some kind of impact in performance when speaking of very complex gauges, but might be perfectly masked by other variables (like scenery, weather). In my case, loading the default G1000 (both MFD and PFD) yields a loss of 2-3 fps in full window (I have a notebook nw9440), which I find very tolerable.Tom

[n4gix 4,949]

>In my case, loading the default G1000 (both MFD and PFD)>yields a loss of 2-3 fps in full window (I have a notebook>nw9440), which I find very tolerable.The G1000 affects my system quite heavily (-10fps) vs. analog C172 panel. Also, the G1000 cannot by any stretch of the imagination be considered an especially complex gauge.

[Chuck_Jodry-VJPL 663]

[taguilo 33]

Well, I have a similar loss (-7/8 fps) in windowed mode. Anyway I agree with you, the G1000 is a basic gauge, with just too many elements to draw.Tom

[n4gix 4,949]

>Well, I have a similar loss (-7/8 fps) in windowed mode.>Anyway I agree with you, the G1000 is a basic gauge, with just>too many elements to draw.Well Tom, I have worked closely with Stasi during the continuing development of his Mindstar G1000, and I can state with absolute certainty that there's no way under the sun that ACES could ever provide the necessary XML schema to allow all the funtionality that Stasi has put into it to be replicated, period.The very notion of OOP is foreign to the XML paragidm.