FSX - Did You Know!

[n4gix 4,947]

>But all in all I see no big advantage of this format. The code>is by far not safe in this format...Well, I have written directly to ACES about this issue and hopefully will get an answer soon enough that I can share.The chief advantage of using pre-encoded .spb files is actually speed of loading and execution. For simple gauges, the "speed increase" would never be noticable, but for more complex gauges it can - and does - make a world of difference."Plain text .XML" gauges must be parsed/encoded at an 18Hz rate, so having them pre-encoded stops the redundant process required by "plain text" files... ;)

[n4gix 4,947]

>BTW, how does a program like Panel Studio react to these SPB>files? Just curious as I don't expect to ever D/L or use>any addon's that use the SPB format for gauges. Paul, FSPS simply cannot "read" them. It will - after several warnings - display a "magenta box" where the gauge is supposed to be.That's why I only "SPB" the .xml code at release time, after throughly debugging and testing the code. ;)The "issue" of this "invisible gauge" in FSX has only happened to 2 customers out of >1000 so far, so it's hardly a show stopper AFAIC...Obviously there is "something" amiss with those two customer's FSX installation, but I haven't found out what it is yet.

[taguilo 33]

>The chief advantage of using pre-encoded .spb files is>actually speed of loading and execution. For simple gauges,>the "speed increase" would never be noticable, but for more>complex gauges it can - and does - make a world of>difference.>Actually the advantage should be for speed of loading more than speed of execution, because a standard XML gauge is loaded and parsed/encoded at load time and then executed on each cycle directly from its memory's binary code; that's the reason one can modify an XML file even though the sim may be using it while running.Besides, so far I've tested, stack compositions remains "as is" -in text mode- inside the spb file, hence it seems that one could not expect much speed gain when working with complex XML data.Tom

[n4gix 4,947]

>Actually the advantage should be for speed of loading more>than speed of execution, because a standard XML gauge is>loaded and parsed/encoded at load time and then executed on>each cycle directly from its memory's binary code; that's the>reason one can modify an XML file even though the sim may be>using it while running.Until you "unlock" the .XML file using "Reload Panels," you cannot save any edits.Similarly, the saved edits won't take effect until you again "Reload Panels" to re-read the code.What I explained is what Susan Ashlock (Lead Gauge Programmer) at ACES told me. Perhaps she's incorrect in her understanding. :-beerchug

[Herbie63 0]

XMLs can be edited and saved while loaded in the SIM. Of course the changes do not appear until the aircraft/panel is reloaded. This is new in FS-X it did not work in FS-9 - there you had to unload the panel/aircraft befor you were even able to save an edited XML.I'm not an expert in these things, but don't think that this has something to do with the XML format or used editor but simply with the way the FS version handels those files. What counts is: it's more convenient now.As for the loading or executing time - well, I don't realize any differences, but that's probably my point of view only. If you tell me that there are differences... they will be there.And if you ever open an spb file with a simple text editor, you'll see that there still is a lot of plain text inside... That much about copy potection.But please don't misunderstand me - one or two more updates and the ACE editor might even become my first-choice-XML-editor.krHerbert

[taguilo 33]

>>Until you "unlock" the .XML file using "Reload Panels," you>cannot save any edits.>>Similarly, the saved edits won't take effect until you again>"Reload Panels" to re-read the code.>>What I explained is what Susan Ashlock (Lead Gauge Programmer)>at ACES told me. Perhaps she's incorrect in her understanding.> :-beerchug For a reason I don't know, FS keeps "locked" the XML files not only after its initial load, but after a resize/popup of any of its subpanels is done while running. Once "reload panels" unlock them, you can work on the XML files (edit/modify,etc) without bothering FS execution. What means that XML data is being read/executed by FS directly from it's memory stack. That's also the reason you need to "reload panels" again if you want your changes immediately reflected. The ability to work with xml binary data from memory is what makes XML files FAST to execute (yes, against what someone could think, they're really fast).Now, the scripting sections of XML files (what I use to call "stack composition" is loaded into memory in plain text format. This can be easily verified looking at dump files produced when FS hungs because of an XML gauge misbehavior. And it's perfectly logic, because a script has to be read one by one of its characters by the dynamic library that interpretes the code. Tom

[n4gix 4,947]

>And if you ever open an spb file with a simple text editor,>you'll see that there still is a lot of plain text inside...>That much about copy potection.The only "plain text" visible are variable names for the most part. The "logic" is totally hidden, as is the structure of the gauge.>But please don't misunderstand me - one or two more updates>and the ACE editor might even become my>first-choice-XML-editor.Please don't misunderstand me. I think the "editor" sucks hind teat! I much prefer working either in notepad.exe or using the "editor" in MSVC++ .NET 2003! :)The only thing I've ever used the ACE.exe program for was to (a) validate my syntax and (:( export the file to SPB format... :-wedge

[n4gix 4,947]

>Now, the scripting sections of XML files (what I use to call>"stack composition" is loaded into memory in plain text>format. This can be easily verified looking at dump files>produced when FS hungs because of an XML gauge misbehavior.>And it's perfectly logic, because a script has to be read one>by one of its characters by the dynamic library that>interpretes the code. BTW Tom, I wasn't be facietious in my quip about Susan perhaps not fully understanding how XML works in FS... At the time she wrote that explanation to me, she was still a relatively "new hire" at ACES. Although Susan is a crackerjack C++ programmer, this is her first exposure to the rather "odd use" that FS makes of XML... ;)I can report to you some objective experience with loading time however. Having "spb'd" all of the .xml files in the Bombardier_CRJ_700.cab, I noticed that the loading time for the "spd'd" .cab was just under 3 seconds, where the "stock" .cab took around 45 seconds to load!That is a very significant difference! :-beerchug

[taguilo 33]

>>I can report to you some objective experience with loading>time however. Having "spb'd" all of the .xml files in the>Bombardier_CRJ_700.cab, I noticed that the loading time for>the "spd'd" .cab was just under 3 seconds, where the "stock">.cab took around 45 seconds to load!>>That is a very significant difference! :-beerchug Yeah, that's the real advantage. I have an XML gauge that is 45 kb in size, that when converted to spb it only measures 4 kb! No doubt it will load much faster :-)I recall that spb format was originally created to handle XML scenery files which might be bigger than 1 mb, and being reduced to the 10% after "converted" to spb.Tom

[Herbie63 0]

Hmmm Bill, that indeed is a significant diference in loading time.I never made such a test converting a complete set of gauges...So this makes me consider to convert all my xml gauges to spb.Can this only be done useng the ACE editor? As allready said, most the time I load one of my xml with that ACE I get a bunch of error messages, even though the xmls work fine in the sim. But I wrote them using the "old" FS8/9 syntax which is - as you know - a bit different from what ACe expects. I have to go through the SDK once more, maybe converting xmls via the commandline works better.Herbert

[n4gix 4,947]

Herbert, to be perfectly clear: ONLY XML code that is 100% compliant with the new FSX syntax can be "SPD'd". Period. :)

[Herbie63 0]

Bill,Yes, after several attempts to convert my "old" xmls I allready thougt so... Thanks anyways for pointing this out once more. Seems I have to convert my xmls... anyone out there interested in converting a gauge with more than 1000 lines of code?But seriously, for me the safeness of the code is of a much greater importance as loading time. And at least in my spb not only the variable names but also almost every text of the script-elements is in plain text. And that's where many of the "secrets" are to find!!I felt really enthusiastic when I read your news about this spb files, but now it ends up in disappointness only. Maybe I should try to learn C++.Thanks for your help and infos!Kind regards,Herbert