Open up for tools integration

#1
Generally speaking a lot of the SDK tools are of the type "file in, process, output". While this was the standard way of doing tools like this years back it is not something that is recommended anymore for two reasons: It's hard to maintain, and it doesn't support the level of integration expected from modern programs.

Instead deliver a .NET DLL exposing a domain model allowing manipulating the data in an object oriented way before generating the BGL (or whatever) files. Obviously importers for standard file formats (like .X files) can be included in this DLL as well.

The command line tools we know (and still need) would simply be a small "interface" invoking the necessary methods in the domain model.
 
#2
a reply

releasing those tools in a .Net domain is an excellent idea. I would like to see it go one step further, how about some tools using the same potential 'paradigm' to decompile BGL's. There a quite a few legit reasons for doing so. Extracting navigation data is really my primary for being able to do so.
 
#3
reply #2

I know proprietary/intellectual rights is a potential concern for decompling BGL's. A library released to do so could be limited to the extraction of certain types of information from BGL's, once again my primary example being navigation data, VOR's, Airports/ILS, NDB's, ISEC's, you get the idea.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#4
I know proprietary/intellectual rights is a potential concern for decompling BGL's. A library released to do so could be limited to the extraction of certain types of information from BGL's, once again my primary example being navigation data, VOR's, Airports/ILS, NDB's, ISEC's, you get the idea.
I think that a MS supplied tool that would generate XMl from files created by BglComp would be a very good idea. This would stop the multitude of different efforts in doing this kind of thing by the community and ensure the security of current and future file formats. An output in Xml would satisfy just about everyone and given that this is a published format in the SDK avoids copyright and other legal considerations. Given that there are several user created tools of this type I suspect it would not be difficult for MS to do it :)

This is my top wish for future versions of the SDK
 
#6
Just a FYI - what you are really requesting is support for deserializing the compiled format back into the domain model and support serializing/deserializing the domain model to/from XML. If we just get the file format converters, everyone still have to do their own domain model on top of the XML - this is 2008, not 1998. :)
 
Last edited:

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#7
Just a FYI - what you are requesting is support for deserializing the compiled format back into the domain model and support serializing/deserializing the domain model to/from XML. :)
If you say so Lars ;);)
 
Top