Sign in to follow this  
Herbie63

FSX - Did You Know!

Recommended Posts

Has anyone noticed the new "tools" in FSX SDK SP1a?The first is psd2xml.exe...Psd2Xml is a tool that generates the files required for a gauge from a multilayered Adobe

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Nice.One day I hope to have to time to read/learn about them. ;DIn the last two weeks, I've been too busy with all the web site stuff, and been going crazy.Great finds, and thanks again ACES!

Share this post


Link to post
Share on other sites

Hi Bill,would you by any slim chance know how to convert an XML file written for FS9 into XML written to the new ACES.XML schema so that it would load into ACES.exe?cheers,nick

Share this post


Link to post
Share on other sites

>would you by any slim chance know how to convert an XML file>written for FS9 into XML written to the new ACES.XML schema so>that it would load into ACES.exe?Yes. Very carefully! ;)Actually, I'm in the process of doing just that at the moment with my ESDG "Garmin stack" of gauges.To make life simpler, I've carefully created "templates" for each of the various types, and simply cut-n-paste 'em into the "new" gauge project's XML file.Keep in mind ALL of the existing parameters and coordinate locations are the same, only their syntax and locations have changed... So, it's really not that difficult. Tedious and time consuming to be sure, but hardly difficult! :)Because I'm blessed with three monitors on my dev computer, I'm able to have FSX open and running on the middle monitor, the two XML gauge files open on the left monitor, and my "template XML file" open on the right monitor.Every so often, I'll save the "new XML gauge" file and exit notepad, then open it in the ACES Editor, (re)save, then load it back in notepad to continue working.Frankly, I find the ACES Editor too cumbersome and ackward for the task of "converting" an existing XML gauge file, but it is invaluable for (re)formatting the XMl code with proper tabbing and indents, as well as "validating" work done so far.After throughly testing and debugging the gauge, the final step is exporting as an SPB file for the "release version" of the gauge, removing the plain-text XML file of course... ;)

Share this post


Link to post
Share on other sites

>>would you by any slim chance know how to convert an XML>file>>written for FS9 into XML written to the new ACES.XML schema>so>>that it would load into ACES.exe?>>Yes. Very carefully! ;)>>Actually, I'm in the process of doing just that at the moment>with my ESDG "Garmin stack" of gauges.>>To make life simpler, I've carefully created "templates" for>each of the various types, and simply cut-n-paste>'em into the "new" gauge project's XML file.>>Keep in mind ALL of the existing parameters and>coordinate locations are the same, only their syntax and>locations have changed... So, it's really not that difficult.>Tedious and time consuming to be sure, but hardly difficult!>:)>I've started a similar procedure, just copying/pasting the structures to templates of the new format. VERY BORING, but not difficult at all. Besides, mostly of my codes are long stack structures and macros, which makes the whole thing simpler to convert :-)The idea, as Bill pointed out, is to take advantage of the new SPB format file, for which the ACES tool becomes mandatory. (though I still believe is a no-no for programing-only for exporting)Tom

Share this post


Link to post
Share on other sites

>The idea, as Bill pointed out, is to take advantage of the new>SPB format file, for which the ACES tool becomes mandatory.>(though I still believe is a no-no for programing-only for>exporting)Oddly enough, the SDK wasn't updated for SP1 in the description of SPB file creation. It still describes a way to use the Simpropcompiler.exe program:"To create an SPB file, run the simpropcompiler.exe tool, which is in the SDKCore Utilities KitSimProp folder. This is a command-line tool, so open a command window and navigate to the SDKCore Utilities KitSimProp folder. If Flight Simulator X is installed, then enter the following command: > Simpropcompiler 2spb

Share this post


Link to post
Share on other sites

Hi Bill,Could you please explain where or when you use multilayered PSD files in a plane design?Thank you for this observations!Best,Jose

Share this post


Link to post
Share on other sites

>Hi Bill,>>>Could you please explain where or when you use multilayered>PSD files in a plane design?>>Thank you for this observations!It would have been better to ask this question in a new thread, rather than branching off into another direction entirely.In the instance discussed in this thread, a multilayerd PSD file is used to create the gauge artwork, and automatically generated the basic XML code framework.As for "plane design," multi-layered PSD files are used to build up the texture bitmaps for the aircraft...IOW, one should always use multilayerd PSD files for both aircraft and scenery textures.

Share this post


Link to post
Share on other sites

Thanks Bill,It was just curiosity because I am now studying Photoshop and call my attention your comments.I suppose that you draw background of a gauge in one layer and, say a needle in another layer and this tool makes the BMPs and a XML file ready to load in aces.exe to work in the code just for the functions?If that is true, do you think it is worth do gauges in C++?? If you want I can open a new thread asking how to do a little sample gauge from a PSD file.Best,Jose

Share this post


Link to post
Share on other sites

>I suppose that you draw background of a gauge in one layer>and, say a needle in another layer and this tool makes the>BMPs and a XML file ready to load in aces.exe to work in the>code just for the functions?>>If that is true, do you think it is worth do gauges in C++?? I still do 98% of my gauges in C++...>If you want I can open a new thread asking how to do a little>sample gauge from a PSD file.The procedure is adequately described in the SDK already. ;)

Share this post


Link to post
Share on other sites

>The second "tool" is actually a new feature of the ACES.exe>XML Gauge Editor.>>Gauges written to the new ACES.XML schema may be "Exported">from the ACES.exe tool in SPB (Sim-Prop Binary) format. If an>XML version of a file is found in the same folder as an SPB>file, the SPB file will be loaded in preference to the XML>file as the binary format is faster to load that its XML>equivalent.>>This means that gauges in the SPB format are binary encoded,>and thus protected from theft...That sounds interesting! But I just tried to export one of my latest gauges and - allthough it works well in the sim - I've got several load errors in ACE. OK, deleted the elements in question, got no more errors, exported - and it does not work in the sim - it doesn't appear at all.Any idea where to start with this kind of problem?

Share this post


Link to post
Share on other sites

>Any idea where to start with this kind of problem?Without seeing the code, I don't have a clue. OTOH, I've had several people who've reported that one of my SPB'd gauges won't display in their FSX at all, yet it works fine for 98% of the others... :-erks

Share this post


Link to post
Share on other sites

>>Any idea where to start with this kind of problem?>>Without seeing the code, I don't have a clue. OTOH, I've had>several people who've reported that one of my SPB'd gauges>won't display in their FSX at all, yet it works fine for 98%>of the others... :-erks Ah....exactly the scenario that I anticpated would occur withthe publication of this "tool"...At least when I run across malfunctioning XML gauges I cango about troubleshooting them and making the necessary fixes( as well as alerting the original designer to my findings ).BTW, how does a program like Panel Studio react to these SPBfiles? Just curious as I don't expect to ever D/L or useany addon's that use the SPB format for gauges. Paul

Share this post


Link to post
Share on other sites

First of all, thanks for the answers.Despites that this new ACE-version is something one should consider to use, I guess / hope we'll get at least one more update for it.Try to load one of the default FS-X xmls, and you'll get errors...(at least with some gauges like the radarscreen). But the gauges obviously work...Meanwhile I found the mistakes that caused the errors in my xml and also could export them to working spb-files.But all in all I see no big advantage of this format. The code isby far not safe in this format...Herbert

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

>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

Share this post


Link to post
Share on other sites

>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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

>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

Share this post


Link to post
Share on other sites

>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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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