Jump to content
Sign in to follow this  
Guest Vorlin

XML coding wish-list for FSX

Recommended Posts

>>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... ;)


Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556


     Avsim Board of Directors | Avsim Forums Moderator

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.


Fr. Bill    

AOPA Member: 07141481 AARP Member: 3209010556


     Avsim Board of Directors | Avsim Forums Moderator

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
Guest Vorlin

I have an idea that *should* (yea, we all know about that word) be practical.To upgrade the functionality of XML in FSX, it should only be necessary to upgrade the parser that translates XML into machine code... not do a major change to the program itself. Such an upgrade could even be done as a downloadable patch, so as to not delay the release of FSX at all.If I had my wish, these are some of the things that would be in such a patch:1) First and foremost, a really good DTD that has all possibilities in it and a chart showing the tree of every possible tag that can be used as a child to any possible parent. Start the tree at and just keep branching until you get to the last possibility in any and every direction. It's not that bad, I did it myself in a couple of hours for a DTD that I generated for FS9.2) Macros that can handle all child tags that are below . This would allow us to write an Element with L:Vars in a macro, then write an updater macro that changes the Vars used in the Element above. @Element produces result A, @Update, then @Element produces result B because the Vars were updated. Coupled with #3 and #4, this could be huge...3) Case tags that can handle not only Images, but assign numeric or text variables and even run macros to set entire sub-sets of variables to the needed values, depending on any one of an unlimited number of situations (each of which is it's own Case).4) The ability to use variables inside of tags. (Yes, Nick mentioned it but I think it deserves a clear example). IE:Now we use:AliveBut this is far more flexible:(L:MyTextString,text)Why would this be worth the trouble?1) It would cut down on a lot of repeated code, reducing the time it takes to write.2) Re-usabilty would be enhanced dramatically.3) Looping a single operation many times while changing the Vars in between loops, including text vars and attribute vars, could end up being the power tool that could shatter all known limitations to this point... leading to all sorts of things we haven't even dared to attempt before.Macromedia AS1 already does every one of these things via their function() and Switch/Case structure and can provide a great example of how the ability to use such routines enhances the ability of the developer to make really stunning packages.And the better we can make our projects, the better FSX looks and feels... and the more people will want it.Oh, and it would be nice to know if all the XML for autogen and gauges is handled by one parser... the DTD should show if there are multiple possibilities for a base tag. It would increase the flexibility of those who code XML to be able to do ANY XML needed for FS9 and, if it's all handled by one parser, there is no reason that the DTD couldn't be all-encompasing.Scott / Vorlin

Share this post


Link to post
Share on other sites

Scott,From your two preceding posts:""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.""You can perfectly edit XML gauges that are in folders while FS is running. Just need to reload_panels BEFORE any attempt to edit a gauge, this action will release its write protection. Then edit the gauge, save it and reload_panels again, that's all.""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.""When a gauge blanks out, it means there is a structural error (NOT a syntax error) . For example: code is a struct error-gauge blanksAn unclosed if{ is a syntax error-gauge shows all but the offending code.To test for struct errors, simply open the gauge with Internet Explorer, and it will signal the portion (aprox) where the error begins.Testing for syntax errors can be very tough when dealing with complex code but, hey, that's part of life for any dedicated programmer in any language :-)""2) Macros that can handle all child tags that are below . This would allow us to write an Element with L:Vars in a macro, then write an updater macro that changes the Vars used in the Element above. @Element produces result A, @Update, then @Element produces result B because the Vars were updated. Coupled with #3 and #4, this could be huge...""This is already possible though not exactly the way you state here.""4) The ability to use variables inside of tags. (Yes, Nick mentioned it but I think it deserves a clear example). ""I agree. This would be a great enhancement.""3) Looping a single operation many times while changing the Vars in between loops""This is already possible as well.I would add what I believe would be a winner for XML addicts:-The ability to assign string values to LVars- The ability to manipulate arrays of LVars (ie L:MyVar:1,number) WITH the possibility to handle index as values in macros.For example, @1 would mean what is passed is literal text, and $1 would mean is a numeric value, then one could write @Maco((LvarIndex)) and in the macro (L:MyVar:$1,number) would retrieve its :1 position's value(Bear in mind L:MyVar:1,number is available today, but almost useless because of the stated)Just my 0.02 centsTom

Share this post


Link to post
Share on other sites
Guest Vorlin

Tom,>You can perfectly edit XML gauges that are in folders while FS>is running. Just need to reload_panels BEFORE any attempt to>edit a gauge, this action will release its write protection.>Then edit the gauge, save it and reload_panels again, that's>all....and...>When a gauge blanks out, it means there is a structural error>(NOT a syntax error) . If this is the way to use a reload, and it will recover a blanked out gauge without restarting FS9, then we apparently won't need the external emulator after all (though there are times when it would be nice to have).I'm combining the above with an odd tip that you all may or may not know already:Make a copy of the AC you're writing a gauge for and change it's contact points in AC-config so that the wheels/skids are floats. Then start in Adak Alaska and slew south very quickly until you're about halfway to Hawaii (takes 3 minutes or so at very high slew). Put your AC down on the water, clear all weather and save the flight.This loads FS9 about 3x faster than normal on my system... It's just my AC, the water and not a cloud in the sky. >To test for struct errors, simply open the gauge with Internet>Explorer, and it will signal the portion (aprox) where the>error begins.I was aware of the MSIE check but it's a tip that always is worth repeating!>Testing for syntax errors can be very tough when dealing with>complex code but, hey, that's part of life for any dedicated>programmer in any language :-)Oh yea... my work with ActionScript1 sometimes threatened to make me chew the desk in half. AS1 is the scripting language for MM FlashMX, and those practices are what I'm trying to emulate in my XML scripting for FS9... which is tough to do without arrays, text vars, functions and case statements that can call functions.>""2) Macros that can handle all child tags that are below>. This would allow us to write an Element with L:Vars>in a macro, then write an updater macro that changes the Vars>used in the Element above. @Element produces result A,>@Update, then @Element produces result B because the Vars were>updated. Coupled with #3 and #4, this could be huge..."">>This is already possible though not exactly the way you state>here.>>""4) The ability to use variables inside of tags. (Yes, Nick>mentioned it but I think it deserves a clear example). "">>I agree. This would be a great enhancement.>>""3) Looping a single operation many times while changing the>Vars in between loops"">>This is already possible as well.Ok, I can do my 30th forum advanced search or maybe someone could just point me at a post that I should start with... but either way I *must* figure out what you're referring to! LOL>I would add what I believe would be a winner for XML addicts:>>-The ability to assign string values to LVarsSorry, I didn't say that specifically but I think many of the things I did say would require your string variables suggestion first for my suggestions to work very well.>- The ability to manipulate arrays of LVars (ie>L:MyVar:1,number) WITH the possibility to handle index as>values in macros.Big time. Character selection is huge... especially the ability to set a variable or attribute variable to determine which character will be selected.>(Bear in mind L:MyVar:1,number is available today, but almost>useless because of the stated)I can't understand the last part of that sentance... "because of the stated ___________?" Referring to something you stated above perhaps? I got lost in that reference.>Just my 0.02 centsUS, Canadian, Singapore or Centavos Mexicanos? >TomScott / Vorlin

Share this post


Link to post
Share on other sites

Hi everybody,""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.""I've not had this problem. My little reload gauge (I think everyone knows the code)reloads this kind of corrected gauge ok. I do however use a seperate folder with the files uncabbed.BTW, main reason for replying, have a search for a freeware text editor Notepad++. It's great for editing XML. You can also add a dll that checks for errors when you save the file. I won't give details here because there are so many features, but they are listed on the website. I use this all the time now and would not be without it.cheers,nick

Share this post


Link to post
Share on other sites
Guest Vorlin

>Hi.>It is very likely that it is too late to integrate another,>more powerful, language.I agree... but it's never too late to rewrite just the parser. Even if it wouldn't be ready for the release of FSX, it could be a downloadable upgrade just as 9.1 was for 9.0.Rewriting the parser could add a lot of functionality that we're currently lacking, could be used to take things to new levels and it's not *changing* the language at all... merely adding functionality to the existing one.Scott / Vorlin

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...