Jump to content
Sign in to follow this  
taguilo

"new" XML vs. "old" XML.....

Recommended Posts

Guest jprintz

Hi everybody. I've just finished some new gauges, and they work wonderfully, but they are written in the old (FS9-style) XML. Are there any advantages to updating these to the new FSX style of XML? So far I know this: - new XML lets you use the ACE editor (yeah, so??) - new XML offers a way to wrap up and hide the code (good!) - new XML syntax tends to be significantly longer than old (bad...)What I DON'T know is this: - does new XML offer any new functionality? - does new XML offer any efficiency or performance improvements? - will there be an issue of old XML possibly not working in FS11?I would appreciate any input before I attempt to tackle what might be a pretty boring and tedious task. Thanks!

Share this post


Link to post
Share on other sites

At first I was excited at the possibility of encoding XML gauges using the spb format......until I discovered to my utter dismay that they won't actually work on everyone's system.Also, because we are still releasing all projects as FS9 SDK and FSX SDK versions, rather than code things twice we decided to stick with the FS9 XML schema for the time being.I will say this though, it's a whole lot easier to update existing XML to the new schema than it is to 'translate' the other way! ;)


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,>Are there any advantages to updating these to the new FSX>style of XML? It depends on the case. If you need compatibility between FS9 and FSX versions, it's obvious you'll have to stay with the old format.Now, pointing to your statements:> - new XML lets you use the ACE editor (yeah, so??)This per se isn't really important, because it's not necessary to use this editor for straight coding.> - new XML offers a way to wrap up and hide the code (good!)This is a neat advantage, that has a weak point though: code within scripts is not "compiled" but rather remains in plain text, visible to anyone that loads the spb file with a hex editor.> - new XML syntax tends to be significantly longer than old> (bad...)Yes, this is a disadvantage too.>What I DON'T know is this:> - does new XML offer any new functionality?Appart from some properties that now work ( ie ), and stockable structures, not more that I know of. > - does new XML offer any efficiency or performance>improvements?.SPB files are smaller in size than their .xml sources, and as their properties are precompiled also, load faster at aircraft init. But I don't see any performance improvement while running a flight, and I see no reason to expect a gain here just when only the schema was changed.> - will there be an issue of old XML possibly not working in>FS11?I don't think it would happen because of compatiblity needs. However, I believe MS will keep working to improve .spb format, and it will only apply to the new XML format.Just for the records, I was one of the detractors of this ugly new format, but had to change my mind and I'm currently working fine with it once I got used to.Tom

Share this post


Link to post
Share on other sites

>Just for the records, I was one of the detractors of this ugly>new format, but had to change my mind and I'm currently>working fine with it once I got used to.Well, it certainly is verbose, but at least it has the virtue of being "more consistent" in format than the earlier schema... ;)


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 jprintz

Hi Tom. In response to whether the new XML adds any new functionality, you said "Appart from some properties that now work ( ie ), and stockable structures, not more that I know of."Stockable structures? Does this mean that I could do a lot of variable assignments and computations within one element, as opposed to 20 of the following back to back?variable assignments, computations, etc.On a related note... with a long series of variable assignments and more complex computations, do you think, in general, it is better to use macros, or to assign things to L: Variables at the top in Element-Select-Value statements? This is for computations that are needed every cycle, the results of which are called several times throughout one pass through the gauge, and this made me think that somehow the L:Variable route would be better. Anyway, WRT my original question, my thinking is, if my initial impression of what you're saying about the new structure is true, that might be significant enough to tip the scales in favor of the new format.Thanks!

Share this post


Link to post
Share on other sites

>>Stockable structures? Does this mean that I could do>a lot of variable assignments and computations within one>element, as opposed to 20 of the following back to back?>No, it means you can include more than one on a gauge, and each one will be processed as well, as opposite to before where only the last found, in case of being more than one, would be considered. Mind though that all of them still share the same stack space, which in fact gives no big advantange to the new schema.Sorry but I don't understand what you mean with that "20" number?Actually there's no limit on XML code related to that number that I know of.>On a related note... with a long series of variable>assignments and more complex computations, do you think, in>general, it is better to use macros, or to assign things to L:>Variables at the top in Element-Select-Value statements? This>is for computations that are needed every cycle, the results>of which are called several times throughout one pass through>the gauge, and this made me think that somehow the L:Variable>route would be better. Anyway, WRT my original question, my>thinking is, if my initial impression of what you're saying>about the new structure is true, that might be>significant enough to tip the scales in favor of the new>format.>>Thanks!>Macros are useful mostly as a shortcut for repetitive code, and also as pnemonic names is special cases (for example a macro named @EngineStart is easier to remember than the set of LVars it represents)The use of LVars is mandatory when dealing with complex code, but again they should have a specific meaning (ie shared between other gauges, or the need to keep their values on everey cycle); if you need a temporary storage it is better to use registers 0 to 49 (s0-s49, l0-l49). The ultimate functionality within an XML gauge is given by the registers, therefore it is a very important thing to try mastering their use.Tom

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