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

Open up for tools integration

lmoelleb

lmoelleb

Messages
268
Country
netherlands
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.
 
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.
 
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.
 
gggdude said:
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.
Click to expand...

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
 
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:
lmoelleb said:
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. :)
Click to expand...

If you say so Lars ;);)
 
You must log in or register to reply here.
Back
Top