• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Installing custom autogen configuration

Interesting to hear about MergES. Also quite interesting to hear that it uses SPB2XML and SimPropCompiler. I Myself have written a program that I distribute with my scenery, and from what I've read about MergES it works very much like it, i.e not overwriting any files but instead decompiling, adding in the entry and recompiling.
I built mine to be customizable, as the entries are retrieved from an xml file and added straight in. It can also remove them on uninstall. It's coded in Delphi and Free Pascal, however (,as I never went beyond a few weeks of C#).
I've always been interested in how a program like this could benefit everyone, but as their is no other alternative to reverse engineering the binary format of SPB, I was unsure of whether this was something that could be shared.
I would also happily take a look into debugging MergES (I think I've spent enough hours in autogen files to achieve mastery.)
 
Hi Darren,

Any news already on debugging the MergES tool? I'm still interested in a generally available merge tool. I have almost finished the autogen for one project now, so in not too long I need to tackle the merge issue on install.

So let me know when I can help with debugging.

Or else I might start to look into making another merge tool myself, but if not needed I would prefer not to duplicate things.
 
I got the sources from Darren, but I haven't had the time yet to properly debug them.
 
So what happens if you go to all the trouble of making this tool to merge descriptions, the end user installs your scenery, the merge goes perfectly and the descriptions are beautifully appended to the autogendescriptions.spb and roofdescriptions.spb, and all is well in the FS addon world for the average turn-key simmer... Then, before that end user even starts the sim to see this beautiful work, he cycles FTX Central one time between FTX NA and FTX Hybrid and those beautifully appended descriptions have now been overwritten by custom autogendescriptions.spb and roofdescriptions.spb that Orbx supplies in the ORBX\Scripts\custom.gb_hybrid folder and updates with every version of the orbxlibs?
 
Good question Jim. But the only way to encourage all developers to merge properly is to have a tool available for that.

If every developer would use that swap files approach it will become a huge mess.
 
Jim those of us who don't use FTX Central will have lovely beautiful autogen, and those who do use it won't :p to be fair OrbX are already sharing their autogen data with others so I don't think there will be so much resistance to a solution that solves so many support headaches for developers all over the world.

Darren'sidea behind MergES was that all devs could use it freely to solve autogen compatibility problems so let's hope a debugged version through Arno is adopted widely. As someone once said, "build it and they will come"!
 
I guess developers going the merge approach should not only merge on install, but also provide a shortcut to remerge after some other scenery affected the autogen configuration.
 
Hi all,

Just to let you know I have started debugging MergES.

I'm discussing some of the things I have found with Darren know to see if I understand what is going on.

But one thing is for sure, merging autogen configuration can become tricky. I think we'll need to set some developers discipline here :)
 
Have you guys tried just replacing the AutogenDescriptions.spb with the xml version? Generally a lot of the simprop processing code in FS will read from either spb, or xml if the spb doesn't exist. If everyone distributed the files as xml, it would make them easy to merge, but obviously, it wouldn't be as secure. You might also want to try the SimProp assembly in the Flight Toolkit. It might be able to read the FSX formated spb and xml. If not, I can fix it up :)
 
When do autogen files get loaded? At sim startup or flight loading, or while the simulation is running? I only ask because I'm wondering if keeping it in XML might have an impact on performance. It's probably negligible, but I'm curious. :p

(The SDK states that "XML gauges, Missions and some Autogen files can either be in XML or 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.")
 
Yes, the data they represent is the same; it's just the way it's serialized. Once it gets loaded into memory there's probably no difference.
 
I believe for the autogen files they are just loaded at startup. I tried using my tools to parse the spb to xml and it didn't work, but I was able to fix it up.
 
During development I often use XML versions indeed, since that saves me from compiling to SPB first. I never really noticed a difference in load time, I guess on the total FSX loading time you can neglect it :)

Steve, I planned to try your library to load the SPB of FSX, but it seems you already found some small issues with that.

The MergES tool decompiles the SPB to XML before doing the merge. So that's not the biggest issue. Whether we use SPB or XML, developers need a reliable tool that can do the merging during their installation. Since that is not widely available at the moment, some developers will just overwrite the SPB files with their own, hence creating the conflicts we are trying to fix.
 
stonelance said:
Have you guys tried just replacing the AutogenDescriptions.spb with the xml version? Generally a lot of the simprop processing code in FS will read from either spb, or xml if the spb doesn't exist. If everyone distributed the files as xml, it would make them easy to merge, but obviously, it wouldn't be as secure. You might also want to try the SimProp assembly in the Flight Toolkit. It might be able to read the FSX formated spb and xml. If not, I can fix it up :)
Click to expand...

stonelance said:
I believe for the autogen files they are just loaded at startup. I tried using my tools to parse the spb to xml and it didn't work, but I was able to fix it up.
Click to expand...

Hello:

When used with FSX files (rather than with MS Flight files), what is the difference in output *.XML file format and content between the above "FlightToolkit" SimPropCompiler.exe :

http://flighttoolkit.com/wp-content/uploads/2014/06/FlightToolkit_1_0_0.zip

http://flighttoolkit.com/

...and the output *.XML file format and content derived from use of the spb2xml.exe by Lamont Clark (aka "lc0277") ? :scratchch

http://lc0277.gratisim.fr/spb2xml2.zip

http://lc0277.gratisim.fr/software.html



Thanks in advance for any further explanation. :)


FYI: I'm curious what requirement there may be in the FSX SDK for specific *.XML file formatting, as IIRC, there was some mention of such a criteria in an old thread at AVSIM during some testing by Jesus Altuve (aka "bojote") which initially involved a mis-interpretation of results from a performance tweak that turned out instead as due to an accidental disabling of certain autogen content rendering (...because of an incompatible *.XML file format being ignored by the FSX SDK compiler and/or FSX run time rendering engine).


ISTR this was due to a some sort of incompatible "UTF-8" format being used instead of "UTF-16" during early tests to edit FSX content in *.XML files prior to re-compilation and/or FSX run time rendering of incorrectly formatted XML source code.

AFAIK, initial problems with incompatible *.XML file format may have subsequently been eliminated by using a 'text' editor which output to a XML format compatible with FSX SDK requirements.

http://forum.avsim.net/topic/317839-simple-stutters-fix-for-fsx/


I'm not certain if the above cited AVSIM thread also involved Byte Order Mark (aka "BOM") issues ...as discussed in this somewhat related context dealing with "XML" in Ruby scripting for Sketchup:

http://sketchucation.com/forums/viewtopic.php?f=180&t=56528

http://en.wikipedia.org/wiki/Byte_order_mark


[EDITED]

BTW: IIUC, one may prefer to use "NotePad++" (aka "NotePad plus-plus" or "NPP") to ensure output of FSX SDK compatible XML files; readers interested in using this freeware editor for text, XML, etc. may get it here:

http://notepad-plus-plus.org/


PS: I see that the default NotePad++ titlebar designation of "ANSI as UTF-8" was regarded as a 'bug' due to potential mis-interpretation as to what file format might result; IIUC this was fixed (...but not documented ?) in a May of 2014 bug-fix update.

A "eXtensible Markup Language (*.XML)" output file type is now available in the NotePad++ 'Save As Type' pick list. :idea:

http://stackoverflow.com/questions/21977623/what-is-the-meaning-of-ansi-as-utf-8-in-notepad

http://sourceforge.net/p/notepad-plus/bugs/4095/

http://sourceforge.net/p/notepad-plus/patches/571/


By default NotePad++ auto-updates itself online every start-up; it is IMHO a good idea to allow this process to run. ;)


PPS: A concurrent related discussion on UTF-8 versus UTF-16 and BOM with regard to XML files and FSX SDK compatibility:

http://www.fsdeveloper.com/forum/threads/xml-files.430825/

[END_EDIT]

GaryGB
 
Last edited:
So, as it currently exists the SimPropCompiler.exe from the Flight Toolkit only loads SimProp symbols from the Flight pak files, and therefore cannot be used to convert FSX spbs to xml. I am going to add support for optionally specifying a directory to load the symbols from instead and this allows converting FSX spb to xml. I'm not really sure what it will use for the encoding. The output should be similar to spb2xml.exe

I am really surprised that encoding would make any runtime difference at all in FSX other than load time, but it is possible something weird is going on. FSX was not a unicode app, but Flight was changed to use unicode pretty much everywhere, so no matter how it is stored on disk, it is usually loaded and converted to unicode.
 
Hi Folks

Just to clarify -
AIUI, FSX's autogen tool has always been capable of converting all FSX SPB's.

spb2xml.exe, though much appreciated, was reinventing the wheel.

IIRC, depending on SPB type, after decompiling,
both product's outputs may contain some extraneous tags.



Gary -
Previous versions of NPP displayed the BOM character.
NPP now suppresses its display through applied styles, (Encoding Menu).
Look in a hex-editor, its still present.

IIRC, deleting the BOM,
then attempting loading into FSX caused the file's processing to fail.



Steve -
Between FSX betas and RTM, weren't some XML's encoding changed ?
I can't remember if it was either or both -
- Windows-1252 to UTF-8 ?
- UTF-8 to UTF-16 ? (default.xml & TerrainAutogenClassDescriptions.xml are UTF-16)

ISTR explanation being,
change was a requirement to support internationalization, (? Kanjii ?).

Whatever the other aspects,
I recall it broke some of our in-development mission xmls.



Everyone -
Regarding the XML merging -

Are any developers overwriting/reassigning any of MS's original entries ?
Or are they just appending their own extra entries ?



HTH
ATB
Paul
 
You must log in or register to reply here.
Back
Top