XML coding wish-list for FSX

[nickpike 0]

Here are some notes regarding changes/ improvements when using XML to produce gauges in FSX.Modellers are now using multiple contact points for their gear to simulatethe 4 wheels on an airliner bogie, for example. Therefore, something like anAirbus can have something like 14 wheels, and therefore 14 contact points inthe aircraft.cfg file. Problem is, the autobrake function will not work withthese many points when done as an XML gauge. The C++ type gauges still work.I believe XML RTO still works ok.Would there be a workaround for this or fixed in FSX?In FSX, can it be written-in that when using in an element block, the block becomes inactive?Can you add to FSX a way of using a variable in this?that is, for exampleWill vector graphic handling be improved? When designing a gauge in just one view and size, all can look well, but when changing, say, from windowed view to full screen, or changing the gauge size, the vector graphics move relative to each other. This does not happen if bitmaps are used.Some of the variables originally intended for the GPS gauge (and have not been implemented to date) do not work. Will these be fixed. Example, FlightPlanWaypointFrequencyWill it be possible to produce a full FMC, TCAS and weather screen in XML. In other words, will XML achieve what C++ gauges can achieve now. Can you introduce the ability to use Circular clipping.Introduce the 'arc' vector graphic.Will there be the ability to add fuel to a tank in a controlled manner, also make fuel/ tank control comprehensive.Dump controlled quantities of fuel.It would help if vertical speed can be implemented seperately from altitude hold.Have the ability to change the symbols on the gps maps which are presently hard coded?Some of the periscope gauge parameters do not work at present.Many thanks,Nick Pike

[Guest]

turning XML into a programming language is always a Bad Idea (with capital :(, and doing so in FS was no exception.It would be better if that decision was reversed rather than expanded, and FSX return to C++.

[Guest fsxcess]

Whatever FSX uses, I just hope they document everything correctly this time with samples as well. The learning part is not that hard, its the discovery of what and what isn't doable is where the problem lays.If FS is to continue to grow then the internal FS functions should be revealed to the addons and less of this guessing game.It reminds me of when PSS came out with the reverse thrusters and everyone saying, "oooh how did you do that?". Letting everyone create 'work arounds' is no good. Instead we need hard facts about what features are available.

[nickpike 0]

Hi fsxcess. I could not agree more.Hi Jwenting, I could not agree less. XML is a far more flexible coding language than C++. Alright, I know it's not strictly a language as such, but being text based and does not require compiling makes it far easier to use for the enthusiast. It's a lot easier to learn that C++ (in my opinion). I really enjoy coding in XML, and gives an easy route to the inner workings of FS. The enthusiast can study existing gauges and learn how to make their own gauges. If all gauging was C++, it would all be left to the priviledged few. We would go back to a time where people producing panels would be stuck with a finite number of gauges to use and the same old gauges would keep turning up and be missmatched. XML allows a far larger number of people to produce realistic panels with matched gauges. I would like to see XML have all the features of C++ and then people would have the full choice of what system to use.I sincerely hope that the MSFS team grasp this opportunity and make XML as comprehensive as possible.cheers,nick

[Avcomware 1]

Hi.Another idea maybe to integrate a language like Python. TV

[Guest Dan G Martin]

Great Idea I used Python back in the days of Fly! and one could get atjust about anything one needed but I fear it might be too late as most of the base feature set might be all ready locked in but it would great if the Team could add more tools for the Add-on community to grow the core product. Moving back to a more C++ orentated way of doing things would be a step backwords as it would mean many people would no longer be able to do their part in adding to the sim. Dan Martin

[mgh 89]

I agree. I've programmed in C/C++ professionally but decided to use XML for gauges beacuse it's easier. Also, the SDK implies everything is C, as are most of the samples, but ITrafficInfo.h is in C++. Most people here are not experienced C programmers, don't have access to a C compiler, and would have problems setting one up to create .dlls. With XML all that's needed is a text editor.What I do hope is the Microsoft will offer a proper SDK covering XML. The 7 pages (including the example) in the current SDK are a disgrace. The don't even identify the all features available and have at least one error - rdeg is said to normalise an angle in degrees. In fact dnor seems to do that but isn't even listed!

[Guest]

XML is a mess, it's useless for procedural and especially OO use.Almost everyone who tries to turn it into a programming language has second thoughts after a while.I've had to do some programming of ANT scripts and it's a mess. While for simple things it might do, when you get into the complicated, advanced stuff, it either becomes incredibly messy and impossible to maintain.I wouldn't want advanced stuff on my system no matter what environment it's done in that isn't created by experienced people. Opportunities for trouble are just too great.And it doesn't have to be C++, Python is an excellent alternative for example.And even with C++ (which is a very nice language) it's not just a "privileged few" that would be able to do it.Anyone with a decently developped brain can learn it reasonably well, certainly well enough to write a game plugin using some samples and a published API to follow.

[Guest]

Everyone can download the latest C++ compiler free from Microsoft, and there are several other free options as well.

[taguilo 33]

>XML is a mess, it's useless for procedural and especially OO>use.I cannot disagree more. In fact, I think XML is the future in FS gauge development (though C++ would not be abandoned for obvious reasons). >Almost everyone who tries to turn it into a programming>language has second thoughts after a while.>Precisely its strenght lies on not being like a classic (structured) programming language, and its stack-oriented-assembler-like flow makes it run fast, faster than some people may think.>While for simple things it might do, when you get into the>complicated, advanced stuff, it either becomes incredibly>messy and impossible to maintain.Well, I'd dare to say, for example, that nothing could be a better choice than XML to program an airliner's complex overhead (freeware of course). And I know what I'm talking about.>And even with C++ (which is a very nice language) it's not>just a "privileged few" that would be able to do it.>Anyone with a decently developped brain can learn it>reasonably wellProbably, but, why bother to learn C++ if XML:- It's easier to code - It's easier to test and debug- It's fast- It's very stable (no PC crashes and/or hungs)Unless someone's going to develope a payware project, needs to code vector graphics, sound or file IO, I strongly believe XML is the option.If FS team manages to address some of these weakness, they would make a lot of people very happy for sure! And, if ever they (or someone else) finally find a way to protect XML cabs, most payware groups would begin to smile as well...Just my thoughts.Tom

[mgh 89]

To build a simple fuel gauge in C following the examples/instructions in the SDK I needed the following files:fuel.hfuel.cfuel.rcfuel-gauge.cgauges.h gauges_bcc.def (because I use Borland C++ builder)I also needed my experience of writing C/C++ to be able to understand what I was doing. Even someone with a "decently developed brain" might balk at first having to learn how to use a C++ complier, then having to learn C++ and OOP, and finally having to understand Miccosoft's approach as set out in the SDK before he or she can create a simple gauge.

[Guest tdragger]

Right on! I remember the first gauge I created took me about 4 hours to build from the time I picked up the SDK to the time it was finished. (Well, finished in the sense that it behaved the way I wanted--I'm no artist!) It consisted of 37 lines of XML and 5 bitmaps and all I needed was a paint program and Notepad.To me that's the clear benefit of XML gauges--rapid development with a simple toolset. Sure, there are things (like owner-draw gauges) that are impossible or impactical to do in XML. But if you measure the success of the platform by how many people are developing for it we'd be severely limiting FS by restricting development to C programmers.

[Guest]

> XML is a messWrong buddy, XML will become a mess if Your schema is a mess.> it's useless for procedural and especially OO use.Thats BS! XML data can map to object models, one key use being serialization. It can be used to make programs configurable and generic, and it avoids recompilation. Thats just some of the advantages!> I've had to do some programming of ANT scripts and it's a mess. It dont surprise me your Ant scripts are a mess if your trying to program with them LOL.

[Guest christian]

>XML is a mess, it's useless for procedural and especially OO use.True, but the gauge SDK is using a batch of C macros and not using OO either. One could rewrite the macros, but that would be a lot of work with no apparent advantage.Don't get me wrong, I'm using C for developing gauges and I love OO, but the SDK doesn't support OO, no matter what path your choosing.Christian

[Guest jordanmoore]

XML structure with a proprietary scripting language, while being a little daunting at first (because it is proprietary), will serve MS well as they continue to evolve the product internally, but strive for maximum backwords compatibility with existing add-ons. Abstraction in this way was a great choice for the platform. That being said, I think they could have made it far more accessible by abstracting one layer further and providing a set of scripting functions that are not loosely based on RPN. While quite learnable, this approach can make even simple tasks more complex than they should be. If they need RPN internally for efficiency reasons, perhaps they could have done that parsing for themselves at load time.I think the XML gauge scripting component of FS was a great choice on the part of the dev team. I think they probably know this as well by now, and will continue to let it evolve. I hope for FSX that they incorporate more functions, more conveniences, more variable interaction, more features, and the possibility of protecting IP.A powerful XML gauge emulator would also be a huge boon to those of us who get tired of restarting the sim 8,000 times to develop a complex gauge (luckily, simple gauges only take 500 restarts of the sim, lol). Or perhaps some type of developer mode for FS that would allow for quicker testing cycles and/or sim reloading.Very much looking forward to FSX.