Jump to content

Sign in to follow this  
Guest Vorlin

XML coding wish-list for FSX

Recommended Posts

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

Share this post


Link to post
Share on other sites
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++.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest

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

Share this post


Link to post
Share on other sites

>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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

>>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).In FS2004 you can test and debug an XML gauge while the sim is running. Nothing more easy. No need to restart ever, as CTD and hungs are RARE events to happen because of the way the code is handlend, ie syntax and math errors (like div by 0) are literally ignored and produce no crash effects on the sim.Tom

Share this post


Link to post
Share on other sites
Guest jordanmoore

Hi Tom,I did not find that to be the case. There were many small changes I found that could hang the sim. Enough of them, that eventually, I had to get into the habit of restarting every time, because it was faster than dealing with a hung sim.For example, any time a 2 digit positional coordinate value was changed to a 3 digit value (ie. x=99 changed to x=100) would hang the sim on a reload. This of course is just one small example. Did you not find this to be the case? I saw many posts regarding reloading flights, and reloading panels to refresh gauge changes, and tried to implement them for my own work, but did not get desirable results. Did I overlook some important detail?Jordan Moore

Share this post


Link to post
Share on other sites

Jordan,I've never had problems like those you report. I've been playing with XML almost for two years, from a start point of not knowing what the heck RPN meaned up to now having a collection of very complex gauges of my own. One of them is a "test gauge" that I've been using to experiment with syntax code, stack's composition and macro's behavior among other things. I use the reload_panels command and the only times I hung the sim were because of events constantly fired, bad handling of stack's loops and improper macro coding.However, I've heard of other people having problems with components, bitmaps positioned wrong inside a gauge, and a bunch more of this type, more related to be graphic issues.Honestly, I find XML gauges to be very stable, much more than some C ones. In fact I own a couple of the most prestigious airliner's addons, and have suffered the "blue screen" drama more than once.Tom

Share this post


Link to post
Share on other sites

I missed jwenting's remark about the "published API" the first time round. Using Windows GDI requires dealing with bitmaps, handles, pens, brushes, device contexts, pens, brushes, and palettes (including creating releasing and deleting them); creating compatible bitmaps; understanding the 16 output modes, the 7 mapping modes, windows extents and viewports; working on memory-based compatible bitmaps and BitBlkging them to the screen, etc, etc.The latest GDI+ which provides a C++ interface "contains about 40 classes, 50 enumerations, and 6 structures. There are also a few functions that are not members of any class." Neither are the thing for the typical user who wants to create a simple gauge!

Share this post


Link to post
Share on other sites

>In FS2004 you can test and debug an XML gauge while the sim is>running. Nothing more easy. No need to restart ever, as CTD>and hungs are RARE events to happen because of the way the>code is handlend, ie syntax and math errors (like div by 0)>are literally ignored and produce no crash effects on the>sim.Like yourself, I've found the "Reload" gauge to be a great time saver when it comes to XML development. In fact, the first benefit is "unlocking" the .xml gauge so it can be overwritten. Make a small change, save the .xml file, then click "Reload" button again to instantly see the results! ;)However, I've wasted weeks trying to track down an issue with a GNS530 I developed, which was syntactically perfect. It passed every validation test I could throw at it, and worked perfectly in most cases.However, with a few systems, the code would cause a CTD on panel load with a consistent "ntdll.dll error." Compounding the problem was that there was zero commonality between the affected systems to point to a proximate cause.I spent several hundred hours chasing down ideas that proved to be red herrings...Finally, a few days ago I sat down and rebuilt the entire gauge by , testing carefully after each addition, until I located the offending section(s), of which there turned out to be two.The "fix" involved nesting a group of into a parent . Even though there is no syntactic reason why this is necessary, doing this in the two problem areas solved the CTD issue completely.Now, what is the point of all this narrative? Simply to point out that - even if you follow the syntax rules one-hundred percent - there are exceptions that can occur. This points to a somewhat unstable and unpredictable development platform... ;)

Share this post


Link to post
Share on other sites

Hi.It is very likely that it is too late to integrate another, more powerful, language. I find MSFS XML lacking in the controller / Joystick interface and I hope it will get implemented. Also the possibility to build / run it in Global mode, like DLLs, where a Module can be constructed without having to be a Gauge. TV

Share this post


Link to post
Share on other sites

Hi Bill, would you say this is a pretty rare occurance, though. I've built hundreds of gauges without any problems except one which caused crashes, but then it turned out I was being experimental. Certainly, if I follow the 'rules', XML seems pretty stable, in my experience. Could you post the section that caused the problems please. I'd be interested to see it.thanks,nick

Share this post


Link to post
Share on other sites

>Hi Bill, would you say this is a pretty rare occurance,>though. I've built hundreds of gauges without any problems>except one which caused crashes, but then it turned out I was>being experimental. Certainly, if I follow the 'rules', XML>seems pretty stable, in my experience. Could you post the>section that caused the problems please. I'd be interested to>see it.>thanks,>nickSure will... Look in the Panel forum for the code snippet.

Share this post


Link to post
Share on other sites
Guest Vorlin

I'll place this here since this is the thread it was started in:I have experienced something between CTD's and no problems with XML scripts that have errors in them.... the blank gauge.My experiences have been that the reload command works great if you're cab'ing your files first, but you can't use it if your XML files are in a folder because you can't save any changes if the sim already has that XML gauge file open.Another issue with reloads is that when they're working with cab files, just one script error blanks the gauge... which is no big deal. However, once the gauge has blanked once, even reverting to a known good version will NOT bring it back to life. The only option, once it's blanked once, is to shut FS9 down and bring it back up with a good working version of the XML file in the cab.If there is a way around this that anyone knows, could you share it here? I'm looking at archives almost day an night lately, and haven't noticed anything that would help.This is why I have to agree with Jordan. Until there is another way to get FS9 to display a good version after a bad one has blanked, without restarting the sim, the need to have an emulator to check your code outside of FS9 is a valid one.If that way exists already, could you share it please? :)Scott / Vorlin

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...